Re: [w3c/editing] insertParagraph definition is different from current browsers' behavior when selection is collapsed at end of inline element(s) (#172)

> So, I believe that contenteditable/designMode are just rich text editor rather than HTML editor.

Ok, but is there any editor in the world that does not use at least one custom element? I don't think I've seen one that only does bold/italic/links and paragraph breaks. Even if such an editor exists, it will be highly annoying if one cannot extend it to do more things easily but has to implement all logic again. 

I think it's fine that browsers don't want to deal with those extra elements. That's part of the reason we are moving away from execCommand and toward beforeinput events.

> Yeah, but Mozilla needs to keep compatibility with Blink and WebKit as far as possible due to market share difference.

Ok, granted. Anything that makes Firefox and the other browsers behave more similar will generally make it easier to build an editor. So as long as you are just trying to recreate what Chrome does already (and that is reasonable behavior) that sounds fine. But I'm a little afraid we can get distracted by trying to standardize paragraph merging and splitting (which quickly can turn into a very long debate) as well as standardizing execCommands commands that are no longer used. Let's at least make sure we don't forget about the beforeinput event as that will be what really will give the tools needed to build standardized editors across browsers if done right.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/172#issuecomment-387031601