Hi Alice, Could you update the chromestatus entry <https://chromestatus.com/feature/6244885579431936>'s overview to explicitly list out all of the changes to web API IDLs, and any other details needed to understand what is proposed for shipping? I'm getting a bit confused about the status.
Thanks! On Wed, Feb 5, 2025 at 7:03 PM 'Dan Clark' via blink-dev < blink-dev@chromium.org> wrote: > Should this Intent be considered as including ariaOwnsElements > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/aria_relationship_attributes.idl;l=17;drc=3746ad65cf4dcd5217ed68c6a72aa6bf0f05ea0b>? > That was split off into a separate flag from the other properties here > <https://chromium-review.googlesource.com/c/chromium/src/+/5752663> and > it doesn't look like https://github.com/w3c/aria/issues/2266 has come to > any definite conclusion yet. > > I think the other properties are in a good state and I'm excited to see > them ship. It would be great to clarify what the plan is for > ariaOwnsElements as it's not yet clear to me that that one is ready. > > -- Dan Clark > > On Tuesday, February 4, 2025 at 3:10:04 AM UTC-8 Daniel Bratell wrote: > >> LGTM1 >> >> /Daniel >> On 2025-02-04 06:40, Alice Boxhall wrote: >> >> After many delays, I think this is finally ready for another look. >> >> On Thursday, February 1, 2024 at 4:47:45 PM UTC+11 dom...@chromium.org >> wrote: >> >> Very exciting to see this! >> >> On Thu, Feb 1, 2024 at 12: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 >> >> >> These specs are incompatible with each other, because >> https://github.com/w3c/aria/pull/1876 has not yet been merged. Do you >> think it'll be possible to get that merged soon? >> >> >> This has now been merged. >> >> >> >> >> 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. >> >> >> Can you confirm whether the scope of this intent is element reflection >> only? Or does it include ElementInternals support as well? >> >> (Coincidentally, I saw you filed this bug >> <https://bugs.chromium.org/p/chromium/issues/detail?id=1518693> which >> seems to state that the ElementInternals support is currently not working.) >> >> >> I had originally intended this to be only element reflection, but the >> AriaMixin properties on ElementInternals are now mapped through to >> accessibility APIs as well, so I think they should be in scope. >> >> >> >> Blink component >> Blink>DOM >> >> TAG review >> https://github.com/w3ctag/design-reviews/issues/134 >> >> TAG review status >> Issues addressed >> >> >> This tag review seems to be for AOM in general, as of its 2018 shape. I'm >> not sure there's been a lot of discussion as to where it ended up, with >> element reflection. Do you know of any TAG review or comments on the latest >> API? >> >> >> I don’t know of any further TAG review specific to this API. >> >> >> >> However, I think this qualifies for an exception >> <https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/>, >> under "already specified and accepted by the relevant standardization >> body", and "has already shipped in at least one other browser" >> >> >> Phew! >> >> >> >> >> >> 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. >> >> 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. >> >> >> From what I understand, WPT allows some testing of accessibility tree >> mappings these days, via WebDriver hooks. For example: >> >> - These tests appear to test the computed role >> <https://github.com/web-platform-tests/wpt/tree/master/wai-aria/role> >> - These tests appear to test the computed accessible name >> <https://github.com/web-platform-tests/wpt/tree/master/accname> >> >> IIUC, the above test shows that content attributes (like <div >> role="region">) are reflected correctly in the accessibility tree. Would it >> be possible to add similar tests for the corresponding JavaScript code? >> Maybe that's not possible for most of the complex element relationships >> that this I2S is about, but I think you should be able to use element >> reflection to influence accessible name computation, at least? I don't >> think they need to be exhaustive, but just some tests to catch issues like >> the >> above-mentioned bug >> <https://bugs.chromium.org/p/chromium/issues/detail?id=1518693>. >> >> >> Flag name on chrome://flags >> None >> >> Finch feature name >> None >> >> Non-finch justification >> None >> >> >> I believe the recent guidance is that all new features should be guarded >> by a base::Feature flag, which then generates a Finch feature automatically. >> >> >> There is now a feature flag, “EnableAriaElementReflection”. >> >> >> >> >> >> 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 >> >> >> https://github.com/whatwg/html/pull/8496 contains a consolidated list of >> spec issues related to this area. The ones that seem relevant to this >> intent are https://github.com/whatwg/html/issues/8545 and >> https://github.com/whatwg/html/issues/8544. Can you tell us whether the >> spec changes that might come out of those issues, could have back-compat >> concerns? >> >> >> I think https://github.com/whatwg/html/issues/8545 has more or less been >> overtaken by events, given this API has been shipping in WebKit for some >> time. Given the only viable solution proposed was to change the API to use >> ObservableArray, this would obviously be a breaking change to a shipping >> API at this point. >> >> I believe the WebKit implementation adopts Anne's proposal in >> https://github.com/whatwg/html/issues/8544 that elements referred to >> from ElementInternals don't need to be subject to the same Shadow DOM >> validation rules. >> >> >> >> 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+...@chromium.org. >> >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdb2a75c-5e7c-4475-b0a9-39870757ec62n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bdb2a75c-5e7c-4475-b0a9-39870757ec62n%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 visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3a1e3c7f-9bbf-4d35-8184-60d4b6bb4606n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3a1e3c7f-9bbf-4d35-8184-60d4b6bb4606n%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-escAV8TKRa0_hK2f%3DUMwKLKF4Xat3iozK4UeHYt4G3Q%40mail.gmail.com.
