Limit onselectionchange to Document until known to be needed elsewhere

[foolip]

Per the testing in #54 it looks like implementations have it only on Document, with the exception of WebKit which also has it on HTMLBodyElement.

There was talk of also firing the event on some elements, but that's not yet in the spec, moving onselectionchange to GlobalEventHandlers could make sense as part of that and be a form of feature detection.

[rniwa]

I don't know what spec change you're proposing here. Could you clarify?

[foolip]

I propose to move onselectionchange from GlobalEventHandlers to Document until the spec change that would cause the selectionchange event to fire anywhere other that on the document.

[rniwa]

Due to the issue #53, we're going to start firing onselectionchange on input and textarea elements.

[foolip]

Do you expect that this will happen soon both in spec and implementation? If it could be a year out, it'd be a shame if any implementation moved onselectionchange to GlobalEventHandlers first, if input.onselectionchange will be the only way to feature detect support.

[rniwa]

I think Gecko has already done that. See https://bugzilla.mozilla.org/show_bug.cgi?id=571294

[foolip]

Oh, too late then.

[ehsan]

I think Gecko has already done that.

Done what? We currently only dispatch the selectionchange event on Document, but selectstart is dispatched to all elements, depending on the parent start node for the selection's range.

Also, we haven't shipped this API, but we would like to, so we can change our implementation in whatever way that's needed. I unfortunately don't have access to reopen this issue, but if restricting the selectionchange handler to Document for now allows us to get to something that we can ship faster, that's ideal.

[ehsan]

Also to make it more clear, right now we expose onselectionchange on Document and onselectstart on GlobalEventHandlers, similar to WebKit and Blink where I can inspect the source.

[rniwa]

As a WebKit implementor, I don't see any value in limiting this to Document and HTMLBodyElement. I could imagine adding an informal note saying the implementations should do that but I don't think it makes sense for the spec to be doing this one off thing like that. It would be inconsistent with other event listeners, and we don't need any more inconsistencies on the Web.

[foolip]

I'm not saying that it should forever stay on just Document, just that the change in spec and implementations should coincide with making selectionchange fire on input and textarea elements. If that change never materializes, we'll be better off with the spec matching what is currently implemented.

[foolip]

FWIW, https://fullscreen.spec.whatwg.org/#api adds event handlers on Document only.

[rniwa]

I'm not saying that it should forever stay on just Document, just that the change in spec and implementations should coincide with making selectionchange fire on input and textarea elements. If that change never materializes, we'll be better off with the spec matching what is currently implemented.

The thing is, I'm about to add selectionchange event on input and textarea. What do you suggest we do once that happens?

[foolip]

Then onselectionchange should be moved to GlobalEventHandlers. It's not unusual for spec issues to sit around for years, but if the change really is imminent, then please close this issue again.