Move some items from contenteditable to HTML

Start with the contentEditable spec draft linked as [1] and review its plaintext-only section and list of legal caret positions, then compare them with the HTML specification. Determine whether those already-implemented parts can be separated into focused PRs while the remaining contenteditable modes and EditContext discussion stay unresolved; done means agreed-upon HTML spec PRs for the suitable parts.

Hey,
a few years ago, we started writing a contenteditable spec draft [1] in this taskforce. This was at a time when we believed that we needed a more basic contenteditable type that would be simpler than contenteditable=true in that the browser would not deal as much with inserting and deleting content, and that would at the same time behave more predictably. The idea was that JavaScript editors could combine the beforeinput event with our more simplified contenteditable to create editors and then eventually be able to deprecate or at least top working on contenteditable=true.

We came up with at least three different alternative types of contenteditable: "events", "caret" and "typing". We moved quickly between these in a circular manner as running into particular issues and finding solutions to other problems, it quickly changed which of them was more useful. Given that we experienced several times coming back to one of these three, we predicted this would happen for a while and we put all three of them into our spec draft. I do not think that we expected that all three would be implemented in all browsers, but we simply did not yet know on which one we would land in the end.

We then moved away from working on the spec draft temporarily while we focused on Input Events. However, we did add some more things to the draft over time: a list of places that it was essential that the caret can be placed in (an area that had been fully of bugs in several browsers for a longer period of time) and also we added a quick mentioning of plaintext-only.

Now the question is how we go on with this: Some of these modes could still make sense even with the new landscape in which EditContext in part replaces Input Events, level 2. For example, JavaScript editors have asked for a way to let the browser keep handling selection changes (caret movements) and this could possibly be done by combining EditContext with a variant of contenteditable=caret or so. The discussion on this will likely take a while, so a final decision on which new contenteditable mode makes sense may still be a bit into the future.

However, there are bits in the draft that have implementations already - namely plaintext-only and the list of legal caret positions. The question is whether we should make PRs toward the HTML spec out of those parts already now while we continue to work on the rest of the document.

[1] https://github.com/w3c/contentEditable