Edit This Blog Post | Hacker News Reader

Edit This Blog Post

shkspr.mobi

82 pointsedent12 comments

Reading the comments on the post, a practical use for this is building forms: https://moj-forms.service.justice.gov.uk/

Oh, this is a good contenteditable demo. I was hoping for a collaborative thing.

Me too. Is it in theory possible? Can you handle a “text change” kind of event then grab the inner html and send it to a server or at least chuck it in local storage. Using local storage and a download button would make the most basic wiki possible!

Absolutely! The real complexity comes from conflict resolution. If someone edits the top, and someone else edits the bottom, which version do you go with? What if they're editing the same area? Entire companies exist to provide elegant solutions to this[0], so it's no simple task.

0: https://liveblocks.io/

The keywords here are operational transform (OT) and conflict-free replicated data types (CRDT). Fun to implement, there are lots of libs.

yourworldoftext is kind of in this space, although it's not traditional HTML. In it's heyday there were a lot of internal pages that were kind of like wikis

Something like etherpad? https://etherpad.org/

See https://etherpad.wikimedia.org/p/hello-hackernews for a real-time demo (works better with more people, I suppose!)

ProseMirror (an excellent library IMO, though it takes a couple of hours of reading the docs to get started) has support for collaborative editing: https://prosemirror.net/examples/collab/

I work for XWiki SAS. Two products we develop have it:

- XWiki, a extensible wiki platform, experimentally [1] but soon to be fully supported.

- CryptPad [2], an end-to-end encrypted collaborative platform. And actually, CryptPad was accidentally born as a first attempt to have this feature in XWiki.

[1] https://extensions.xwiki.org/xwiki/bin/view/Extension/Realti...

[2] https://cryptpad.org/

Not sure what's the current state of behavior for contenteditable in different browsers, but a decade ago it used to vary wildly among them.

The most fun one was how IE handled nested contenteditable attributes. I needed blocks of texts within the editable part which couldn't be edited or removed, so it was implemented with a nested contenteditable="false". This worked as expected in every browser except IE for some reason. After hours of debugging, I realized setting the nested attribute to contenteditable="true" made it work as expected in IE (and of course, broke it for every other browser). Turns out this was a know bug in IE >_>

I just tested the above behavior and it seems to work fine in both Chrome and Firefox, though I have no IE to test with now ¯\\_(ツ)_/¯.

So just a warning for anyone planning to use contenteditable as a quick and dirty WYSIWYG editor for their website, the final output generated can be very different based on the browser the user is using.

Anyway, I poked around and found some other fun things -

* Chrome supports changing the styling of the text using the keyboard shortcuts (Ctrl+I, Ctrl+B), Firefox doesn't.

* Clicking at the end of a header text and pressing <Enter> adds a newline with a div containing a tag in both Chrome and Firefox. On adding any text to this div, Chrome removes the but Firefox keeps it.

* Copying the header text and appending it as a new list item, Firefox adds a tag but Chrome doesn't.

* Adding a new line anywhere else, both Chrome and Firefox add an empty tag. On pasting any header text there, Firefox keeps the empty tag as a sibling but Chrome replaces it.

This was found in just under 10 minutes, I'm sure there are loads more lurking beneath the surface.

I think you nailed it:

> quick and dirty WYSIWYG editor for their website

But, as we all know, quick and dirty never gets deleted.

I tried doing this on a website I made for a business: in dev mode only, press e and it switches on design mode (contenteditable but for the whole document). This let me and others quickly try out wording changes and see how they looked.

Reply on news.ycombinator.com