Should cE=events (or cE=whatever now) handle selection?

[Reinmar]

The discussion started in #56 (#56 (comment)).

So far the plan is, as I understand, that cE=events will only fire events and nothing will actually happen there.

The current input event list includes such input types as caretRight, caretUp, caretEndNextWord, etc. Thread #56 also discusses caret movements.

But selection is not only about caret movements. Hence, the following two topics seem to be totally uncovered right now:

• making selection on touch devices,
• making selection by mouse,
• (theoretically we should also consider other input methods).

If an implementation must handle all actions like mousedown, touchstart, etc. (or adequate intention events) in cE=events, then these two topics need analysis and I predict that this is not going to be easy.

Moreover, the selection works on a normal (non-editable) websites already. I can drag over a text to select it, use Shift+Arrows to select more (note: this is nearly equal to caret movements), etc. Will all this be left without any default action in cE=events? That would be quite odd.Furthermore, is the above behaviour spec-ed? I don't think so. Does it need to be? It'd be great, but I guess it's tough and it's not critical at the same time as it's harmless.

And last but not least, if cE=events is supposed to leave the entire selection behaviour (except rendering) to the implementations, then why shouldn't it drop the native behaviour of drop the drag too? Sounds like we're going too far? IMO dropping selection is already going too far.

Make browser responsible for the selection and its changes in cE=events

Let me list few reasons why I think so.

1. There are two type of user actions for me – those which may modify a content of an editor and those which cannot. The entire selection system falls into the second category. While I want my editor to handle all modifications (because they must be done in a consistent way), handling other actions is not that crucial. I would be satisfied if I just had a control over them (hence the beforeselectionchange event).
2. The cE=events without a necessary methods from the Selection API to back up a fully custom implementation will be useless (or of a limited functionality). This may delay the readiness of the whole ecosystem.
3. The implementations will need to ship with lots of additional code (taking into account all the user actions which may change the selection) to handle the selection and that means bigger code size.
4. I don't expect the selection to behave in exactly the same way on every UA and OS just like don't expect scrolling to work in exactly the same way. I just want to have some control over them.
5. If, as I proposed (see point 3.), the missing selection methods to handle selection movements will imitate possible user actions, then your implementation (even if fully custom), will still be UA-specific as these methods would be UA-specific (unless precisely spec-ed which may delay them). On the other hand, if those methods won't imitate user actions, then building a complete implementation out of them may require a lot of code and may be tricky.
6. Controlling selection is very similar to controlling drag and drop. While drag and drop can be prevented and/or its behaviour can be modified, it's handled by the browser. The UA listens to mousedown, mouseup, etc. I can prevent all the events and even build a custom drag and drop system (see how dnd of blocks works here), but as developer I don't need to implement everything from scratch. I also don't expect that the placement and rendering of a "drop caret" is spec-ed and as you can see the API works without that.
7. The more cE=events drops, the more analysis we must make. This will delay the whole feature, instead of speeding it up.

To conclude:

• UAs should be responsible for the selection and its changes.
• The default actions should be overridable (and predictable thanks to exposing UAs' intentions), but they do not need to be spec-ed.
• cE=events without selection handler will not be functional unless every API is implemented.
• In general, in cE=events user actions should not modify the content, but they may cause other actions (like selection changes, related scrolling, zooming, whatever). This sounds for me as a good rule of thumb when deciding what to drop.
• I think that such approach is in line with https://lists.w3.org/Archives/Public/public-editing-tf/2015Aug/0041.html. Let's don't design something that will be unusable for a long time while not giving any alternatives.

[johanneswilm]

I think we need to depend on the selection API being in place. I can see it being attractive to replicate everything we need here, just to make sure that it's there when we need it, but currently it seems that the Selection API is more on track to getting into browsers than this spec.

Also notice that this is supposed to be a first module, and later modules should then be able to remove large pieces of JavaScript polyfills. This is only supposed to be functional, not represent the ideal division of labor between browsers and JS editors.

But maybe we can add some examples into the spec about how certain operations are done, and in those link to the Selection API spec, just to make sure that UA developers get the point.

[johanneswilm]

And as you can see from this discussion: #52 , we added two extra intentions connected to selections that are not keyboard-related: select word, block and all. We can reopen that issue if you feel you want to add even more there.

[marijnh]

If I understand correctly, the goal of this exercise is to gut out most of the complexity from contentEditable, while still allowing JavaScript components to implement rich text editors.

I think what both CKEditor and ProseMirror (and CodeMirror on mobile, to a certain extent) are doing (leave selection to browser, but intercept editing actions) illustrates the way forward pretty clearly. Those could basically keep working the way they work now, just switching to a different contentEditable mode, and handling some new events.

Removing the cursor/selection entirely would be a disaster, I expect. You can implement proper cursor motion using just existing APIs, but it is a big, complicated problem (bidi text is hard to reason about). People wouldn't bother. You can't, as far as I can see, allow people to manipulate selection and place the cursor on touch platforms without having the browser be aware of the selection. (This is why CodeMirror, which has most of this stuff already implemented, does enable contentEditable on such platforms.) The same, by the way, goes for screen readers -- those get lost easily if the selection isn't managed by the user agent.

So a good start would be to leave selection, focus, and cursor display in scope for the new contentEditable approach, but entirely disable built-in editing, filling the gaps that leaves (IME input, spell correction, ...) with better events. That would be all I'd need to make CodeMirror and ProseMirror work.

[johanneswilm]

Ok, good points, I think we can summarize this as that we leave caret movement as default actions, but we do not specify how the caret moves, so that the various UAs can take care of that. A later spec can then bring in "standardized caret movement".