- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 18:15:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-cascade] Evaluate cascade order of ::slotted and global styles in the same conditions`, and agreed to the following: * `ACTION: lea to create a meta issue on shadow DOM styling and what needs to be solved` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> [presentation logistics chatter]<br> <kbabbitt> lea: looks like this is about well known problem in web components space of slotted having low specificity<br> <kbabbitt> ... anything from outside overwrites anything from shadow dom when they target same element<br> <kbabbitt> .<br> <kbabbitt> ... run in to same problem with host<br> <kbabbitt> ... less a problem with part since you need to be very specific<br> <kbabbitt> ... but these problems keep coming up with slotted and host<br> <kbabbitt> ... even a css reset on outside will override styles on host<br> <kbabbitt> ... this is proposing that shadow dom styles fight with global styles at same specificity<br> <kbabbitt> ... basically they expect that shadow dom styles have specificity to resolve conflights with light dom styles<br> <kbabbitt> ... which I think would make sense<br> <kbabbitt> ... but would not be web compatible<br> <kbabbitt> ... but problem needs solving<br> <kbabbitt> ... it means component cannot rely on styling itself<br> <kbabbitt> ... can't use !important since it's a separate origin<br> <kbabbitt> ... if you don't use !important, anything from shadow dom has more important<br> <kbabbitt> ... if you use !important everything has higher priority<br> <kbabbitt> ... none of these are ideal<br> <kbabbitt> ... you want component users to be able to style components<br> <kbabbitt> ... but also need to be able to provide defaults<br> <kbabbitt> ... this is something we keep running into<br> <kbabbitt> ... adthis point, I don't think it's web compatible to change<br> <kbabbitt> ... which brings us again to having slotted as a combinator<br> <kbabbitt> ... there's no way to override this, no escape hatch<br> <kbabbitt> ... no special layer people can use<br> <kbabbitt> astearns: do you have a solution to summarize?<br> <kbabbitt> lea: solution I proposed before was to make slotted a combinator<br> <kbabbitt> ... would also solve a bunch of other problems<br> <emilio> q+<br> <kbabbitt> ... another issue about this<br> <astearns> ack dbaron<br> <kbabbitt> ... that by itself doesn't solve, but it solves other problems and doesn't have web compat problem so it can have different specificity<br> <kbabbitt> dbaron: part of my intuition here is that one weird thing here is that if you want to intermix things that come from inside and outside component<br> <kbabbitt> ... and you need to somehow make up how those appear in order<br> <kbabbitt> ... because cascade at some level relies on order<br> <kbabbitt> ... and if we get rid of distinction between inside vs outside we need to define order<br> <lea> q?<br> <kbabbitt> ... one weird thing is that order isn't obvious from how stylesheets get linked to different pieces<br> <lea> q+<br> <kbabbitt> ... not obvious that this declaration came i the order before or after that one<br> <kbabbitt> ... this observation, off the cuff, makes me wonder if it would help to have a syntax or component to inject a set of rules into containing page at specific place in the order<br> <kbabbitt> ... almost certainly very beginning or very end of order<br> <kbabbitt> ... though presumably then those rules would only apply to component itself<br> <kbabbitt> ... thus you wouldn't need to worr about collisions<br> <kbabbitt> ... not entirely sure that makes sense, but not sure slotted combinator will solve<br> <lea> qq+<br> <kbabbitt> ... even with that, we need sensible proposal for order for cascade to work together<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to dbaron<br> <kbabbitt> lea: as I mentioned, slotted doesn't solve the problem, just gives us an avenue to work around web compat<br> <lea> s/slotted doesn't solve the problem/a slotted combinator doesn't solve the problem/<br> <kbabbitt> dbaron: I recognize that, just saying that even if we use that as a hook, we still need not just a defined order but a sensibly defined order<br> <lea> q+<br> <astearns> ack emilio<br> <kbabbitt> emilio: was going to comment on same line<br> <kbabbitt> ... don't think slotted combinator helps<br> <kbabbitt> ... first it can be mixed with other selectors, might care about host and whatnot<br> <kbabbitt> ... also becomes subtle to handle because you want to get all the rules that go in a particular spot together<br> <kbabbitt> ... poking at selector is not a great way to do that<br> <kbabbitt> ... potential alternative that could work and give some flexibility is some sort of wrapping at-rule<br> <kbabbitt> ... we need to define requirements of this properly<br> <kbabbitt> ... because you may want to inject at beginning or among other rules, or something else<br> <kbabbitt> ... I don't think we thought about specificity of slotted [??]<br> <kbabbitt> ... with intent of them competing for other spots<br> <kbabbitt> ... my point is, I think some way of grouping rules that you want to sort outside is probably an easier avenue to explore<br> <kbabbitt> ... easier to understand, this weird selector does same thing as this old selector but in subtly different way<br> <kbabbitt> ... also allows tweaking, inject beginning, inject at end, somewhere else<br> <kbabbitt> ... question is how this interacts with current cascade sorting parameters<br> <kbabbitt> ... might want to behave as source order, always after other scope, or before<br> <miriam> q+<br> <kbabbitt> .... assuming the thing people want is to make specificity work as if shadow dom wasn't involved<br> <astearns> ack lea<br> <kbabbitt> lea: speaking of requirements, one is that the surrounding page should not have to do anything weird for things to just work<br> <kbabbitt> ... some ideas floated at points were, special layer name, important layer, stuff like that<br> <kbabbitt> ... for component it's ok to do weird things<br> <kbabbitt> ... surrounding page should noy have to do anything for tyhings to just work<br> <kbabbitt> .. want to drop component into page and have it just work<br> <kbabbitt> ... also one thing to keep in mind defining layer is that it's not just one layer<br> <kbabbitt> ... nested shadow roots, components containing componentys<br> <kbabbitt> ... something can be in shadow dom but function as light dom for components it includes<br> <kbabbitt> ... whatevber we define needs to work in that context<br> <kbabbitt> ... don't think it matters what order we define, maybe everything after page css<br> <kbabbitt> ... or same kind of order as if you were using style or linke element where style appears<br> <kbabbitt> .<br> <kbabbitt> ... any order is better than no order<br> <kbabbitt> ... though I feel weird when bikeshedding the details<br> <kbabbitt> ... core problem is how we're going to change this<br> <kbabbitt> ... what would syntax look like without combinator<br> <kbabbitt> ... can't change how ?? behaves<br> <emilio> q+<br> <kbabbitt> s/??/::slotted/<br> <kbabbitt> ... and I hope we don't introduce some weird word or parameter after it<br> <kbabbitt> ... we have another issue for this meeding for allowing complex selectors in slotted<br> <kbabbitt> ... this could turn in to a combinator piece by piece<br> <astearns> ack miriam<br> <lea> s/this could turn in to a combinator piece by piece/so we're basically turning it into a combinator piece by piece, without the benefits that come with that/<br> <kbabbitt> miriam: to build on what emilio was saying<br> <kbabbitt> ... if we had any order either the component styles are firsty or they're lad<br> <kbabbitt> ..they'd compete not only in specificity but in layers<br> <lea> +1 to what miriam is saying, great point<br> <kbabbitt> ... [missed] that might be right<br> <kbabbitt> .... maybe there's an at-rule that relies on what component is doing, what page is doing<br> <kbabbitt> ... like emilio. curious about defining problem better<br> <astearns> ack emilio<br> <kbabbitt> emilio: wanted to emphasize defining what we need<br> <kbabbitt> ... constrains solution space<br> <kbabbitt> ... if we only care about competing with unlayered styles outside scope, a simple at-rule or some other opt in might do<br> <kbabbitt> ... if we need to make layers cross trees somehow, that's a whole different problem<br> <kbabbitt> ... I think we need to ... some sort of grouping at-rules feels like most flexible solution<br> <kbabbitt> ... also don't want to fixate on a solution without knowing everything we need to solve<br> <lea> q?<br> <kbabbitt> astearns: I think I'm hearing that people would like to define the problem we're trying to solve<br> <kbabbitt> ... not sure, is the basic problem how shadow dom styles can participate in ordering to work with light dom styles?<br> <kbabbitt> ... is it an ordering issue, finding a way of defining how some shadow dom styles can be ordered with outer page styles?<br> <kbabbitt> lea: problem is not order; it behaves likle different origin entirely<br> <kbabbitt> miriam: letting them interact as though in same context<br> <lea> btw the issue I mentioned: https://github.com/w3c/csswg-drafts/issues/7922<br> <kbabbitt> astearns: should we take back to issue with resolution that we want to figure out how to let these separate sets of styles interact?<br> <kbabbitt> ...before working on syntax solution?<br> <kbabbitt> ... trying to suggest something we can do for this issue, would it be better to leave this one be for now?<br> <kbabbitt> lea: wonder if there's web compat research we can do?<br> <kbabbitt> ... definitely won't be compatible<br> <kbabbitt> emilio: 90% sure that if I make a change and try to start Firefox, it won't look like Firefox<br> <kbabbitt> astearns: suggestions for how we should proceed?<br> <kbabbitt> emilio: think it might be useful to have a more focused issue on defining exactly what we need<br> <kbabbitt> ... this discussion has gone on in that issue for a while<br> <kbabbitt> ... not sure that would be in practice vs continuing in this issue<br> <kbabbitt> miriam: there are several related issues here<br> <kbabbitt> ... maybe there's a meta issue that needs to nail down the problem instead of individual issues<br> <kbabbitt> lea: I think that makes a lot of sense<br> <kbabbitt> ... need to look at all issues around targeting shadow dom styles together<br> <kbabbitt> ... I could take an action item for meta issue<br> <kbabbitt> astearns: let's leave this issue's discussion there<br> <kbabbitt> ACTION: lea to create a meta issue on shadow DOM styling and what needs to be solved<br> <kbabbitt> lea: to discuss in next telcon or f2f?<br> <kbabbitt> astearns: don't know that a deadline is nececessary<br> <kbabbitt> ... when we come to sort of consensus in that issue, it will be in next agenda<br> <kbabbitt> ... we could set a deadline but I've never seen them work in CSSWG<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6466#issuecomment-2773352063 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 18:15:16 UTC