Relating to #3515 and #3917.

Relevant spec language from the current PR:
https://whatpr.org/html/3917/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element

We discussed this during the Web Components meeting at TPAC (minutes).

@zcorpan summarised some requirements for the design of the API:

1. Removing and re-adding an element which is the subject of an attr-association should ideally not cause the association to be lost.
   • @rniwa does not agree with this.
   • The developer cost if this is not true would be needing to add a secondary mechanism for tracking these relationships, so that they can be re-added after removing and re-adding the element.
2. The design should not compromise the encapsulation provided by shadow roots.
3. The design should not allow inadvertent creation of circular references.
   • @rniwa, @annevk: Neither Simon nor I could recall the details of this concern; would either of you mind fleshing out an example to illustrate this risk?
4. The web developer should be able to specify associations for the constituent elements within a component before inserting the elements in the DOM, and the associations should survive regardless of the relative order of insertion and the relative order of the elements in the tree
   • for example:

   let container = document.createElement('div');
   let a = document.createElement('span');
   container.appendChild(a);
   let b = document.createElement('input');
   container.appendChild(b);
   b.ariaLabelledByElements = [a];  // a precedes b in the tree
   document.body.appendChild(container);

5. ??? - @annevk, @rniwa: I thought there were seven enumerated requirements, but there seem to only be 5 in the minutes. Do either of you remember what the others were?
6. ???
7. The design (probably obviously) needs to be implementable.

Here are what I think are the open questions:

1. In general, when and how should an attr-association have distinct behaviour from a regular (expando) JavaScript property on an Element DOM object? i.e.

   a.foo = b;
   // vs
   a.ariaActiveDescendantElement = b;

2. Should an attr-association be allowed to be created, or persist under circumstances when it can't have an effect? For example, a <label> for relationship where the <label> has been removed from the tree (or is yet to be added) and thus can't act as a label.
   • This potentially goes to (1) and (4) in the developer needs noted above.
3. Should an attr-association be treated like a regular javascript reference for the purposes of garbage collection? i.e. if the attr-association is the last remaining reference to an Element object which has been removed from the tree, should that Element object be considered garbage?
   • This is moot if attr-associations do not persist when the Element is removed from the tree.
   • If the Element should be garbage collected, then should the attribute and the attr-association be removed when it is? Does that constitute revealing gc timing?
   • How would we detect this occurring?
4. How should attr associations behave across Shadow DOM boundaries?
   • Current spec allows creating an association to any element which is a descendant of a shadow-including ancestor, i.e. in the same shadow scope or any of the enclosing ones.
   • Allowing an association to go into an unrelated shadow scope would potentially leak implementation details.
     • This is also the case for a.foo = b.
   • In particular, how can we avoid a leak in the case where an author does something like:

   a.ariaActiveDesendantElement = b;
   deeperShadowRoot.appendChild(b);

   • If we want to remove the attribute at that point, how do we detect the moment when it needs to be removed?
   • If not, how do we avoid leaking encapsulated details?
     • Do we conceal the association, presumably by special-casing the getter method?

     // continued from above
     console.log(a.ariaActiveDescendantElement);   // logs null
     document.body.appendChild(b);
     console.log(a.ariaActiveDescendantElement);   // logs b

     • How should this work for associations with lists of elements, like ariaOwnsElements?
     • Does the association still have an effect (for example, on the accessibility tree) if it is concealed?