Hi there, Yes, I'm now (finally) working on this again :) Will send a longer response once I have a more meaningful update to give.
Thanks Alice On 2024-08-08 02:04, Daniel Bratell wrote: > 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 -- 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/9ed7612668cdf2986ba5b8f16e0f35a7%40igalia.com.
