Why does the handle attribute changes algorithm of popover associate with all HTML elements

[dSalieri]

You have the following:

The following attribute change steps, given element, localName, oldValue, value, and namespace, are used for all HTML elements:

1. If namespace is not null, then return.
2. If localName is not popover, then return.
3. If element's popover visibility state is in the showing state and oldValue and value are in different states, then run the hide popover algorithm given element, true, true, and false.

But how the above can work with for example this:

The following attribute change steps are used for the nonce content attribute:

1. If element does not include HTMLOrSVGElement, then return.
2. If localName is not nonce or namespace is not null, then return.
3. If value is null, then set element's [[CryptographicNonce]] to the empty string.
4. Otherwise, set element's [[CryptographicNonce]] to value.

I mean the first thing determinated for all HTML elements and the second only for content attribute nonce. But if some invokes the attribute change steps what will it mean:

• Both algorithms will be invoked or
• Only one algorithm will be invoked (which one and why?)

---

By the way, why the popover's attribute change steps doesn't apply same way as for the nonce content attribute algorithm?

Why this can't be deleted

If localName is not popover, then return.

with modification to:

The following attribute change steps, given element, localName, oldValue, value, and namespace, are used for the popover attribute

---

Would be better if spec become clearer, because some expanding in spec makes the mess sometimes.

[annevk]

cc @domfarolino @josepharhar

[domfarolino]

In general, the various hooks that DOM provides (largely for HTML's consumption by my estimation) like attribute change steps, insertion steps etc., seem to be underspecified ordering-wise. DOM provides a per-specification hook, which doesn't specify ordering across specs, and also HTML seems to provide multiple overrides for some of these hooks, as you've found, which is bad form.

Probably most of the time this is fine since I would guess(??) the steps are often mutually-non-observable, but I imagine this system has grown into a larger mess than it was originally conceived to be, so an issue filed against DOM to track cleaning that up is probably best (unless Anne has more historical context that I don't know about).

For this specific instance about popover, I would delegate to @josepharhar who has more domain-specific context than I. But also happy to take a look myself if needed.

[josepharhar]

I probably wrote the popover change steps this way because I found the details element change steps before I found the nonce change steps to figure out what to write:

The following attribute change steps, given element, localName, oldValue, value, and namespace, are used for all details elements:

I don't see how the hook which DOM provides has anything to do with particular types of elements or attributes, so maybe it would be most correct to change all of the attribute change steps to stop saying that they apply to certain types of elements or attributes, and add steps like the one in the popover change steps which actually examines the element and returns early when the steps don't apply.

Probably most of the time this is fine since I would guess(??) the steps are often mutually-non-observable

Yeah I don't think this is a problem, but if somebody finds a problem then I guess we will have to write in the spec somewhere what the order of attribute change step hooking algorithms is...?

[domenic]

I would love it if someone did a holistic refactor of the attribute change steps (and insertion steps, and connected steps, etc...). #7712 and #2771 kind of discuss that.

I don't think it's the highest-priority work, but it would be nice. It's just a lot of busywork moving stuff around.

[domenic]

Moving to #10331.