Finalise spec mechanism for event handlers

[lukewarlow]

As of #457 the spec uses the HTML "event handler content attribute" concept. Anne's feedback was that that was ambiguous and we should instead generate a fixed list to check inside of. This issue tracks generating that or an alternative.

cc @koto as spec editor you might know how best to deal with this.

[koto]

@otherdaniel how does Sanitizer deal with this? From memory, the challenge was that there was no centralized and specced list of event handlers we could refer to.

[otherdaniel]

@otherdaniel how does Sanitizer deal with this? From memory, the challenge was that there was no centralized and specced list of event handlers we could refer to.

Yes, there isn't a spec list of event handlers. Sanitizer has it a bit easier, since it's based on an allow-list: We (manually) write a list of allowed attributes, and we maintain a list of all attributes. Sanitizer doesn't have to decide why an attribute (or element) isn't in the allow-list, e.g. whether it's an event handler or not.

There was some discussion of adding some sort of spec-level 'tags' to any known element or attribute that could then form a basis for these lists; but this mechanism doesn't currently exist. Until it does, it'll be manually maintained lists.

[lukewarlow]

I'm happy to spend some time and put together a list.

But from a spec maintainer and implementation point of view a block list of element event handler attributes seems far from ideal. Any time someone adds a new one they have to remember to adjust that list. Rather than current implementations which just use the IDL (which I'm realistically gonna use as the basis for my list). Especially tricky if the event handler is specified in a random wicg spec or something like that. Also if there's non standard events browsers have they should also be protected but won't be specced.

That being said I'm happy to defer to others on whether that's okay in practice.

[koto]

So, rephrasing, the choice is to be either ambiguous and refer to other spec concepts (event handler content attribute), or explicit, and maintain a separate list (here, or in HTML?). I actually think the first choice is better, from normative perspective.

[otherdaniel]

But from a spec maintainer and implementation point of view a block list of element event handler attributes seems far from ideal.

From an implementation point of view, there's two easy ways:

• Check whether the attribute name [Edit: of a spec-defined attribute] starts with "on". HTML has been quite consistent with that.
• All event handlers in WebIDL are of type EventHandler, OnBeforeUnloadEventHandler, or OnErrorEventHandler.

But I don't think this is how we can spec things.

[lukewarlow]

check whether the attribute name starts with "on". HTML has been quite consistent with that

Unfortunately custom attributes would fall foul of that and apparently chrome's had issues with it.

[otherdaniel]

check whether the attribute name starts with "on". HTML has been quite consistent with that

Unfortunately custom attributes would fall foul of that and apparently chrome's had issues with it.

What I meant is, whether it's a spec-defined attribute and starts with "on". Getting a list of attributes described in the spec and filtering for the "on" prefix gets you the list of event handler attributes, as they've been consistent with the naming.

[annevk]

"Specification-defined attribute" is also not a concept that exists though, currently.

[fred-wang]

Skimming over existing WPT tests, it seems all the event handler attributes used in tests are coming from GlobalEventHandlers. Conversely, all event handler attributes from GlobalEventHandlers are covered by trusted-types-event-handlers.html (which tries all the names of a div's proto starting with 'on' of at least 3 characters)

Trying to implement getAttributeType in Firefox, it's not clear from the current text of the spec whether the attributes below should also be covered:

• WindowEventHandlers from the on HTMLBodyElement and HTMLFrameSetElement, some of them also supported by the <svg> element.
• onencrypted and onwaitingforkey on HTMLMediaElement from the Encrypted Media Extensions.
• SMIL attributes used for SVG animations (namely onbegin, onend and onrepeat).