Hello Alice, I have no clue what you are talking about. This is all technology and I have no clue of what it is, ma’am, so if you can explain this in plain English, I would appreciate it.
Just for your information someone is emailing all of you and it is not me. Our you a Technology company are you guys hackers or are you guys helpers because I am absolutely actually I’m scared to see all this technology talk. Are you people tracking me I see there’s a thread and a lot of other things but I do not understand it. I’m sorry, but I do need an explanation because I am going to be turning in my phone to the police department because I am being stuck and I don’t know if it’s you people or somebody else so please if you can be kind and call me, I would appreciate it. Thank you, Elsa On Wed, Jan 31, 2024 at 3: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). > > (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.) > > > 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/2e4f1290-a652-4901-9cba-2de31ea6ed26n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2e4f1290-a652-4901-9cba-2de31ea6ed26n%40chromium.org?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%2B2exUP7fiBp8wRU%2BnM-EZHBaEhFQhLRgg1E_%2BC6EpKrFw%40mail.gmail.com.
