Re: [editing] Should the caret move by default, and should we define this behavior? (#58)

> I think that platform-specific selection implementation is fundamental for accessibility and usability. I don't care if it is implemented by UA or script.

> However, even with enough API (e.g. showing the magnifying glass on an iPad), this would be a huge task for editor devs. So, I imagine there will be a handful of libraries that will have to offer some API in order to be customized by each editor. So we are back to square one: designing an API for managing selection.

I agree that this still does not create a full editor for us. The situation now however seems to be the following:

1. Lowest layer: a limited number of contenteditable implementations that are incoherent used by most browsers nowadays.
2. Middle layer: a limited number of editors (CKEditor, TinyMCE, Aloha 1.0, QuilJS) that have been developed over many years to work around the issues in the lowest layer. They are backed by companies that have the time and resources to have done the development in the first place and that now have the time and resources to monitor whether anything changes about the implementations in the lowest layer so they adapt to that. These editors are hundreds of kilobytes and even MB large because the ground they build on is so shaky.
3. Highest level: The website. This can be Wordpress or Drupal or a custom system and they put the middle layer editor into their site. They add some plugins to make it work with the rest.

The above, I would assume, covers about 99.9% of small to medium sized sites.

Every fortnight there is someone saying he has created the perfect replacement for the above-mentioned editors that is able with just 2kb of code to replace the above editors. The way that goes is usually: they work enough to type a few words in an editor for demo purposes, but if one actually tries to write a text with them, one quickly runs into the numerous contenteditable bugs that they have not been able to cover with their 2kb code. So they start adding more code to it as they find out that their editor doesn't work. This can take some 2-3 years. AT that stage it's as complex as the above mentioned editors, or development has ceased before they ever got there.

I can see two other types of contenteditable-based editors:

* Large organizations with the time and resources to create their own editor. 

* Projects with the need of a complex editor, who lack the resources to do the constant monitoring of cE in the browsers, time to reimplement everything 4 times to work around the bugs in each of these.

I would assume that you fall into one of these last two categories.

The idea is to shift the creation of these libraries from browsers, who have a million other things to do and don't really have time and resources to put into constantly thinking about editing, to JS developers working on editors who do nothing else than concern themselves with editing. 

If the primitives actually get implemented, I expect there to grow maybe 1,2,3 different libraries that can take care of most of the editing. They shouldn't be as large and bulky as what is needed in the editors right now, because they can rely that the browsers behave the same way and don't constantly change. Also, the rest of us can commit JS patches much easier than patches to browsers. It is my understanding that the Chrome team even for a while had planned to move execCommand to Blink-in-JS internally for that precise reason.

The structure would then be:

1. Lowest level: API offering access to browser primitives.
2. Middle: JS libraries that offer access to what execCommand and contentEditable=true and others did previously.
3. Highest: Editors of various degree of complexity that build on those libraries.

With time, the functions the Middle layer performs may be moved into the browser itself after having been spec'ed thoroughly.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/58#issuecomment-108872858