Give ElementInternals element-reflecting attributes more power

[annevk]

In particular allow them to point to any known element, as long as that has the same shadow-including root as the ElementInternals's element. This is not considered to break encapsulation as ElementInternals itself is encapsulated.

Tests: anyone want to volunteer?

Fixes #8544.

---

I marked this as a draft for now as there are quite a few issues around element-reflecting attributes, such as w3c/core-aam#152, which might have further implications for HTML and WAI-ARIA. I wanted to put this out there to see what it would look like.

(I'm somewhat surprised element-reflecting attributes don't care about "connected" at all, but maybe that's okay.)

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • …
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• MDN issue is filed: …

(See WHATWG Working Mode: Changes for more details.)

---

/common-dom-interfaces.html ( diff )

[alice]

(I'm somewhat surprised element-reflecting attributes don't care about "connected" at all, but maybe that's okay.)

They don't directly care about connected, but this step in the computation of attr-associated elements effectively means the associated element must be connected if the reflected target is:

1. If attrElement is not a descendant of any of element's shadow-including ancestors, then continue.

We check at get time because we didn't want any of these scenarios:

• not being able to construct a tree with attr associations before connecting it to the document
• disconnecting a node even temporarily causes it to drop off any attr association (both for developer ergonomics e.g. when recycling/re-ordering elements in a list, and because doing this would entail extra bookkeeping in the engine)
• a "loophole" to construct otherwise illegal references by moving an element from light DOM into shadow DOM.

[annevk]

That doesn't enforce being connected though. A disconnected subtree can also satisfy that constraint.

[alice]

Right - it only has to be connected if the host element is connected. That was a deliberate design choice, for the reasons I outlined.

[annevk]

I'm not seeing it. If you construct a subtree and point to an element already in the document tree, it'll work but the public getter won't yet work. If you additionally enforced connectedness on the public getter nothing would change here.

I think that also applies to the second scenario. The only case where the public getter will remain functional throughout is if they happen to be in the same subtree, which isn't a given, but also not required for things to work.

The last scenario doesn't seem affected by additionally requiring connectedness for the public getter.

[alice]

If you construct a subtree and point to an element already in the document tree, it'll work but the public getter won't yet work.

Right, it'll only allow you to get the reference back if it's also in the same subtree. The main scenario we were thinking of was one where the host element and associated element were both in the same (disconnected) subtree and the author would like to be able to set up and be able to check all the references before the tree is connected - requiring the whole tree to be connected before you can check the references seemed unreasonable. I guess we could consider also allowing it to be returned if the associated element is connected to the document and, I guess, not descended from any shadow root?

The only case where the public getter will remain functional throughout is if they happen to be in the same subtree, which isn't a given, but also not required for things to work.

Right - since we have no way of telling whether an element removed from the document is coming back, it stops being available as an attr-associated element (both to the IDL attribute getter and to any other consumer of attr-associated elements, such as accessibility APIs) as soon as it's removed from the tree, but sticks around as an explicitly set attr-element so that it can be an attr-associated element again if it lands in a legal part of the tree. Ideally, as you've identified elsewhere an explicitly set attr-element which isn't referred to elsewhere should be a candidate for GC.

It might be worth noting here that we wanted the IDL attribute getter to reflect the actual attr-associated elements as closely as possible, which is why I'm being pedantic about which I'm referring to in each instance. So, if the host element is connected to the document, you can easily check what elements consumers of attr-associated elements will get by checking the IDL attribute. (If an element isn't connected to the document, nothing else is going to be consuming them.)

The last scenario doesn't seem affected by additionally requiring connectedness for the public getter.

You're right, it isn't - the point I was making was slightly tangential, about why the explicitly set attr-element relationship can be set and persists even when it's not an attr-association. I was making that point because I wasn't sure when you would want to check connectedness, or what effect you'd want it to have. I should have made that more clear, sorry.