Philosophical discussion and getting back to edit

[SteveALee]

So a fundamental feature of REST is a URL uniquely identifies a representation of a resource (I think)

When you edit in itty.bitty.site/edit the url is changed and if you copy that url you then get a different representation as the URL is "executed"

This seems odd, a bit weird and possibly wrong :)

Relates is that given the generated URL how can we get back to the source used in the editor? This would be like being able to view source in any browser - something that I'm sure makes the web great.

[alcor]

I wrestled with this quite a bit. It was important to me that you be immediately able to share the current url to share the content. It leads to some slightly odd behaviors, but it makes that use (particularly on mobile) more efficient. This is also why there was an edit link for that ad-hoc content. The editor is not really intended for code.

Since advanced editing usually relies on dragging in html or codepen, I was ok with this tradeoff.

As far as getting back to the source, the contextual menu item "view frame source" works well to see exactly what is being rendered.

[SteveALee]

Yes not such a simple design choice. A few thoughts

• If you have an edit control why should it not accept anything including code?
• drag and drop requires use of pointer (mouse or touch) while copy and paste is KB or pointer (a11y)
• a file select UI would allow all input modes
• using codepen requires another a resource to be set up and probably another account
• Why not have a big 'copy URL' button next to editor to copy generated URL to clipboard? That's primary UI and I think will work cross browser (at least desktop). You do already have that function buried in the menu
• with that button then editor is //itty.bitty.site/edit/..... and url to be opened is //itty.bitty.site/...… Then easy way to programmatically or manually generate the edit url from the generated url.
• I've not thought of all the mobile edge cases. Only used on desktop.

While Im at It, having CLI versions to encode / decode is cool but perhaps you could extend your API to offer those functions. That would remove dual maintenance and cross platform problems but would need online access to you service and cause more traffic. "swings and roundabouts"