Add beforeselectionchange event

[Reinmar]

Quoting @johanneswilm from w3c/editing#73:

beforeselectionchange has been mentioned a few times. This event should be in the Selection API. If the caret movements intentions are to be moved there, it's important that the beforeselectionchange event contains the user intention (such as: "caret up").

Alternatively the beforeselectionchange event can just have a from-range and a to-range that doesn't need to specify what user intention caused the selection change, and we keep the intended caret movement events the beforeinput.

[rniwa]

I think if we're doing this, we need to make it so that only user-initiated selection change triggers this event as in selectstart event. Otherwise, it would become an implementation nightmare.

[Reinmar]

I agree. Just like beforeinput, the beforeselectionchange event would be a "user intention event".

[johanneswilm]

I agree as well.

[johanneswilm]

Let me know when/if you are ready to add it to the selection api spec, then I'll remove it from the input events spec.

[johanneswilm]

@rniwa Now that the beforeinput event is shipping, I am being asked about the status of beforeselectionchange. Do we have a timetable for when we are going to move ahead with this?

[johan]

There would be definite benefit for this event, especially if (along the lines of the detailed inputType properties of a beforeinput event) this beforeselectionchange event could cover OS standardized Edit menu action intents like "Select All" too, not just explicit ranges.

Similarly whatever typical caret movements OS environments standardise for "move caret" or "extend selection" to previous/next glyph/word/paragraph/page/document start/endpoint, and so on, so web developers don't have to guess what raw editing actions their users expect to have such semantics.

[Zhang-Junzhi]

I think the event can be renamed to something else, and it can only be triggered when the change attempt is going to fail.

[Zhang-Junzhi]

For example, when the caret is already after the last character in the editor, if the user still presses the "move-forward" arrow(Say, right/down arrow in a horizontal-tb or vertical-lr editor; or left/down arrow in a vertical-rl editor) to continue moving forward, it will fail, but the developer may sometimes want to be informed of the user's failed attempt. Only then the event can be triggered.

[rniwa]

The problem is that whether a movement fail or not is not obvious to the browser. In the case the app itself is drawing selection for example, the browser has no idea whether the selection had moved or not even,