[editing] Should cE=events (or cE=whatever now) handle selection? (#71)

The discussion started in #56 (https://github.com/w3c/editing/issues/56#issuecomment-131715587)

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](https://github.com/w3c/editing/issues/56#issuecomment-131584200) (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](http://sdk.ckeditor.com/samples/simplebox.html)), 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.

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