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

> Personally, I don't worry about such web apps since

Right, but my question is: Is contenteditable used anywhere in a production level environment that is not a web app with such complexity? In the editing taskforce, we have not come across such a simple editor, with the exception of simple test cases. It is this realization that contenteditable cannot seriously be used by a "simple editor" and consequently is not being used that way which lead us down the path of specifying the beforeinput event.

This does not mean that we don't care about the 'little man' who just wants to create a webpage. Several of the professionally used JS editors that exist today are open source and relatively easy to include on a webpage also by people who only recently began learning about how to create web pages.

What we need to worry about is the interface we give to the web developers creating the editors, and they are the ones then providing the tools needed by those creating web pages.

This also has to do with manpower: the browsers all struggle with putting developers on contenteditable, because this is not specifically important to them. But there a number of smaller companies and organizations behind the various JS editors who do have the developers to create editors and the time to listen to end users' complaints and requirements. That's why it makes sense to let these JS devs create their editors without complicating their lives unnecessarily. Should it emerge in a few years that browsers will put many more resources into this, and should some JavaScript editor have become the defacto standard, then it's possible that it makes sense to use reimplement that editor's API in browser native code and ship it like that.

> Even if web apps don't use insertParagraph command directly, if they don't override Enter key press, the command is executed indirectly. So, execCommand is used forever indirectly.

Right, but that is why enter, backspace, delete, pasting, etc. are among the first things to be overriden and handled in JavaScript. Even without a single bug and everything working exactly the same in each browser, as long as there is at least one custom element, it will break the entire thing.

-- 
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-388774136