- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Jul 2022 16:20:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `disallowing pseudos in :has()`, and agreed to the following: * `RESOLVED: Disallow all current pseudo-elements inside of :has(), allow future pseudo-elements to define that they are valid if useful/possible.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: disallowing pseudos in :has()<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7463<br> <TabAtkins> fantasai: Proposal was to make selector invalid if a pseudo-element is inside of :has()<br> <emilio> +1<br> <fantasai> TabAtkins: object to that as a general thing, because the reason we were doing that was because of conditional pseudo-elements (conditional on propeties)<br> <fantasai> TabAtkins: but shared element transitions has use case for checking existance of pseudos<br> <fantasai> TabAtkins: much more awkward API if we don't have ability<br> <fantasai> TabAtkins: outside of that, I think we should make a list of pseudo-elements that are allowed, and disallow the rest<br> <fantasai> TabAtkins: so the shared element transition ones, and just because they don't have an effect (because they exist at all times), ::marker/before/after<br> <fantasai> TabAtkins: but I can go either way on that<br> <fantasai> TabAtkins: wouldn't do anything<br> <fantasai> TabAtkins: but need a list for those that don't create cycles<br> <TabAtkins> fantasai: Prefer to make things invalid rather than valid but meaningless<br> <TabAtkins> fantasai: If we need to have exception for SET pseudos, fine, but since most pseudos won't make sense we shoudl disallow all others.<br> <TabAtkins> fantasai: Can alway smake them valid later, less likely to cause problems that way<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: I agree with "list of the ones taht work"<br> <TabAtkins> dbaron: Skeptical about putting before/after/marker on that list.<br> <TabAtkins> dbaron: Not sure the statement they always exist makes sense.<br> <TabAtkins> dbaron: Do before and after exist on replaced elements? Does marker exist on non-list items?<br> <TabAtkins> dbaron: I think the spec says yes to that last one, which I find confusing.<br> <bramus> `::backdrop` might also be a handy one to allow, could unblock `:top-layer` as that would become `:has(::backdrop)`<br> <fantasai> bramus, that's just weird<br> <TabAtkins> TabAtkins: Fine with just disallowing before/after/marker<br> <faceless> Aren't they all defined to not exist on items with display:none?<br> <dbaron> s/I think the spec says yes/Not sure what the spec says/<br> <TabAtkins> astearns: Do we have the allowlist or blocklist?<br> <TabAtkins> fantasai: Proposal is an allowlist, assume invalid otherwise<br> <TabAtkins> astearns: What's the allowlist?<br> <TabAtkins> fantasai: The SET pseudos<br> <TabAtkins> astearns: what about bramus' suggestion about ::backdrop?<br> <TabAtkins> fantasai: I think it's a little weird. Not really needed, should do that as a :top-level instead.<br> <vmpstr> ntim:<br> <TabAtkins> ???: "Does ::backdrop exist?" is also not clear<br> <TabAtkins> ntim: Still think it's weird if the state can change<br> <TabAtkins> astearns: So seems the proposed resolution is that all current pseudo-elements in :has() are invalid, but allow for future pseudo-elements to define that they work<br> <chris> That sounds good to me<br> <TabAtkins> ntim: What does "invalid" mean?<br> <TabAtkins> TabAtkins: Means "invalid" - the selector inside of :has() is dropped.<br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: Disallow all current pseudo-elements inside of :has(), allow future pseudo-elements to define that they are valid if useful/possible.<br> <chris> q+<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7463#issuecomment-1196971909 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 27 July 2022 16:20:21 UTC