Combine selection events under GlobalEventHandlers

[Elchi3]

Companion PR for mdn/content#15385

Let me know if this approach makes sense at all.

[Elchi3]

Okay, so I guess whenever a specific interface's compat data differs from the data we have in GlobalEventHandlers, we want to have a compat data entry for that feature on the specific interface.

So, in addition to
api.GlobalEventHandlers.selectionchange_event

we also want
api.HTMLInputElement.selectionchange_event
api.HTMLTextAreaElement.selectionchange_event

[saschanaz]

Having them together sounds good, but I think "whenever a specific interface's compat data differs" should be "always" or machines will get zero data for those interfaces. (And having zero data typically means no support, which makes no sense)

[Elchi3]

Okay, but what would "always" imply exactly? The list of interfaces is quite long as GlobalEventHandlers is well global...

As a start it would be all of these:
Document includes GlobalEventHandlers
Window includes GlobalEventHandlers
HTMLElement includes GlobalEventHandlers
MathMLElement includes GlobalEventHandlers
SVGElement includes GlobalEventHandlers

And then the two we identified only through the different compat data:
HTMLInputElement
HTMLTextAreaElement
(but there are of course more elements that inherit from HTMLElement).

How would I programmatically detect where I need to have compat data entries?

[saschanaz]

How would I programmatically detect where I need to have compat data entries?

Perhaps there should be a script that checks the IDL?

[Elchi3]

How would I programmatically detect where I need to have compat data entries?

Perhaps there should be a script that checks the IDL?

Hm yes, I can see how that's doable to go through all of the inheritance. Is it practical for BCD, though? I mean it would be a lot of places where we would record compat data and GlobalEventHandlers has many (50+) features.

[saschanaz]

GlobalEventHandlers itself is not very practical to be fair. As current BCD items are IDL machine readable in some ways, I think it's practical to leave it as is.

[Elchi3]

I reverted the changes for HTMLInputElement and HTMLTextAreaElement.

(Not sure this brings me any further to come to a general rule for how to treat events that come from GlobalEventHandlers, though. Just having the data on api.GlobalEventHandlers.* is not it apparently. Having it on all specific interfaces isn't either, so it is something in-between that is maybe a case-by-case decision.)

[Elchi3]

In mdn/content#15385 (comment) @foolip proposes yet another way.

Per https://w3c.github.io/selection-api/#selectionchange-event the "selectionchange" event can be fired at Document, HTMLInputElement and HTMLTextareaElement. I think it'd make sense to have these as 3 pages, and link them together. (I haven't tested if they're actually supported.)

If I understand Philip correctly, the proposal would be to have
api.Document.selectionchange_event
api.HTMLInputElement.selectionchange_event
api.HTMLTextAreaElement.selectionchange_event

(and nothing in api.GlobalEventHandlers)

[github-actions]

This pull request has merge conflicts that must be resolved before we can merge this.

[foolip]

I think HTMLInputElement and HTMLTextAreaElement should have separate entries. They're mentioned separately in https://w3c.github.io/selection-api/#selectionchange-event and importantly they don't seem to be supported in Chromium, so they shouldn't have the same compat data as Document.

[foolip]

Manual testing with https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10319 confirms the "selectionchange" event on <textarea> is supported in Firefox but not in Chrome/Safari.

[foolip]

Hah, this is amusing, none other than @saschanaz implemented this in Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1677253

[saschanaz]

Yeah it's weird, Chrome "supports" selectionchange within textarea but fires it at document, not at each element.

[saschanaz]

HTMLInputElement does not include GlobalEventHandlers and there is no machine-readable way to tell the data is in that mixin instead of the interface.

Wait, sorry, it does actually (via HTMLElement includes GlobalEventHandlers). But #16029 (comment) is still relevant here.

[queengooborg]

Thanks @Elchi3! However, we ended up deciding to demix GlobalEventHandlers as it's the only mixin left and it's not fully representative of what events fire on what interfaces.