Look I don’t know what you guys are talking about. This is gonna be the last time I’m asking you give me a call right now or I am delivering this to the police department. I’m not playing around anymore I do not know who you people are. I don’t know if you guys are tracking something selling something delivering something you don’t even know who I am ANNA and I somebody is sending you these messages and it’s not me and I’m giving you my phone number area code 559-871-6945.
On Wed, Jan 31, 2024 at 4:16 PM 'Vladimir Levin' via blink-dev < blink-dev@chromium.org> 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/CAPLTm%2B3Evgv5HMZXbiyYjP%3D4JObhfxiaO4KumVSyXQ7%2B%2BuqUpg%40mail.gmail.com.
