"Reflection" can be a confusing term

[mrego]

We already use reflection term for ARIA attribute reflection, and reflection of HTML elements in general (see HTML spec: https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflect).

There reflection means that the HTML attributes are "reflected" on the JavaScript/DOM side, so one can query/modify them from JavaScript. Example:

  <div id="foo" aria-label="Test"></div>

With ARIA attribute reflection you can do things like:

  console.log(foo.ariaLabel); // Test
  foo.ariaLabel = "Modified";
  console.log(foo.ariaLabel); // Modified

If I understand correctly this proposal, this is a different kind of reflection than the one I've described above. This is more about how to "export" or "expose" the Shadow DOM internal elements, so they can be somehow referenced from outside the shadow tree. From the explainer:

This proposal introduces a reflection API which would allow ARIA attributes and properties set on elements in a shadow root can be reflected by their host element into the parent DOM tree.

So I believe this can be confusing, for example the README talks about "reflect" ARIA attributes, which is very similar to the wording we've been using for ARIA attribute reflection.

It's not possible to "reflect" ARIA attributes from am element in a shadow root up to the host of that shadow root.

Also in the AOM Features in progress document, this repo is now linked in Aria attribute reflection feature, which is not totally right I believe.

I don't have a great suggestion for a better name, but I think it'd be better to look for alternatives to avoid this kind of misunderstandings.

[Westbrook]

I've outlined some ideas as to how this could be rectified in #6. Pasted below for conversation:

• ARIA Attribute Export API
  • This would update reflects="..." to exports="..." and reflect-* to export-*, etc.
• ARIA Attribute Hoisting API
  • This would update reflects="..." to hoists="..." and reflect-* to hoist-*, etc.
• ARIA Attribute Surfacing API
  • This would update reflects="..." to surfaces="..." and reflect-* to surface-*, etc.
• ARIA Attribute Maping API
  • Possibly becomes a parent API naming to include both this and the delegation API
  • This doesn't give a specific direction for attribute naming, but might be worth considering at large.

Meta Question:

• Is it just an "Attribute" Mapping API? Current discussions point primarily to ARIA, but other applications exist, see Add reference to OpenUICG Popup API #5

[mrego]

Somehow this proposal "reflection" is more related to attributes that reference to an element (IDREFs) like aria-labelledby; than string attributes like aria-label. And as you say this could apply to other things, like <label for=input>.

Do we need to use this proposal to expose string attributes outside of the Shadow DOM? Is there a use case for that too?

However, the delegation proposal is related to both things IDREF attributes but also string attributes.
I have the feeling that delegation for IDREFs and this proposal are very related, and maybe a generic mapping thing ask you mention could be a good idea and include both.
Then delegation of string attributes could be a different topic.

Not totally sure yet as I'm still trying to understand the different use cases. Also having some use case that combines delegation and reflection might be nice to have. To understand better what are the actual needs.

[Westbrook]

Interesting insight. I’m not sure where you’d want to reflect a string out of a shadow root when you could have access to an element and you wouldn’t have access to that string from above. The only place I could think of right off might be dynamic translation contexts, but am not 100%. I’ll think about that some more and see if there’s a good demo to add to the explainer.