That was exactly my experience few months ago when I was building a wysiwyg resume builder. The first problem I faced was that if I was entering some text and switched from the browser to another app and then back to browser, I would lose focus. So I had to built custom logic for that using a whole bunch of workarounds. But this was an even bigger pain because if the user's cursor was in the middle of a sentence and not at the very end, then placing the cursor at a specific position was quite complex in content editable. Similar problems if the user had selected/highlighted some text.

Undo/redo logic was another nightmare. And copy paste required a ton of clean up before.

Next issue I faced was that if the container element had certain css formatting applied (can't remember which one) then if I hit enter, then backspace won't work. If I remember right, this had something to do with a well reported bug related to pre-wrap, white-space, break-line etc. This was also when I discovered that the content editable would work differently across browsers. This was basically when I dumped content editable and went with a simple textarea and a "fake dummy" hidden textarea used for calculating the size, formatting etc.

https://resumetopdf.com/

Believe it or not, it used to be a lot worse. One of my first dev projects was a contenteditable based editor, and this was back in 2008 so I needed to support IE6-8, which had it's own separate API for manipulating selections/ranges and of course a whole bunch of bugs. Firefox's impmentation wasn't much better!

Yep, I remember running into the IE type edge cases too with contenteditable though I just ended up excluding IE all together as not many people use it now a days anyway. I also remember running into bugs which were logged for Firefox over a decade ago for contenteditable and no one had fixed them.

As someone who's worked on this, I'm oh so conflicted. Yes, it's mostly a terrible idea, if CodeMirror and the likes work. On the other hand, there's so much default behaviour that's just excellent that'd need to be reimplemented if you started from scratch. It can't be denied that contentEditables have the advantage of just requiring much less code overall.

To this extent, I've written a hook for React/Preact that attempts to be a decent code editor basis on contentEditables: https://github.com/kitten/use-editable

Funnily enough, if you just search the code for "// Quirk" it's easy to see that this experience wasn't pleasant in the slightest. But it did allow me to write a code editor in just about a day which can be found here: https://trygql.formidable.dev/

I'd say, there's plenty of edge cases to take care of. But on the other hand, things like composition, selection behaviour, and other niceties are things that you just have to take care of much less

This was my experience, too. Contenteditable wasn’t as bad as I was led to expect going into the project. (It is terrible, but not the showstopper everyone says it is.)

The biggest problem I have with it is that layering on collaborative editing is nontrivial.

Tiptap does a pretty good job of it, but really that's just using a contenteditable as an interface to update a well-defined JSON representation of the content.

If you are planning to write a custom editor Tiptap is a good starting point, but it's weirdly over-complicated in places.

Oh, if I could upvote you twice...

There are still nights I wake up screaming, remembering the time I tried to build an editor with contentEditable. Is there a special place in hell for those who forced this spawn of Cthulhu upon us? Or should we pity these souls, who were the first to lay eyes on these unimaginable horrors?

If you ever meet someone who thinks that the lovecraftian amalgamation of HTML/JS/CSS is a sane platform for developing applications, just tell them to build an editor using only contentEditable and the standard browser APIs. Then wait a few days. They will hate you, but at least they'll be forever cured of their delusion.

Yes, it's that bad. No matter how long you have been programming, no matter what you have built before, contentEditable will defeat you. Decades of experience, written your own programming language, database, editor? Oh you poor soul, contentEditable will laugh in your face, because there is no logic to it. It is the very embodiment of edge cases built upon edge cases, with a smidge of browser incompatibilities sprinkled on top, then all dumped onto the garbage dump that is caret handling.

I'm a contentEditable survivor. The dark episode is now behind me, yet no matter how much time passes, I will forever be scarred by the experience.

> when you go deep into the rabbit whole

It's a perfectly reasonable mistake, but damn are the implications of that phrasing unpleasant to think about...

It's "rabbit hole", btw, in case this was an /r/boneappletea moment :)

I'm curious - how are the implications of rabbit whole worse than rabbit hole?

"Going down the rabbit hole" brings to mind entering the rabbits warren. "Going down the rabit whole" brings to mind entering the rabbit.

Oh it was a typo. But I like it now. Haha

Thumper, oh no!

> that a event based editor is the technical better choice

could you expand on this? what's the high level

You literally build the editor from the ground up (events like keystrokes modify a data object which then changes the page), rather than trying to patch the browser's editor (including all possible versions of every supported browser) into doing what you want.

Yes, and everyone using Compose or dead keys starts to hate you.