Disambiguate when to add global event handlers

[domfarolino]

Fixes #611. I think when new events are introduced with the intention of being fired at HTML or SVG elements, as opposed to just generic non-DOM-associated EventTargets, the guidance is to add them to the GlobalEventHandlers mixin.

As #611 notes, this is the advice I received by Domenic in WICG/fenced-frame#144 (comment), and I think there is slightly ambiguous wording in the design principles that may mistakenly lead people away from this advice when designing new APIs that introduce new events aimed at HTML elements. See #611 (comment).

---

Preview | Diff

[domfarolino]

@zcorpan @annevk Can you confirm that this is right? In particular, #611 (comment).

[annevk]

I'm not sure that we necessarily want all SVG events to end up on that list, but maybe? The other direction does seem like it's usually desired.

cc @foolip

[domfarolino]

That suggestion works for me @jyasskin, thanks! Btw @annevk, can you think of any specific guidance we could add (maybe in a follow-up) for when it would make sense to add element-specific handlers, instead of adding global ones?

[annevk]

Element-specific seems almost never justified (due to bubbling), but I don't know how many events SVG and MathML define and whether we want to have those on the global list.

[marcoscaceres]

I think @bkardell said none for MathML. I’m unsure about svg. Maybe we should take out mentions of those.

[marcoscaceres]

Checked SVG’s IDL. It depends fully on html. https://www.w3.org/TR/SVG2/idl.html