set targetRange to null for all editTypes where the targetRange would always have been equal to the selection range

[johanneswilm]

This request came from Apple after the meeting had concluded. As I see it, this removes no functionality to editors, as one can simply find the range by looking at the selection, as long as everything is synchronous and the selection doesn't change before the event is being handled. So if this makes things easier for Webkit, I am fine with removing those target ranges.

Please comment if anyone has issues with this.

[rniwa]

I don't think the request was removing targetRange. It's about setting it to null for all event types but repalceContent since that's the only case in which we may request to modify parts of the document that's not adjacent to the caret/selection.

[johanneswilm]

@rniwa Exactly. And I assume that this also applies to any future editType that for whatever reason is unrelated to the caret/selection, right? So basically we remove the range info from targetRange (set it to null) whenever the selection range and targetRange would be the same anyway, and right now that's all cases except replaceContent. I guess for this to work, we need to specify that the events are fired synchronously and before the selection has any chance to change, right? I briefly spoke with Apple's Sam (?) yesterday, and he mentioned that we need to specify how it relates to the event loop.

[johanneswilm]

@rniwa How will this work with multi-range selections and inserting characters? Should the JS get an indication which of the ranges corresponds to the one where something will be inserted? Or is this up to the JS code to figure out?

[rniwa]

I think it depends on each editor and the type of an event you're getting. e.g. if the type is deleteContent, then presumably you wanna delete contents in every range. If the type if paste, then perhaps you want to paste into the first range instead.

Regardless, targetRange might need to be replaced by the new selection object we talked about which properly supports multi-range selection.

[johanneswilm]

agreed. For now I will just turn it into "targetRanges" for just that one editType. Then we can change it once you have the new selection object ready.

[rniwa]

And yes, all these events need to fire synchronously.

[johanneswilm]

@rniwa I think this already specifies the event order and that these events need to be synchronous: https://w3c.github.io/uievents/#h-event-types-list given that the "beforeInput" event there is the event we are working on (we should resolve #87 to be clear about this).

[johanneswilm]

@rniwa @kojiishi: At the CSSWG @frivoal and I discussed whether it would be good enough that it is specifies the order of the different events related to user input within cE are synchronous, if we want to make sure that the selection/caret has not changed at the time the event is being triggered, and also to be able to do the timeout-0 type polyfills @rniwa was contemplating.

The synchronous nature of the events mean that one of them has to finish before the next one starts, right? Does it also ensure that there cannot be a separate thread that changes the selection in the meantime?

[rniwa]

Yes, there is no such a thing as a "separate" thread in Web. Everything is single threaded by design in DOM.