The above demo works fine in Firefox, FWIW. I had a large hand in building a WYSIWYG email editor a few years back, using direct DOM editing, that was the most full featured available at the time. I would only recommend it to people with very high pain tolerance, as the differences between browsers are stark, undocumented and hard to work around.

In firefox it skips one letter at a time and maybe that is the intended behaviour, but it doesn't seem consistent with what I'd expect from a WYSIWYG editor.

I'd expect there to be 2 positions between the "e" and the "t" that the cursor would stop at so I can either insert text with the formatting of "one" or "two"

There is a position at the start of "two" in Firefox, but you have to approach it from the right. That feels sane to me.

The "approach from the direction you want to take styling from" breaks down when you cannot approach from the other direction, or if there are >2 possible insertion points in the middle of a piece of text. I'm going to use Markdown to show the markup in HN, but pretend like it's rich HTML:

  A string that ends in *bold!*
                             // 
                            AB

Only position A is possible in Firefox's "approach from" algorithm; there is no way to tack on non-bold text to the end, short adding it and then re-/unformatting it.

You can then pretty quickly see what goes wrong here:

  A string that have *_italic bold_ and bold!*
                    ///
                   ABC

In Firefox, only positions A and C are possible; there is no way to start editing at B.

I think you could turn any of these into interesting box forms like one of the links in this thread that has two colored boxes, and you could have text somewhere (like between A & B in the second example here) and delete that text, and suddenly not be able to get a cursor back there, short of laying some text down and reformatting it.

Markdown, and other markup/syntax based inputs, make this trivially obvious, to a large degree. (Some ambiguities in the syntax can cause issues, but those seem to be rarer than issues w/ Slacks WYSIWYG editor.)

Don't Fuck with Paste, extension that disables anti-paste event handlers some banks use, triggers this when pasting into rich editors. Even Facebook and old Slack editor, IIRC.

Yup, in order to be able to paste into any of those inputs you need to have clipboard events on

It doesn't work fine on Firefox android.

Firefox on Android ( / Preview) is generally terrible with input handling anyway. I still haven't figured out a way to paste into a textbox without removing existing text — long press is required to show the menu, but also selects the last word, and unselecting removes the menu.

>long press is required to show the menu

It's not. Tap on the caret and the menu will show up without selecting anything.

Thank you! This does seem to work intermittently (at least, it didn't work when this text box was empty, but started working once I typed in some text). I guess I'll have to file that in my head as "works inconsistently", but at least it… sometimes works?

Same for FF preview.

Checked and it behaves the same in Safari as Chrome so it appears this is left over from WebKit and by HN logic since Apple did it it's the right way! (jk)

Yes, I agree it should be fixed. Most WYSIWYG editors do have issues though. Just tried Pages (apple's word processor. abc <b>def</b>. Putting the cursor before after the space before the d I would personally think is more intuitive to insert bold but it inserts plain. As it is there is no way to type bold at the front of the bolded word. You either have to type new text and bold it OR you have to insert after the d, type a new text and an extra d then delete the leading d. Yes you can press Cmd-B then type but of course if the text had more styling applied that would get cumbersome to reapply styling so you're left with the previous solution of inserting new text in the middle and deleting the leading character.

The reason is that content editable is a gaping hole in the HTML5 spec, at least last time I checked, there are tons of undefined undefined behaviors (not a typo) where vendors have to choose what they want to do and where developers have no idea that the behavior does not exist in a specification.

My very wise coworker made every effort to avoid that minefield. I thought he was wrong for many years, but I have been forced to agree, content editable is completely and utterly useless and should be avoided at all costs.

I always thought the entire cms space, the idea that non coders could manage web content, was a non starter just because of the editors.

But it's utterly inefficient to use coder time to manage web content. That's why the best idea is to create a block by block content editor with textareas or severally limited editors that remove and reformat HTML that's being generated. I've seen good results thanks to this.

I agree though, whenever I included a full WYSIWYG editor to a CMS the end users created unimaginable havoc. "Hey it's Word, I know this".

but it's good enough these days to serve as the basis for the CodeMirror 6 rewrite:

https://news.ycombinator.com/item?id=17859291

All that demo uses is a contenteditable div. The bug is definitely is Chromium.

Safari on Mojave and iOS has the same problem...so it'a likely a bug in that's been around since Chromium/Blink forked from WebKit

So stop implementing WYSIWYG if its a buggy piece of crap across the board.

Really? It works fine in Edge (edgehtml-based version) and FireFox.

Prepare for it to not work in Edge in ~1 month when they switch to being Chromium-based.