Intent to Implement: Element Reflection

[Meredith Lane]

Contact emails mere...@chromium.org,abox...@chromium.org Explainer https://github.com/WICG/aom/blob/gh-pages/explainer.md#reflecting-element-references Design docs/spec Specification: https://whatpr.org/html/3917/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element TAG review https://github.com/w3ctag/design-reviews/issues/134 Summary This feature allows for ARIA relationship attributes to be reflected in IDL as element references rather than DOMStrings. Motivation This would allow specifying semantic relationships between elements without the need to assign globally unique ID attributes to each element which participates in a relationship. Moreover, this would enable authors using open ShadowRoots to specify relationships which cross over Shadow DOM boundaries. Risks

Interoperability and Compatibility Other browser vendors have been actively involved in shaping the API, and are present on the pull request thread, and supportive of the general idea. None have begun implementation. This initial implementation only effects a small set of ARIA attributes, so should be easily implementable in other browsers. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals Ergonomics This feature is being implemented on the AriaAttributes interface mixin, and rolled out as part of AOM Phase 1.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes WPT tests will be included with implementation. Tests for the initial implementation of single element reflection attributes can be seen at: https://github.com/web-platform-tests/wpt/pull/18344 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/6244885579431936

[Anne van Kesteren]

On Wed, Aug 21, 2019 at 3:45 PM Meredith Lane <mere...@chromium.org> wrote:
> Moreover, this would enable authors using open ShadowRoots to specify relationships which cross over Shadow DOM boundaries.

I thought the idea was that this would allow you to reference an
element in the light tree from a shadow tree, regardless of the mode
of the shadow root. And in particular it would not allow you to
reference something inside the shadow tree from the light tree, even
if the mode is open. I briefly looked at the PR again and didn't see
anything branching on "open", but I might have missed it.

[PhistucK]

This is one of the reasons why I avoided adding accessibility support when I would have otherwise - the ID requirement.

Perhaps a bit off topic, but related - do/can the label and datalist (and any other that accepts an ID) attributes get the same treatment?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hJ5mExVKo-4c%3DzV%2BBg_wFEJnQovyPEZCmg2DbRQgn5SQ%40mail.gmail.com.

[PhistucK]

Oops, I meant the HTMLLabelElement.prototype.htmlFor and HTMLInputElement.prototype.list attributes (and a few more), both of which are currently read-only for unknown reasons.

It would be helpful if they accepted HTMLElement (I could live with HTMLLabelElement.prototype.control, which is of type HTMLElement, but it is also read only).

☆PhistucK

[Alice Boxhall]

+Domenic Denicola 

We discussed these attributes when designing element reflection. 

I interpret the comment from Domenic that I linked to as saying we couldn't use this exact system for htmlFor, since it wouldn't be backward compatible (as it's currently a string), but we could add a parallel IDL attribute named for, which is reflected. Since htmlFor is read-only, we wouldn't be creating conflicts.

For list and form, based on the same comment I think there might be more spec work necessary to explain how the getters work.

It'll probably be easiest if we wait until things have settled with the ARIA attributes, since they are completely new to the DOM API and we can experiment more with them to iron out all the edge cases, and then we can start going back to see which existing APIs may be able to be ported.

Cheers,

Alice

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KVLcLF4HUNh8%2BE8Ov%2BOUrNXQrDHJzbVaRjr2ZTQ5vmbg%40mail.gmail.com.

[PhistucK]

I think HTMLLabelElement.prototype.control can be used instead of HTMLLabelElement.prototype.htmlFor. I mistakenly wrote that htmlFor specifically is read only (that message went through a few revisions ;)).

Anyway, I am really looking forward to the next iteration of this that includes non-ARIA attributes.

ARIA attributes are nice, but <label> is the most minimal accessibility element that also provides very nice and actually helpful user experience to users with and without disabilities (you click on the label and the input field is focused/checked), therefore being a huge incentive to developers as well (so they are more likely to use it, especially since they can be easily implemented), so it feels more important to me, but I understand the complexity and I will wait. ;)

☆PhistucK

[mere...@google.com]

Yes, Anne, you are correct! The PR states states that the given value must be a descendant of the element's shadow-including ancestors, which means that an element in the shadow tree can reference something in light DOM, but not the other way around. Sorry, the description I gave in the i2i was perhaps a bit *too* minimal.