Test :host(:has(...)) and :host:has(...) selectors #47441
Conversation
|
Ooh, good question about |
|
Also, I appreciate that you're using the standard reftest for success, but I do prefer tests which fail with red when possible - mind putting the size and a red background on those elements with a lower-specificity selector, so the successful test will just override the color and make it green? |
|
I can dig into expanding the red/green results next week! |
|
@tabatkins this should have the good red/green fail => pass delivery now. Let me know if there's anything else I can do to prepare this for merging. 🙏🏼 |
|
I've understood the current status of
In case of If this understanding is correct (please correct me if I missed something), it seems that the How about making the test cases as tentative until there are some more clarification on the restriction? |
…s#47441) * Test :host(:has(...)) and :host:has(...) selectors * Add clear visual fail state
|
El sáb, 17 de ago. de 2024 19:50, Byungwoo Lee ***@***.***>
escribió:
… I've understood the current status of :host(:has()) as invalid case (w3c/csswg-drafts#7953
(comment)
<w3c/csswg-drafts#7953 (comment)>
):
This means that :host(:has(...)) is invalid, since its arguments are
inherently complex selectors (because they're relative, so there's a
combinator), so imposing a compound-selector restriction on them makes all
possible arguments invalid.
In case of :host(:has(section)), even if the argument of :has() is
expressed as a compound-selector(selection), it has the descendant
combinator (' ') at leftmost which represents the ancestor-descendant
relationship between the :has() anchor element and the subject element of
the :has() argument selector.
If this understanding is correct (please correct me if I missed
something), it seems that the :host(:has(section) case need to be treated
in the w3c/csswg-drafts#7953
<w3c/csswg-drafts#7953> similar to the other
cases that violate the compound-selector restriction on :host() (e.g. :host(:has(>
.a), :host(:is(.a .b))).
How about making the test cases as tentative until there are some more
clarification on the restriction?
—
Reply to this email directly, view it on GitHub
<#47441 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BKGAKPU2CEJACNSBAS7N7GLZR74YBAVCNFSM6AAAAABL6BUH4WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJVGA2TQMRSG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
:host(:has(...))works really well is Safari, sort of well in Firefox and not at all in Chrome. It's not really spec'd (IIUC) but normalizing on the output expected by developers and provided by Safari already seems like a good destination to work towards:host:has(...)doesn't work anywhere and isn't spec'd anywhere (IIUC) but this is how I would tentatively expect it to work, similar to that way the:host(.class)references a class "outside" of the shadow root and:host:afterreferences a pseudo element inside of the shadow root.Both of these types of selectors would likely benefit from various combinator tests and