window event attribute category is not referenced

[heycam]

In definitions.xml, there is an attribute category named "window event" that includes event attributes like onafterprint, onpagehide, etc. This attribute category isn't referenced anywhere, and neither are the attributes listed in it. The attributes in this category end up in the attribute table appendix, but with no elements listed next to them. (Which makes sense, since they're used on the window object.)

Should it be removed?

[dirkschulze]

@heycam So the attributes in question are not only no referenced but lack a description as well? Do we have any implementation reports?

[heycam]

That's right. They're all attributes that are defined in HTML anyway.

[dirkschulze]

@heycam Ah ok, I am fine with removing the tables. Are they part of the mixins we share with HTML and SVG?

[heycam]

Ah, yes the IDL attributes are all defined on WindowEventHandlers.

[heycam]

@dirkschulze actually, hold on a moment. Is the intention that these attributes are all supported on a root <svg> element? The SVGSVGElement implements WindowEventHandlers; line in the IDL makes it feel like that is the case. But is there text in the spec that actually requires this?

(If so, then the right fix is not to remove the attribute category, but to add "window event" attribute category, to the <svg> element definition in definitions.xml.)

[heycam]

In https://svgwg.org/svg2-draft/interact.html#EventAttributes it says

For every event type that the user agent supports, SVG supports that as an event attribute, following the same requirements as for event handler content attributes [HTML]. The event attributes are available on all SVG elements.

That sounds like every event type gets an event handler content attribute, and they can all be specified on every SVG element. "pagehide" is a supported event in all browsers, but I don't think that onpagehide is supported on a <rect>. Should it instead be just the events that are exposed on GlobalEventHandlers? (Is there a term for that?)

[dirkschulze]

@heycam ideally we do not expose more events as attributes than are implemented in UAs. If GlobalEventHandlers does the thing I am fine with it. @AmeliaBR knows the terms better than me.

[AmeliaBR]

With respect to the section quoted in #741 (comment), we already have an open issue for fixing that language (#467).

But the window event handlers are separate. HTML exposes them on body/frameset (including as markup attributes) as well as the window DOM object. SVG 1.1 defined a list of "document-level event attributes" that can only be specified on <svg>. However, many items on that list are now global events in HTML & are supported on all elements. The only crossover between the two lists is "onunload", although the SVG version was linked to a unique "SVGLoad" event that we've since removed.

Quick testing today, neither Chrome nor Firefox seem to support onunload on <svg> elements (as either an IDL value or an attribute), nor do they support any of the newer window event handlers.

So maybe we can just match reality and drop any attribute version of these handlers? That means you couldn't set them from markup in a standalone scripted SVG file, but do you really need to? I don't think anyone's ever complained about them missing…

[css-meeting-bot]

The SVG Working Group just discussed window event attribute category is not referenced.

The full IRC log of that discussion

<AmeliaBR> Topic: window event attribute category is not referenced
<AmeliaBR> github: https://github.com//issues/741
<AmeliaBR> Amelia: This is in respect to window event handlers. In HTML, you can set these with attributes on the body & they're reflected up. In the SVG definitions.xml, we've got a defined class of these attributes but don't actually use it anywhere.
<AmeliaBR> ... There's also confusions because a lot of these events have changed since SVG 1.
<AmeliaBR> ... As far as I could tell, no one supports the attributes, but I haven't tested all the details.
<AmeliaBR> krit: So we need more tests?
<AmeliaBR> Amelia: Yes. Though maybe not ready for formal WPT tests yet. Need to figure out what the spec should be based on what works.
<AmeliaBR> ... My preference is to match implementations & match HTML as much as those intersect. Not a strong argument for `onunload` and `onload` attributes and such.
<AmeliaBR> ... Next actions? Should we try to ping more implementers?
<AmeliaBR> krit: That sounds like a good idea. I won't have time to look at it.