move all caret movement intention events from beforeinput to beforeselectionchange?

[johanneswilm]

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.

[Reinmar]

Yes, that's how I would see it too. Then we would have a cleaner beforeInput event which would be really only about the "input". And a separate beforeSelectionChange event which would about selection.

[spocke]

Yes. Makes more sense to have that in the Selection API spec.

[johanneswilm]

@rniwa What do you think? Would the beforeselectionchange event as you imagine it contain the user intention?

[Reinmar]

I created w3c/selection-api#56 for the Selection API spec.

[johanneswilm]

F2F has decided to change the names of the events to beforeEdit and Edit and only have them apply to contenteditable elements.

[ojanvafai]

Which events were renamed to beforeEdit/Edit?

[johanneswilm]

@ojanvafai The ones that were called beforeInput/Input. The reason was that we already have an "Input" event which works on input elements, textareas and contenteditable, but gives no good information. We wanted to make clear that this does not apply to fields, which the Input event DOES apply to.

About half of the editTypes we then moved to beforeselectionchange -- all the ones related to moving the caret somewhere or selection things (selecctAll, etc.)

[ojanvafai]

Moving the caret movement types to beforeselectionchange makes sense to me. That seems orthogonal to renaming the event though.

I don't think the renaming makes sense. As you say, we already have an input event. If we rename these, then every input will end up having to fire beforeEdit, edit and input in addition to whatever keyboard events need to fire. This is bad for performance and bad for authors (one more event type they need to learn).

Also, Blink/WebKit implement as a wrapper around contentEditable. IMO, that's a good thing and it's one that we should build on and encourage all browsers to move to. Conceptually, the end result should be that is a shadow DOM wrapper around a contentEditable=events element.

I wasn't there on the second day of the F2F when this was discussed, but as I understand it the concerns are:

1. We don't want to issue beforeInput/input events with a "bold" editType on
2. targetRange doesn't work on .

I agree with those concerns, but would be happier solving them in a different way. The beforeInput/input events just shouldn't fire for if the user hits ctrl+b, etc and targetRange should be null.

This fits into the platform layering model of being a wrapper around contentEditable because conceptually:

1. The code that dispatches beforeInput/input for ctrl+b would be a feature of the code that implements contentEditable=typing on top of contentEditable=events
2. The code that fills targetRange would know to leave it out for closed shadow roots (once we finally get those specced and implemented).

[johanneswilm]

True, those were the concerns. Additionally, we found the Input-field had some other fields in some UAs and none in other UAs.

Discussion has been moved to new issue #87