-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User agents must not support aria-owns across shadow root boundaries #2266
Comments
definitely wondering what a good use case would be for someone to need to aria-owns parts of a custom elopement's shadow dom into the light dom. it's not like it'd even be a restriction without precedent, with closed root shadow DOM custom elements not allowing styles from the light DOM to modify the styling of the shadow dom parts. unless someone has a really good use case for this, i don't have a problem with this limitation, especially if it's a lot of dev effort for potentially little gain. |
Image maps could have the same issue, with referenceTarget.
…On Fri, Jun 28, 2024 at 12:38 PM scottaohara ***@***.***> wrote:
definitely wondering what a good use case would be for someone to need to
aria-owns parts of a custom elemement's shadow dom into the light dom.
it doesnt' even seem like a restriction that doesn't have precedent, with
the fact that people can make it so light dom styles don't impact shadow
dom elements.
unless someone has a really good use case for this, i don't have a problem
with this limitation, especially if it's a lot of dev effort for
potentially little gain.
—
Reply to this email directly, view it on GitHub
<#2266 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZUIYX6G6QYJUFWE3KTZJWGQTAVCNFSM6AAAAABKCBKYLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXGI4DONJVGQ>
.
You are receiving this because you authored the thread.Message ID:
<w3c/aria/issues/2266/2197287554 ***@***.***>
|
This seems reasonable, though I can't (currently) think of a case where allowing aria-owns to refer into a shadow DOM would cause problems. I do agree that aria-owns is notoriously tricky though. CC @eeejay because he's working on ARIA element reflection and will likely have a better idea regarding any potential issues here. |
There were a lot of weird edge cases with aria-owns that perhaps weren't
foreseen, at least in our code. It's untrustworthy when combined with other
interesting markup.
…On Fri, Jun 28, 2024, 7:26 PM James Teh ***@***.***> wrote:
This seems reasonable, though I can't (currently) think of a case where
allowing aria-owns to refer into a shadow DOM would cause problems. I do
agree that aria-owns is notoriously tricky though.
CC @eeejay <https://github.com/eeejay> because he's working on ARIA
element reflection and will likely have a better idea regarding any
potential issues here.
—
Reply to this email directly, view it on GitHub
<#2266 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZRKUMXTC3RSLY5P75TZJXWKHAVCNFSM6AAAAABKCBKYLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJXG43DMMJXGQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Discussed briefly in triage: https://www.w3.org/2024/07/11-aria-minutes.html#t01 |
I chatted with Aaron about this some time back, and I agree that it makes sense to at least postpone shipping support for |
@nolanlawson fyi |
Given we're setting via |
Discussed in today's meeting: https://www.w3.org/2024/07/18-aria-minutes.html#t07 |
Would this also necessitate a IDL change, like: [CEReactions] attribute FrozenArray<Element>? ariaOwnsElements; to [CEReactions] attribute FrozenArray<PlaceholderName-Local???Element>? ariaOwnsElements; |
Related to this discussion, I have a change ready for submission in Blink which would put This would mean we could ship the remaining properties, but delay shipping any version of How would folks feel about that as a plan? Then we can work towards potentially shipping the non-shadow-crossing version and/or the shadow-crossing version without blocking shipping the remaining properties. |
+1
…On Tue, Aug 6, 2024 at 7:40 AM Alice ***@***.***> wrote:
Related to this discussion, I have a change
<https://chromium-review.googlesource.com/c/chromium/src/+/5752663> ready
for submission in Blink which would put ariaOwnsElements behind a
separate feature flag from the rest of the ARIA relationship properties.
This would mean we could ship the remaining properties, but delay shipping
*any* version of ariaOwnsElements (shadow-crossing or not) until we can
figure out the logistics, and do enough testing to make sure there are no
lurking issues with even the light DOM case (since there can be surprising
results when you're not using an ID-based attribute).
How would folks feel about that as a plan? Then we can work towards
potentially shipping the non-shadow-crossing version and/or the
shadow-crossing version without blocking shipping the remaining properties.
—
Reply to this email directly, view it on GitHub
<#2266 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKQAZVJS3EGPYDK7CNWNOLZQCYZVAVCNFSM6AAAAABKCBKYLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRGA4DGNZYG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I think we need to clarify what Chromium is doing here vs the requirements for all browsers. At this stage, we don't have explicit plans to disable or restrict ariaOwnsElements in the Gecko implementation. We *can * do that, but that would require spec changes, and in particular, there's an open question about whether this would require an IDL change. To be clear, I'm not saying we're not willing to consider this change, but it would require an additional patch for Gecko at this stage, so we do need to clarify exactly what that change should be.
Are you able to provide an example? That might help us make more informed decisions here. |
Agreed. I (personally) think it would be fine for Gecko to ship I think if Blink is going to hold off on shipping
Sorry, I could have been much clearer about this. I don't mean that there should be any difference, as specced, but more that the code in Blink which checks for aria-owns cycles (including when elements previously referred to get added to the page) assumes there will be actual IDs present in some places. Also, all of the existing tests for the crashy aria-owns cases use IDs, so we can't have good confidence yet that the non-ID cases are well handled. We should definitely fix all of that, but given aria-owns is significantly more complex in implementation than the other attributes, I don't want to block shipping those on fixing all the potential edge cases in aria-owns. |
Because aria-owns is notoriously difficult for user agents to implement in a stable and predictable manner, I suggest that aria-owns cannot cross shadow root boundaries.
Pointing into an ancestor shadow root is already something user agents would hopefully not allow, because it would create a cycle.
I would also like to make it impossible to point down via ariaOwnsElements, referenceDelegate, or any other cross-shadow root ARIA technique.
This is my recommendation unless someone can come up with a legit use case.
@jcsteh @scottaohara @cookiecrook @alice
The text was updated successfully, but these errors were encountered: