Delegation proposal syntax

[mrego]

There are a bunch of issues related to the syntax for the delegation proposal.

Let's link them all from here for future reference and use this issue to discuss the final syntax:

• [Declarative Shadow DOM] bikeshedding delegates attributes #3
• autoaria* or auto-aria* / delegatesaria* or delegates-aria* #8
• Imperative ShadowDOM attribute list API #11
• Condensing properties into a group #12

There's also a section in the explainer about this topic.

The current proposal in the explainer uses:

• Imperative Shadow DOM: delegatesAriaAttributes: "aria-label aria-describedby"
• Declarative Shadow DOM: shadowrootdelegatesariaattributes="aria-label aria-describedby"
• Shadow tree elements: delegatedariaattributes="aria-label aria-describedby"

See a full example:

• Imperative Shadow DOM:

<span id="foo">Description!</span> 
<x-foo aria-label="Hello!" aria-describedby="foo">
  <template shadowroot="closed" shadowrootdelegatesariaattributes="aria-label aria-describedby">
    <input id="input" delegatedariaattributes="aria-label aria-describedby" />
    <span delegatedariaattributes="aria-label">Another target</span>
  </template>
</x-foo>

• Declarative Shadow DOM:

<span id="foo">Description!</span>
<template id="template1">
  <input id="input" delegatedariaattributes="aria-label aria-describedby" />
  <span delegatedariaattributes="aria-label">Another target</span> 
</template>
<x-foo aria-label="Hello!" aria-describedby="foo"></x-foo>
<script>
const template = document.getElementById('template1');
    
class XFoo extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: "open", delegatesAriaAttributes: "aria-label aria-describedby" });
    this.shadowRoot.appendChild(template.content.cloneNode(true));
  }
}
customElements.define("x-foo", XFoo);
</script>

There are a bunch of problems:

• Names are too long: Specially for declarative Shadow DOM. But they're consistent with delegatesFocus and shadowrootdelegatesfocus
• Should we use - to improve legibility: delegated-attributes? Maybe this ship has already sailed and we cannot do anything like that for consistency with other properties.
• List of attributes: Should be comma separated? Should be something different like delegatesAriaAttributes: { aria-label: true, aria-describedby: true }
• What does false mean if we go with a boolean approach?
• Do we want a generic delegates: true that applies to everything? Maybe this is out of scope of this proposal and is more generic than this.
• Should the proposal be tighted to to ARIA attributes or be more generic than that? (see Generic proposal (Potentially expand beyond aria?) #13 and explainer section)
• Is actually "delegate" the best term or should we use something like "import" or something different?

[nolanlawson]

These are all great points and worth bikeshedding on (seriously!). Some of my thoughts:

Names are too long / improve legibility

Legibility is great, but let's avoid reinventing the casing for ARIA attributes. Things like aria-activedescendant are already inconsistent and hard to read, but we would be exacerbating the problem if we tried to "fix" it. delegatedariaattributes="aria-activedescendant" is great because it allows copy-pasting without changing casing or hyphens.

As for whether we're "allowed" to put hyphens in the attribute names, that seems like maybe a question for HTML/TAG folks?

Is actually "delegate" the best term or should we use something like "import" or something different?

For delegates/reflects, I am in favor of exports/imports instead, because of the symmetry. Although this may be confused with ES Module imports/exports. Something like lends/borrows would also be fine IMO.

Do we want a generic delegates: true that applies to everything?

This would be very useful from an author perspective. I think most people would prefer it, rather than having lots of repetition in their HTML.

What does false mean if we go with a boolean approach?

I'd say: the same as not including the key at all.

Should the proposal be tighted to to ARIA attributes or be more generic than that?

This seems inevitable to me, because of for, popup, elementtiming, etc. I think we should at least leave the API open for amendments.