- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Mar 2021 18:01:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-scoping] Proposal for light-dom scoping/namespacing with re-designed `@scope` rule``.
<details><summary>The full IRC log of that discussion</summary>
<dael> Topic: [css-scoping] Proposal for light-dom scoping/namespacing with re-designed `@scope` rule<br>
<dael> github: https://github.com/w3c/csswg-drafts/issues/5809<br>
<dael> miriam: I have slides, but talk through without?<br>
<miriam> https://slides.oddbird.net/csswg/f2f2102/#slide-26<br>
<dael> miriam: Link ^<br>
<dael> [trying to see if miriam can present]<br>
<dael> miriam: I'll talk through them<br>
<dael> miriam: There has been several threads open about having a scoping in css<br>
<dael> miriam: There was even attempt in 2014 to spec it. not impl.<br>
<dael> miriam: Looking into it I found differences with shadow dom. Proposal is what is see is missing from shadow dom.<br>
<dael> miriam: Main goals are avoiding naming conflicts and expressing memebership in a scope. Similar to what shadow dom does which gives us scope and slots. Different from ancestor b/c lower bounderties. It actually belongs to the component<br>
<dael> miriam: A lot of tools out there try and do this manually. Putting together special selectors<br>
<dael> miriam: Other part is trying to capture sense of proximity. A light and dark theme and I need to style links in those. If I use descendant selector the second definition take precesendce when selected. What I want is the one that is closer.<br>
<fantasai> [slide 32]<br>
<fantasai> [slide 33]<br>
<dael> miriam: Why not shadow dom? Basic answer is shadow dom encapulation is high impact and dom centered. Element itself is the scope and that's hard bounderies in the dom. Strong isolation of bounderies.<br>
<fantasai> [slide 34]<br>
<dael> miriam: High power in the cascade as well. It overrides specificities<br>
<fantasai> [slide 35]<br>
<dael> miriam: Interesting proposals to improve, but don't resolve central issues. I think declaritive shadow dom is interesting. But not the same thing as we're trying to solve with views etc.<br>
<dael> miriam: I sometimes want lower bounds, outer bounds. But I want to do that and it's a presentational decision, not semantic. I don't want it tied to dom elements. I want overlap. I want to say what's in or out<br>
<fantasai> [slide 38]<br>
<TabAtkins> q+ when Miriam is done to express support<br>
<leaverou> q+<br>
<TabAtkins> qq+<br>
<dael> miriam: All these tools do it lower impact. It's reused across leements. Priority is handled through ownership rather then specificity<br>
<leaverou> q-<br>
<leaverou> q+<br>
<fantasai> [slide 40]<br>
<fantasai> [slide 41]<br>
<miriam> https://www.irccloud.com/pastebin/MtGSIIPT/<br>
<dael> miriam: Prop bringing back scope rule and scope pseudo class. Proposal is a syntax like &<br>
<dael> miriam: We get @scope and add a selector for outer bounds. Optionally add a to() with any number of lower bounderies. Anything within the rule would scope between selectors<br>
<dael> miriam: Scope selector is the root. It's implied when not used<br>
<fantasai> [slide 42]<br>
<fantasai> [slide 43]<br>
<dael> miriam: I have more details about exactly how I see boundry and selector matching working. Gone through tag review on how it would work. Final piece is this triggers proximity as part of cascade. When 2 scopes overlap inner scope is the fallback to specificity. When they're equal internal scope takes presedence.<br>
<dael> miriam: Some talk about being able to scope to a donut. Is it useful to have it as a selector in it's own right. Interesting and could look more<br>
<astearns> ack TabAtkins<br>
<Zakim> TabAtkins, you wanted to react to a previous speaker<br>
<dael> TabAtkins: I'm very happy to see this. Was happy to work with miriam early on. We tried to do light dom scoping earlier but that was substantially different. It was trying to interact similar leverl of intrusiveness as shadow dom<br>
<astearns> ack leaverou<br>
<dael> TabAtkins: This being a low thing is a really great and useful tool that compliments shadow dom and what we're doing. I'm a big fan of it<br>
<dael> leaverou: I would like to agree with TabAtkins this is highly needed. I support it<br>
<dael> leaverou: Elaborating on my point, I think propo consists of 2 parts. Name spacing use cases which are nesting within this new scope rule and the prozimity prioritization. And then there's the donut scope syntax. Anything related to selection logic isbetter in selectors. That gives it a JS API which gives you access to frequently needed queries<br>
<dael> leaverou: Worth exploring how the donut scope could be done through selectors syntax so @scoping can just have the scoping and not the selection<br>
<dael> leaverou: Does that make sense?<br>
<dael> fantasai: You're prop selector in addition to @scope where selctor is a limit on what's selected?<br>
<dael> leaverou: Yes<br>
<argyle> like `@scope .tabs - .panel {}` like this? where the dash is showing a range?<br>
<dael> fremy: Makes a lot of sense to me<br>
<fantasai> s/selected/selected, but doesn't affect the cascade/<br>
<Rossen_> q?<br>
<dael> florian: Seems worht exploring. Since interested in both parts, I'd like to first express support for the whole thing. We'll take everything here and then as we take this poss try to do donut in selectors. Don't insist on the donut thing to take this<br>
<astearns> ack fantasai<br>
<dael> leaverou: Both problems need solving<br>
<TabAtkins> Hm, I'm not sure how we would work a lower-boundary into the normal selector syntax<br>
<dael> fantasai: Question I have is, I want to understand impact on specificity. Previous @scope proposal which didn't have lower bound. Other difference is specificity, if you have more specific selector outside it overrides in the scope. In previous prop if you're inside a scope it overrides everything outside.<br>
<dael> miriam: That's right<br>
<TabAtkins> Currently, @scope basically *is* just a selector (allowing nesting)<br>
<dael> fantasai: Can you explain the reasoning behind why this is the appropriate choice?<br>
<dael> miriam: One thing, going back a ways as I teach CSS people expect this to be the default fallback. People are surprised by source order being the fallback. That was in my mind<br>
<florian> q+<br>
<dael> miriam: Also this is how all the tools currently work. Feels like it works well to me. Not trying to isolate strongly, trying to keep things from getting out, not from getting in<br>
<dael> miriam: Tools do it with an added attribute now, but that only increases spec by a small amount<br>
<dael> fantasai: This has less impact. Concerned it would cause...not give same results in a lot of cases. not convinced. When you add a class, you'd have to add more specificity.<br>
<leaverou> +1 to fantasai's concerns. If it can be overridden by rules outside the scope, it becomes very similar to nesting which we know doesn't solve these problems<br>
<dael> miriam: Except that the proposal has the scope root selector being added to all selector in scope so it's same as single attribute in most cases, but could be more powerful. Set root selector to ID you're adding the id to seelctor to everything inside. Can create higher weight but you have more control. Only proximity part is lower<br>
<dael> fantasai: spec of selector in @scope condition is added to all selectors within scoped block<br>
<dael> miriam: Right<br>
<dael> fantasai: That wasn't clear. I don't hitnk that's a good design. The way you select element you want to be scoped shouldn't have effect on how specific selector in scope are. If you switch class to ID it can completely distroy relationship between selectors.<br>
<TabAtkins> q+<br>
<dael> fantasai: Where this fits in cascade I'm interested to think about. I don't htink choice of selector in @scope should have effect on cascade<br>
<astearns> ack TabAtkins<br>
<dael> TabAtkins: What I like about miriam design is it is virtually identical to specificity landscape, including with nesting. That means that it's as familiar as specificity in existing css including the scope inheriting into nested selectors<br>
<dael> TabAtkins: You can override it with no specificisty selector. That would achieve same effect w/o specificity. By default you get today's behavior. That has problems, of course, but because we're in todya's model anything we do in the future doesn't have more to worry about. It's the existing model and wil interoperate<br>
<astearns> ack florian<br>
<dael> florian: I don't have a strong view on issue we've been discussion, but not that concerned. Compared to last time we tried this it's easier b/c less problems. We have cascade layers and shadow dom. As miriam pointed out main goal is prevent styles from leaking out. We need tor esolve conflicts, but primary goal is leaking out<br>
<dael> florian: If you want strong isolation maybe you should use shadow dom. If you want to make sure you win you have cascade layers. We need to solvet he discussion, but unlike last time since we're not trying to solve all the problems it doesn't concern me as much<br>
<dael> fantasai: I have strong reservations about the proposal<br>
<nicole> q+<br>
<dael> astearns: Are they about the specificity for the rules inside the block?<br>
<TabAtkins> Yup, recognizing that we're already solving the "figure out which large set of styles wins" in other ways means we can focus this one on the much simpler problem of "lower bound protection" (and, for giggles, letting us give a weak notion of proximity to specificity).<br>
<astearns> ack nicole<br>
<dael> fantasai: Basically, everything except syntax. Also where it fits into cascade. Feel strongly spec of root selector should not be a factor in cascade. Not convinced way defined to itneract with specificity is what we want. Possible it is and I don't understand use cases, but I don't think so.<br>
<dael> nicole: Speaking to use in design systems. You would end up with simple seelctor in root selector<br>
<dael> nicole: I would have expected that as a part of specificitly b/c how nesting works in sass<br>
<leaverou> q+<br>
<fantasai> s/I don't think so/based on what I know, I don't think this is right/<br>
<astearns> ack leaverou<br>
<dael> nicole: Case on more complex selector in root would be more rare. I would expect they want something specific and fremy said that would be better achieved with layers. The interaction of the 2 makes sense<br>
<fantasai> s/Also where/Where/<br>
<dael> leaverou: Separate nesting spec that's supposed to do same as nesting in sass. If they do similar things with slight differences it will be confusing. I agree with some of fantasai concerns. WE know nesting doesn't solve scoping use cases. If things outside scope can leak in worried it won't address cases<br>
<TabAtkins> Contra fantasai, I feel *strongly* that the root selector needs to be figured into the nested styles, because otherwise the selectors will *often* be too weak. Keeping those selectors weak *when they would auto-win anyway* (as our earlier @scope attempt did) is fine, but if we're working within the standard specificity wars, letting the container's selector add in is necessary.<br>
<dael> fantasai: I think you want things to leak in, but leak in at a lower priority<br>
<dael> leaverou: That's what I meant<br>
<dael> fantasai: Prop here fusses with spec and scoping is a fallback. Previous scoping said it was higher than specificity so inner scope would win if there and outer would take effect. Shadowdom the outer scope wins.<br>
<dael> fantasai: Both cases are different. Question is how does scoping interact with specificity<br>
<fremy> I agree with TabAtkins here<br>
<dael> TabAtkins: WE're solving problem of how to worry about larger scale conflicts with layers so we don't have to care as much here.<br>
<dael> fantasai: I think layers helps a lot, but not quite the same. But yeah, can create a layer for every component. Seems overkill<br>
<dael> leaverou: Layers are supposed to contain enitre library, not every component<br>
<dael> TabAtkins: I don't htink you'll be worrying at that level<br>
<dael> fantasai: Example: I have a sidebar in my page and want it to have a different color. Inverse contrast color. I have rules setting link color heading color etc. Need to override them all in my sidebar. I override the link and say it's light.<br>
<dael> fantasai: Overall outer page has slightly different colors for links in a list. B/c that's higher specificity it overrides the sidebar.<br>
<argyle> Sime Vidas showing donut scoping with complex `:not()` https://css-tricks.com/weekly-platform-news-focus-rings-donut-scope-ditching-em-units-and-global-privacy-control/#the-enhanced-css-not-selector-enables-donut-scope<br>
<dael> fantasai: So it doesn't solve the scoping problem b/c specificity<br>
<leaverou> argyle: I've made this point too, but this fails with nested structures<br>
<dael> TabAtkins: You're right it does not solve. You solve it using standard specificitly mechanisms or if this is a page specific modification that's what layers is designed to do. Let you separate general styles from specific styles that need to win at all costs. We've solved that<br>
<dael> fantasai: It's not nec page specific. It could be for my whole site<br>
<dael> florian: What's wrong with a layer<br>
<dael> fantasai: Rest of page could have layers and now they're siblings. It's not about the loading, it's about am I in a sidebar b/c if I am they need to be more important. That's hierarchy, not which stylesheet wins<br>
<fantasai> s/siblings/sibling layers, and ordering matters/<br>
<leaverou> argyle: I've written more about how it fails with nested structures here: https://github.com/w3ctag/design-reviews/issues/593#issuecomment-769351277<br>
<dael> TabAtkins: I don't agree entirely. In some cases yes, but in many cases it's not. Complexifying this by adding another strong kind of scoping will add a ton of complications. Solving in this weak way that melds cleanly and goes with the general approach is better<br>
<dael> astearns: miriam I think you should take the strong opinions as encouragement. That everyone is digging in and has strong opinions and expressing concerns is an indication we should continue work.<br>
<dael> astearns: I don't think we'll be able to resolve to officially work on this right now, but I think we can get there<br>
<TabAtkins> leaverou, argyle: Yeah, current selectors are definitely just too weak to handle lower bounds.<br>
<dael> miriam: Yes, and I was expecting this to be contentios because there are use cases all along the spectrum. That's been a challenge with scope. I went weak intentionally. There are strong pieces out there so I thought I'd go the other direction to balance out the use cases.<br>
<dael> astearns: I think that's all the time we can give to this today<br>
<fantasai> TabAtkins, this is adding something that's "almost the same as nesting but not quite in small ways", as Lea noted. That's more confusing than adding strong scoping that works the opposite of shadow DOM.<br>
<dael> astearns: I don't know how much time you can spend on this miriam but feel free to create something in spec form and make separate issues for the separate concerns.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5809#issuecomment-795831351 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 March 2021 18:01:29 UTC