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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Nixz41KJKXtd7TWQOrS%3DBWVOjSVKQJfqF_9OH6Cjqomg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/a9ad1774-7794-4d93-a26d-21e618748016%40gmail.com.
