Hi from the future!
About Element Reflection, I'm curious if anyone is still working on
this or if we should let go of this intent until some future time?
/Daniel
On 2024-02-01 01:16, 'Vladimir Levin' via blink-dev wrote:
On Wed, Jan 31, 2024 at 6:14 PM Alice Boxhall <al...@igalia.com>
wrote:
On Thursday, February 1, 2024 at 6:52:13 AM UTC+11
vmp...@google.com wrote:
On Wed, Jan 31, 2024 at 10:10 AM alice <al...@igalia.com> wrote:
Contact emails
al...@igalia.com, mere...@chromium.org
Explainer
https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
Specification
https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
https://w3c.github.io/aria/#ARIAMixin
Summary
This feature allows for ARIA relationship attributes to be reflected
in
IDL as element references rather than DOMStrings.
Note: This intent specifically concerns the ARIA attributes using
Element Reflection, i.e. the attributes in the ARIAMixin interface
with
a type of Element or FrozenArray<Element>. popoverTargetElement,
which
also uses Element Reflection, is already shipping in Blink and
WebKit.
Blink component
Blink>DOM
TAG review
https://github.com/w3ctag/design-reviews/issues/134
TAG review status
Issues addressed
Risks
Interoperability and Compatibility
Gecko: Under consideration
https://github.com/mozilla/standards-positions/issues/200
https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
WebKit: Shipped/Shipping
(https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151)
Mentioned in STP release notes:
https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
Was shipped in Safari 16.4 but wasn't mentioned in release notes
there.
Web developers: Requested by Web Component authors in particular as
a
means to implement ARIA relationships for elements inside of Shadow
DOM.
I wonder if you had any feedback from framework authors that use
VDOM. For context, we were considering using element references for
a different feature, and couldn't overcome the fact that when
frameworks change DOM, sometimes Nodes and Elements are removed or
reused for a different purpose than when initially constructed (ie
the element that used to represent the first item in the list is now
used to represent the third item in the list).
I realize that this is asking a question very late in the design
process, but I'm just curious if that's a case that you considered
and if so how you reasoned about it.
To be honest, no, we didn't take VDOM into account.
I'd be curious to hear what specific cases you were running into
difficulty with, but it does seem like these paradigms are
fundamentally at odds with one another - if elements are unpredictably
destroyed and recreated, then it seems like using the string ID-based
version is going to be a better fit. This API is, at least, designed
to work with using the `setAttribute()` version, in that setting the
content attribute will cause any value set via the IDL attribute to be
discarded (and vice-versa).
The main use case for us was just matching elements automatically
across DOM mutations with a caveat that we were using CSS, not
attributes. We couldn't really get a sense of how stable our proposals
were because of the VDOM type of reordering. It might be worthwhile
for us to revisit that plan. I agree with you that I think your case
is a lot better, since it affects attributes being set, instead of
being some ephemeral state that the browser keeps track of.
(VDOM has always made me anxious for similar reasons - if elements
are unpredictably moved or destroyed, what happens if an assistive
technology was visiting those nodes in the accessibility tree when
that happens? But I have essentially no experience actually using
it, so presumably that can be managed in practice.)
I also agree with this sentiment. It seems like we want to rely on the
persistence of elements and their identity, but at the same time there
are a lot of optimized frameworks that are fast because they don't.
Activation
This feature is not completely polyfillable; ID references across
shadow
root boundaries are not possible to implement on top of existing
APIs.
WebView application risks
None
Debuggability
Developers can use console.log to access the value for IDL
attributes
set via this API, and the Accessibility pane to confirm that the
attributes are correctly reflected in the accessibility tree.
Will this feature be supported on all six Blink platforms (Windows,
Mac,
Linux, ChromeOS, Android, and Android WebView)?
Yes
Is this feature fully tested by web-platform-tests?
https://wpt.fyi/results/html/dom/aria-element-reflection.html tests
that
the reflection part of the API works correctly.
WPT doesn't yet offer a way to test the relevant accessibility tree
mappings.
Flag name on chrome://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://crbug.com/981423
Measurement
Per-attribute UseCounters:
V8Element_AriaActiveDescendantElement_AttributeGetter
V8Element_AriaActiveDescendantElement_AttributeSetter
V8Element_AriaControlsElements_AttributeGetter
V8Element_AriaControlsElements_AttributeSetter (etc)
V8ElementInternals_AriaActiveDescendantElement_AttributeGetter
V8ElementInternals_AriaActiveDescendantElement_AttributeSetter
V8ElementInternals_AriaControlsElements_AttributeGetter
V8ElementInternals_AriaControlsElements_AttributeSetter (etc)
Estimated milestones
123 or 124
Anticipated spec changes
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/6244885579431936
Links to previous Intent discussions
Ready for Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ
--
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/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.com.
--
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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Nixz41KJKXtd7TWQOrS%3DBWVOjSVKQJfqF_9OH6Cjqomg%40mail.gmail.com
[1].
--
You received this message because you are subscribed to a topic in the
Google Groups "blink-dev" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/chromium.org/d/topic/blink-dev/j8nZWueWc1s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a9ad1774-7794-4d93-a26d-21e618748016%40gmail.com
[2].
Links:
------
[1]
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Nixz41KJKXtd7TWQOrS%3DBWVOjSVKQJfqF_9OH6Cjqomg%40mail.gmail.com?utm_medium=email&utm_source=footer
[2]
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a9ad1774-7794-4d93-a26d-21e618748016%40gmail.com?utm_medium=email&utm_source=footer
