Re: [blink-dev] Intent to Ship: Element Reflection

[Domenic Denicola]

Very exciting to see this!

On Thu, Feb 1, 2024 at 12:10 AM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@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?


>
>
> 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. 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
 which seems
to state that the ElementInternals support is currently not working.)


>
> 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?

However, I think this qualifies for an exception
,
under "already specified and accepted by the relevant standardization
body", and "has already shipped in at least one other browser"


>
> 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
   
   - These tests appear to test the computed accessible name
   

IIUC, the above test shows that content attributes (like ) 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
.


> 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.


>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/981423
>
> Measurement
> Per-attribute UseCounters:
> V8Element_AriaActiveDescendantElement_AttributeGetter
> V8Element_AriaActiveDescendantElement_AttributeSetter
> V8Element_AriaControlsElements_AttributeGetter

Re: [blink-dev] Intent to Ship: Element Reflection

[Elsa Vega-Martinez]

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  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  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. 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 

Re: [blink-dev] Intent to Ship: Element Reflection

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 6:14 PM Alice Boxhall  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  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. 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

Re: [blink-dev] Intent to Ship: Element Reflection

[Elsa Vega-Martinez]

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  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  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. 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
> 

Re: [blink-dev] Intent to Ship: Element Reflection

[Alice Boxhall]

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  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. 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" 

Re: [blink-dev] Intent to Ship: Element Reflection

[Alice Boxhall]

On Thursday, February 1, 2024 at 4:01:32 AM UTC+11 Philip Jägenstedt wrote:

Hi Alice,

For testing of these in WPT, do you have some details on what's missing? 
It's already possible to get the accessible name and role for an element:
https://web-platform-tests.org/writing-tests/testdriver.html#accessibility


These attributes affect relationships between elements, which project into 
the accessibility tree in various ways. `aria-labelledby` does affect the 
accessible name, so we could write a test for that (which would actually go 
some way to demonstrating that these attributes affect the accessibility 
tree in general), but the remaining attributes affect things like 
accessible description computation (`aria-describedby`), accessibility tree 
structure (`aria-owns`), which element appears to have focus 
(`aria-activedescendant`), or how some assistive technology should provide 
hints to the user (`aria-flowto`, `aria-details`, `aria-owns`, 
`aria-errormessage`).
 

I suspect that won't help, but there's an experimental/tentative API being 
proposed for testdriver.js here:
https://github.com/web-platform-tests/wpt/pull/43773

Would that allow this feature to be tested more fully?


That would allow checking how tree structure is affected, so we could test 
at least one more attribute! I can't tell what other properties will be 
exposed in the tree, so I'm not sure about the rest.
 

Best regards,
Philip

On Wed, Jan 31, 2024 at 4:10 PM alice  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. 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.

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 

Re: [blink-dev] Intent to Ship: Element Reflection

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@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. 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.


> 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+unsubscr...@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/CADsXd2N%3DNU1EUUi6jSEwjoH6Vmo9qGOK82bpWMzB%2BniE4tC_3g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Element Reflection

[Philip Jägenstedt]

Hi Alice,

For testing of these in WPT, do you have some details on what's missing?
It's already possible to get the accessible name and role for an element:
https://web-platform-tests.org/writing-tests/testdriver.html#accessibility

I suspect that won't help, but there's an experimental/tentative API being
proposed for testdriver.js here:
https://github.com/web-platform-tests/wpt/pull/43773

Would that allow this feature to be tested more fully?

Best regards,
Philip

On Wed, Jan 31, 2024 at 4:10 PM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@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. 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.
>
> 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+unsubscr...@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/CAARdPYfUO1-g3wYvrvDw9oV9Hf%3DgHP9O%3DdKj5FsVu4OF4K%2BZeQ%40mail.gmail.com.