Shadow DOM and ElementInternals ARIAMixin properties

[alice]

This came out of the discussion on #8442.

Do Element/FrozenArray<Element> attributes on ElementInternals need to be subject to the same Shadow DOM validation rules as the same IDL attributes on Elements?

For example:

<my-listbox>
  # shadowRoot
  | <my-listitem>Generated option 1</my-listitem>
  | <my-listitem>Generated option 2</my-listitem>
  | <my-listitem>Generated option 3</my-listitem>
</my-autocomplete>

class MyListbox extends HTMLElement {
  constructor() {
    super();
    this._internals = this.attachInternals();
    this._internals.role = "listbox";
    // etc
  }

  // ...

  // called when a user selects a list item via mouse or keyboard
  listItemSelected(selectedListItem) {
    // not allowed:
    // this.ariaActiveDescendantElement = selectedListItem;

    // allowed?
    this._internals.ariaActiveDescendantElement = selectedListItem;
  }
}

@annevk and I were chatting about this and it seems that the constraints which led to disallowing elements in Shadow DOM from being used for Element type reflecting IDL attributes on Elements may not apply when it comes to ElementInternals, since ElementInternals won't generally be available to any in-page scripts, and thus can't lead to undesirable dependencies on implementation details within Shadow DOM.

@nolanlawson we were chatting about this in AOM, so I thought you might also have some thoughts to add here.

[mrego]

CC @rniwa as he might have thoughts about this too.

[annevk]

I do think we still want the same overall approach as at the very least we do not want to return elements that are not connected to the same document. (I.e., you can assign whatever, but you might not be able to get it back out.)

But I think there's some merit to this idea. ElementInternals is private after all so any private references will remain as private as ElementInternals is.

At the very least not hiding references to elements inside the shadow tree associated with the element ElementInternals is from, but I don't immediately see a principled reason why it couldn't be any shadow tree in the same document.

cc @whatwg/components

[nolanlawson]

At the very least not hiding references to elements inside the shadow tree associated with the element ElementInternals is from, but I don't immediately see a principled reason why it couldn't be any shadow tree in the same document.

Original comment

This makes sense to me. There is maybe (?) even a principled reason to expose elements inside the shadow root associated with the host element, since it's possible to leak the shadow root using attachInternals:

console.log(element.shadowRoot) // null
const internals = element.attachInternals()
console.log(internals.shadowRoot) // #shadow-root (closed)

(Of course the component can defensively prevent this by calling attachInternals() in its constructor, but if the author forgets, it may leak.)

(Just occurred to me it's orthogonal whether an element can leak its shadowRoot, so hiding the comment.)

If you have access to an ElementInternals, you also have access to the associated shadowRoot of the associated host element, so it makes sense to me that the ElementInternals can reference elements inside of the shadow root. As for referencing any shadow root in the document, that's a bonus for sure. 🙂

[annevk]

I cannot attend triage until Feb 23 it seems. If folks could give this a look before then I'd appreciate it, but otherwise I can explain then.

[annevk]

I've done part of this work in #8932 but as noted there we might want to address some bigger issues in this space first. Help welcome with regards to review and tests and such.