- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Sat, 28 Sep 2024 00:05:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade] may need to define cascading order between sibling encapsulation contexts`. <details><summary>The full IRC log of that discussion</summary> <emilio> dbaron: one of the steps in the cascade, between origin and specificity<br> <emilio> ... (don't remember how it interacts with layers)<br> <emilio> ... is that rules based on tree scopes cascade separately<br> <emilio> ... so rules from outside the shadow root generally wins, except !important which goes the other way around<br> <emilio> ... there's spec text that assumes that only tree scopes relevant to styling are outside / inside<br> <emilio> ... but in some edge cases you can have sibling scopes<br> <emilio> ... one of these is if we allow ::part() after ::slotted()<br> <emilio> ... the other is the /slotted/ combinator<br> <emilio> ... so in these cases you have stuff in one shadow tree that affects styles in a sibling shadow tree<br> <emilio> ... the cascade spec is not clear about this<br> <emilio> ... I don't really have a solution, thinking about this makes my head hurt<br> <emilio> ... for an impl perspective is probably easier not to cascade them together<br> <emilio> ... because having them together may be painful<br> <emilio> ... the problem here is we don't define what happens<br> <emilio> ... I don't have very strong opinions<br> <emilio> q+<br> <dandclark> q+<br> <emilio> Rossen: tab seems to propose tree order<br> <astearns> ack lea<br> <Zakim> lea, you wanted to say, it's definitely not high priority. Q: if we decide to not allow it now, is that something we can revisit later or will we run into web compat?<br> <lea> q+<br> <Rossen9> ack emilio<br> <dandclark> emilio: The shadow incluuding tree order thing makes sense except I don't know how to define !important in that case beacuse there's no inside or outside. Not clear if it should be reversed or not, that seems weird. So don't have clear answer.<br> <emilio> dandclark: Was going to agree with tab<br> <emilio> ... it generalizes that definition<br> <emilio> ... but agree with emilio that it seems weird to do the reverse from !important<br> <Rossen9> ack dandclark<br> <Rossen9> ack lea<br> <emilio> ... unclear if there's something better<br> <emilio> lea: not quite sure I understand so might be off<br> <emilio> ... not sure how making slotted a combinator relates to this<br> <emilio> ... the whole point was to circumvent some of the issues<br> <emilio> ... wouldn't it be the same as<br> <emilio> ... you're using regular selectors to target the slotted elements<br> <emilio> ... so regular cascade rules should apply<br> <emilio> ... if it's about styling inside and outside we have :host and regular selectors too<br> <emilio> ... maybe I'm misunderstanding<br> <emilio> q+<br> <emilio> dbaron: I think it'd be the /slotted/ combinator in combination with ::part or something else<br> <Rossen9> ack emilio<br> <emilio> dbaron: I think I was thinking was something like /slotted/ element::part(foo) from inside a component<br> <dandclark> emilio: No because the outside is not a sibliing<br> <emilio> ... then slotted looks at the parent tree scope, and ::part() could be a child of the parent tree scope (thus a sibling)<br> <emilio> lea: wouldn't that be the same as targetting the part from outside?<br> <emilio> emilio: no because outside scope wouldn't be a sibling<br> <emilio> dbaron: the other possibility is that some of the rules are not desirable with ::slotted()<br> <emilio> lea: that's a big motivation for the slotted combinator<br> <lea> that any CSS you include in ::slotted() has lower precedence than litterally any other CSS, including the universal selector, CSS resets, generic type selectors etc<br> <emilio> q+<br> <lea> unless you use !important, which is too strong<br> <Rossen9> ack emilio<br> <dandclark> emilio: I am confused because the slotting behavior doesn't fix that layout<br> <emilio> lea: my understanding was that ::slotted() behaves like this because it's a pseudo of the slot<br> <emilio> emilio: that's not correct<br> <emilio> lea: so this is the reason ::slotted() doesn't work?<br> <emilio> dbaron: yes, the reason ::slotted() is so weak is this rule about encapsulation context<br> <emilio> ... which I think makes sense for ::part()<br> <emilio> ... but maybe it's not the right decision for ::slotted()<br> <emilio> lea: but now we cannot change ::slotted() because of webcompat<br> <emilio> ... so /slotted/ would work<br> <emilio> ... btw I chatted with rniwa, and his implementation concerns are about targetting descendants and other elements<br> <emilio> ... but if we restrict what comes after to a compound selector he's fine with it<br> <emilio> q+<br> <Rossen9> ack emilio<br> <lea> q+<br> <dandclark> emilio: So that is correct, that was an implementation issue, but making @@@ doesn't help as long as we don't change the cascade spec in subtle ways.<br> <Rossen9> ack lea<br> <emilio> lea: it's clear we need to fix both<br> <keithamus> s/@@@/slotted combinator<br> <emilio> ... but we probably can't change how ::slotted() behaves because webcompat<br> <emilio> q+<br> <dandclark> emilio: I am not sure that's necessarily true. Does need some investigation . RIght now in the cascade spec all @@@ have hte same behavior. So it would feel weird to change the behavior only because multiple selectors can match<br> <dandclark> ...we could try to fix the cascade spec<br> <dandclark> ...but that's sort of tangential to this issue<br> <dandclark> ...but should do that if that's what we really want<br> <lea> https://github.com/w3c/csswg-drafts/issues/7922#issuecomment-2380098440<br> <emilio> lea: there are a lot of other things that need to be fixed, see ^<br> <keithamus> q+<br> <dandclark> emilio: Seems there's no clear consensus<br> <emilio> ack emilio<br> <Rossen9> ack keithamus<br> <emilio> keithamus: Can you style `:has()` with a combinator? So you'd do `:has(/slotted/ something)`<br> <emilio> lea: yeah `:has()` supports relative selectors<br> <emilio> ... first example in mdn<br> <emilio> Rossen9: let's take this back to the issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10889#issuecomment-2380301569 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 28 September 2024 00:05:15 UTC