16:56:43 RRSAgent has joined #css 16:56:43 logging to https://www.w3.org/2021/03/10-css-irc 16:56:45 RRSAgent, make logs Public 16:56:45 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:57:55 fremy has joined #css 16:58:00 present+ 16:58:05 ScribeNick: dael 16:58:24 Morgan has joined #css 16:58:36 present+ 16:58:47 oriol has joined #css 16:58:49 present+ 16:58:52 present+ 16:58:53 present+ 17:00:22 dlibby has joined #css 17:00:23 present+ 17:00:23 jfkthame has joined #css 17:00:29 alisonmaher has joined #css 17:00:32 present+ 17:00:36 present+ 17:00:38 present+ 17:00:41 astearns: We'll wait a minute or two and then get started 17:01:22 present+ 17:01:26 dgrogan has joined #css 17:01:27 una has joined #css 17:01:28 present+ 17:02:14 present+ 17:02:18 smfr has joined #css 17:02:29 present+ 17:02:30 GameMaker has joined #css 17:02:33 sanketj has joined #css 17:02:37 present+ 17:02:40 present+ 17:02:56 present+ 17:02:59 astearns: We can get going. 17:03:17 astearns: We are going to skip items 2-4 on the agenda b/c chris can't make it today 17:03:24 astearns: Any other changes people would like to make? 17:03:26 Topic: CSS Ruby review + republication 17:03:38 Changes: https://drafts.csswg.org/css-ruby-1/#changes 17:04:06 present+ 17:04:22 castastrophe has joined #css 17:04:31 fantasai: Sent an email with summary of changes. WE re-wrote layout section and incorporated resolutions. Also gave it a layout model for inter character Ruby. Based on layout you would get for an inline block w/ orthogonal writing mode. Some differences with alignment and sizing 17:04:36 https://drafts.csswg.org/css-ruby-1/#inter-character-layout 17:04:40 fantasai: That's all defined in ^ 17:04:56 fantasai: defined interaction of ruby-align more closely. Lots of changes around alignment and positioning 17:04:57 GameMake_ has joined #css 17:05:12 fantasai: Lots of open issues, but would like update WD with this to get wider review and snapshot progress 17:05:24 present+ 17:05:25 present+ 17:05:46 florian: In terms of text it's changed a bit, but not radical. Based on resolutions, editorial re-writes, and disambig. Thigns to discussion, but not a readical change 17:05:51 astearns: Prop: Publish updated WD 17:05:57 RESOLVED: Publish updated WD 17:06:02 astearns: Please take a look. 17:06:03 present+ 17:06:08 astearns: Will you ask for review outside WG? 17:06:23 fantasai: Not quite yet. Lots of open issues. Will look and see if particular groups can look now 17:06:38 Topic: [css-color-adjust-1] accent-color in Forced Colors Mode 17:06:45 github: https://github.com/w3c/csswg-drafts/issues/5987 17:07:27 alisonmaher: This is around adding accent-color to prop adjusted in forced color mode. Similar to scrollbar where force to auto. Question is what should happen w/ forced color adjust. Rest of control isn't adjustable. fremy makes sense, though. Should be honored but up to UA how to apply. 17:07:30 present+ 17:07:38 alisonmaher: Does that sound good or are there other options to look at? 17:07:57 fantasai: If it's none we shouldn't force colors. Main q is do we force it to auto or do we allow it to be a color 17:08:09 s/color/system color/ 17:08:09 present+ 17:08:10 Rossen_ has joined #css 17:08:15 astearns: Other opinions? 17:08:32 IanPouncey has joined #css 17:08:43 fantasai: I lean toward force to auto. Author doesn't know what system color will be and since trying to make page match colors user is comfortable with pushing to auto makes more sense 17:08:58 regrets+ 17:09:01 present+ 17:09:13 astearns: fremy comment seems to imply if adjustment is set to none other colors are reset? 17:09:30 q? 17:09:47 fremy: Not the case. If adjust is none we should not touch property. But maybe we don't need to do anything. UA isn't forced to do anything with it. Saying it does not really matter. We can switch to auto, but easier to impl that we do nothing 17:09:50 nicole has joined #css 17:09:53 fantasai: Could add a note UA could do that 17:09:56 fremy: Yeah 17:10:14 fantasai: Prop would be add a note what UA can ignore accent color in forced colors mode where it wouldn't otherwise 17:10:22 astearns: Add to the list but then say not really? 17:10:56 what would happen with say a black and white display on an ereader 17:10:58 fantasai: Property value would stay at what set at. UA if and how it uses an accent color...well...we do define if ther is an accent color you have to change. So I think force to auto. This is used value time operation 17:11:12 fantasai: We do require if you have something desc as an accent color then the property does change it 17:11:25 astearns: fremy you okay force to auto? 17:11:31 nicole, that e-reader wouldn't have an accent-color, so accent-color would not have any effect 17:11:36 fremy: Yeah. Doesn't matter sinc can't observe as a user. Whatever is easier 17:11:49 astearns: Prop: Add accent color to list of properties adjusted and have it adjusted to auto 17:11:53 alisonmaher: Sounds right 17:11:56 astearns: Obj? 17:12:08 RESOLVED: Add accent-color to list of properties adjusted and have it adjusted to auto 17:12:15 Topic: [css-ruby] visibility:collapse on ruby annotations 17:12:22 github: https://github.com/w3c/csswg-drafts/issues/5927 17:12:35 fantasai thanks, makes sense 17:12:40 florian: When you have ruby and base is identical to annotation we have auto-hiding behavior. This needs to be impl 17:12:56 florian: What's not nice is it's only auto-applied. No way to manually invoke that hiding behavior. Only auto 17:13:00 florian: There are use cases to do it 17:13:21 florian: Since we have behavior, use cases, and syntax that would match to the behavior- proposal is map the syntax to the behavior 17:13:25 jensimmons has joined #css 17:13:28 jensimmo_ has joined #css 17:14:00 astearns: I brought up if this can interact with real world markup, but I'm not that concerned. Happy to go witht he proposal 17:14:04 astearns: Other opinions? 17:14:22 astearns: We could resolve to spec this up and see how it goes 17:14:40 florian: Spec is easy. Behavior is spec, just need to say this syntax matches the behavior 17:14:47 I really like that the behavior in a browser that does not implement this is decently good 17:14:50 So 17:15:03 I don't see harm in adding this, worst case we remove later 17:15:08 fantasai: It gives you control over the hiding. You can hide things that wouldn't be hidden 17:15:18 astearns: Any idea if any engine is interested in impl this? 17:15:42 fantasai: Seems like easy to do in FF b/c they already impl auto-hiding. Wouldn't require a lot to make it work 17:16:01 s/be hidden/be auto-hidden/ 17:16:07 florian: And we're not at CR yet. If we were close maybe, but at that point I don't think it's worth adding that noise 17:16:17 astearns: Worth adding bugs to systems to please try to impl? 17:16:19 florian: Sure 17:16:33 astearns: Prop: Add this defined hiding behavior to spec and ping engines to impl it 17:16:41 RESOLVED: Add this defined hiding behavior to spec and ping engines to impl it 17:16:50 Topic: [css-align-3] What is supposed to happen to abspos in an end-aligned scroll container? 17:16:57 github: https://github.com/w3c/csswg-drafts/issues/4957 17:17:32 iank_: I think we didn't have information previously. Perhaps we forgot to agenda- it 17:17:56 fantasai: This needs more discussion in GH. It is one of the main open issues against alignment spec. Which model do we want for handling alignment in a scroll container 17:18:32 astearns: Been 20 days since comment on this issue, maybe b/c waiting on it on the call. Can one of you summarize what's left to do on this issue on GH? 17:18:36 fantasai: Yeah, TabAtkins and I can 17:18:42 astearns: We'll discuss more in the issue 17:18:49 Topic: [css-scroll-snap] Scroll snap areas for fragmented boxes (like in css-multicol) 17:18:56 github: https://github.com/w3c/csswg-drafts/issues/5911 17:19:45 fantasai: Basically this is a question of how do we want to address it. We didn't spec frag boxes. Basically 2 concepts. Draw a bounding box around all frag and snap or each frag is independent snap area 17:20:16 fantasai: When they line up nicely it works fine. but a box split across multi columns and half is the bottom of a column and half is the top, how do you handle? Snap to the middle might not see well. 17:20:25 fantasai: I don't have a good answer. Wanted to ask the WG 17:20:58 florian: For multicol specicially drawing a big box could work. Fragmentation in general it wouldn't. Scroll and paginate could exist in the same device. If that's the case pieces might be on different canvases. 17:21:31 fantasai: If on sep pages you have to snap within page. No other poss interpretation. Multiple frag on same page, how to handle? 17:21:54 fantasai: scroll snap does apply to inline boxes. That's a case where snap to bounding box makes sense. For block may be snap to each fragment makes sense 17:22:26 astearns: Other ideas? 17:22:44 astearns: Looks like we have 2 behaviors impl and we're not sure either is what we want to spec 17:23:03 smfr: Examples of pages that show different behavior? Any real world ones? Basically, does it matter? 17:23:39 fantasai: Yeah. Let's say I have phrases with an ID. terms and definitions. It wraps 2 lines. WHen you click on a link to the definition, where do we snap? If we ask to center it 17:23:50 Gottfried has joined #css 17:24:09 florian: In spec we don't turn on snapping for these things. What would be a doc where we would turn on snapping? If we know why it's on might be able to reason what's preferable 17:24:44 Rossen_: Instead of trying to come up with examples here, I think this needs to go back to GH. I think it's a good prompt to add real world motivating examples 17:25:00 smfr: My suggestion would be to ask if anyone obj to bounding box solution 17:25:18 TabAtkins: In particular if FF objects b/c that's a change for them 17:25:32 fantasai: I will not original person who raised issue was looking for per fragment 17:25:38 TabAtkins: They wanted to snap to columns 17:25:46 fantasai: Yes, particular use case can be done in other ways 17:25:59 TabAtkins: B/c asking for something different we shoudln't worry about satisfying thier case 17:26:04 jensimm__ has joined #css 17:26:08 fantasai: I think it would be good to get author feedback 17:26:23 astearns: One way of getting feedback is spec bounding box and ask for examples of how we're getting it wrong 17:26:36 fantasai: We have both impl so they can compare. We need people to pay attention 17:26:43 Rossen_: Will bounding box be compat with multicol? 17:27:03 fantasai: If you ask for center snap position you snap to center of all col the element belongs to. Not sure if that's what you wanted 17:27:09 present+ 17:27:33 present+ 17:27:42 florian: Earlier point that for inlines bounding box is good but block it might not makes sense. Multicol is one example. The further apart the pieces can be the less sense it makes for bounding box. Okay to say inline is bounding box, else per fragment? 17:28:01 jfkthame: Even inline element could run cross fragments in a multicol, couldn't it? 17:28:12 florian: Yeah. Double fragmented 17:28:27 iank_: I was going to ask same question fantasai asked, what do webdev expect here 17:28:42 fantasai: WE should try and reach out to dev community. Maybe jensimmons or rachelandrew 17:29:05 rachelandrew: If we ask webdev might get confused with the snap to column boxes. Trying to think how to separate 17:29:18 fantasai: Need a diagram. One of a multicol with a hot pink box or something 17:29:33 rachelandrew: Happy to have a go at writing blog. need to make sure we're getting feedback for the thing we want 17:29:37 fantasai: How about you and I work on that 17:29:39 rachelandrew: Sure 17:29:40 s/pink box/pink box starting near the bottom of the first column/ 17:29:51 astearns: Alright, I'll take the tag off this and we'llg et feedback 17:29:59 Topic: [css-scoping] Proposal for light-dom scoping/namespacing with re-designed `@scope` rule 17:30:05 github: https://github.com/w3c/csswg-drafts/issues/5809 17:30:14 miriam: I have slides, but talk through without? 17:30:24 https://slides.oddbird.net/csswg/f2f2102/#slide-26 17:30:29 miriam: Link ^ 17:30:53 [trying to see if miriam can present] 17:31:02 miriam: I'll talk through them 17:31:16 miriam: There has been several threads open about having a scoping in css 17:31:30 miriam: There was even attempt in 2014 to spec it. not impl. 17:31:50 miriam: Looking into it I found differences with shadow dom. Proposal is what is see is missing from shadow dom. 17:32:35 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 17:32:50 miriam: A lot of tools out there try and do this manually. Putting together special selectors 17:33:39 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. 17:34:08 [slide 32] 17:34:16 [slide 33] 17:34:18 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. 17:34:23 [slide 34] 17:34:31 miriam: High power in the cascade as well. It overrides specificities 17:34:34 [slide 35] 17:35:05 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. 17:35:34 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 17:35:38 [slide 38] 17:35:39 q+ when Miriam is done to express support 17:35:50 q+ 17:36:02 qq+ 17:36:02 miriam: All these tools do it lower impact. It's reused across leements. Priority is handled through ownership rather then specificity 17:36:02 q- 17:36:08 q+ 17:36:10 [slide 40] 17:36:17 [slide 41] 17:36:20 https://www.irccloud.com/pastebin/MtGSIIPT/ 17:36:22 miriam: Prop bringing back scope rule and scope pseudo class. Proposal is a syntax like & 17:37:00 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 17:37:10 miriam: Scope selector is the root. It's implied when not used 17:37:18 [slide 42] 17:37:25 [slide 43] 17:38:13 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. 17:38:39 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 17:38:40 ack TabAtkins 17:38:40 TabAtkins, you wanted to react to a previous speaker 17:39:18 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 17:39:36 ack leaverou 17:39:37 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 17:39:46 leaverou: I would like to agree with TabAtkins this is highly needed. I support it 17:40:56 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 17:41:17 leaverou: Worth exploring how the donut scope could be done through selectors syntax so @scoping can just have the scoping and not the selection 17:41:25 leaverou: Does that make sense? 17:41:37 fantasai: You're prop selector in addition to @scope where selctor is a limit on what's selected? 17:41:39 leaverou: Yes 17:41:42 like `@scope .tabs - .panel {}` like this? where the dash is showing a range? 17:41:44 fremy: Makes a lot of sense to me 17:41:51 s/selected/selected, but doesn't affect the cascade/ 17:42:05 q? 17:42:24 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 17:42:27 ack fantasai 17:42:29 leaverou: Both problems need solving 17:43:08 Hm, I'm not sure how we would work a lower-boundary into the normal selector syntax 17:43:30 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. 17:43:33 miriam: That's right 17:43:33 Currently, @scope basically *is* just a selector (allowing nesting) 17:43:45 fantasai: Can you explain the reasoning behind why this is the appropriate choice? 17:44:11 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 17:44:23 q+ 17:44:36 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 17:44:54 miriam: Tools do it with an added attribute now, but that only increases spec by a small amount 17:45:25 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. 17:45:57 +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 17:46:16 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 17:46:31 fantasai: spec of selector in @scope condition is added to all selectors within scoped block 17:46:32 miriam: Right 17:47:12 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. 17:47:27 q+ 17:47:36 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 17:47:39 ack TabAtkins 17:48:16 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 17:49:05 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 17:49:08 ack florian 17:49:57 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 17:50:37 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 17:50:44 fantasai: I have strong reservations about the proposal 17:50:51 q+ 17:50:58 astearns: Are they about the specificity for the rules inside the block? 17:51:31 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). 17:51:47 ack nicole 17:51:49 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. 17:52:03 nicole: Speaking to use in design systems. You would end up with simple seelctor in root selector 17:52:16 nicole: I would have expected that as a part of specificitly b/c how nesting works in sass 17:52:29 q+ 17:52:35 s/I don't think so/based on what I know, I don't think this is right/ 17:52:48 ack leaverou 17:52:49 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 17:52:52 s/Also where/Where/ 17:53:32 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 17:53:39 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. 17:53:46 fantasai: I think you want things to leak in, but leak in at a lower priority 17:53:49 leaverou: That's what I meant 17:54:30 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. 17:54:43 fantasai: Both cases are different. Question is how does scoping interact with specificity 17:55:05 I agree with TabAtkins here 17:55:05 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. 17:55:13 aja has joined #css 17:55:22 fantasai: I think layers helps a lot, but not quite the same. But yeah, can create a layer for every component. Seems overkill 17:55:34 leaverou: Layers are supposed to contain enitre library, not every component 17:55:41 TabAtkins: I don't htink you'll be worrying at that level 17:56:19 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. 17:56:40 fantasai: Overall outer page has slightly different colors for links in a list. B/c that's higher specificity it overrides the sidebar. 17:56:41 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 17:56:53 fantasai: So it doesn't solve the scoping problem b/c specificity 17:57:25 argyle: I've made this point too, but this fails with nested structures 17:57:43 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 17:57:55 fantasai: It's not nec page specific. It could be for my whole site 17:58:02 florian: What's wrong with a layer 17:58:35 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 17:58:57 s/siblings/sibling layers, and ordering matters/ 17:59:18 argyle: I've written more about how it fails with nested structures here: https://github.com/w3ctag/design-reviews/issues/593#issuecomment-769351277 17:59:26 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 17:59:54 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. 18:00:08 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 18:00:21 leaverou, argyle: Yeah, current selectors are definitely just too weak to handle lower bounds. 18:00:52 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. 18:01:01 astearns: I think that's all the time we can give to this today 18:01:20 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. 18:01:22 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. 18:01:24 Topic: end 18:01:34 astearns: We're done for the day and we'll talk next week. Thanks all. 18:02:26 I actually didn't understand that - leaverou, how is it not like Nesting? The sole difference from nesting (modulo some syntax concerns that I still need to raise) is that scoping adds the weak "proximity" layer between specificity and source order. 18:02:33 It seems like we might need to back up and decide which use-cases this particular feature is trying to solve 18:02:53 +1 nicole 18:03:56 But that said, I see it as similar to nesting syntactically but the donut is a key part that is different. For design systems, you don't want component styles to flow into child components. 18:03:57 But otherwise, `@scope (.foo) { .bar { color: red; } }` and `.foo { & .bar { color: red; } }` are identical in every way. 18:05:13 (The syntax issue is just that I'm still not 100% sure we don't want to make indicating the scoping element mandatory, exactly like nesting, and whether or not we want to just use Nesting *directly* and have the & selector work there. 18:05:14 ) 18:06:03 Yeah @tabatkins I wondered the same thing, but thought there are use-cases for nesting that are about code organization where you wouldn't really want scope. 18:06:08 (But I'm not sure about either of those issues, and the current spec might be okay, just need to give it more thought.) 18:06:54 nicole: Right, I wasn't suggesting dropping @scope and just having Nesting auto-apply scoping, I just meant spelling it like `@scope (.foo) { & .bar { ... } }` 18:07:02 ahhh 18:07:04 gotcha 18:07:06 `&` refers to an entire selector list, where `:scope` refers to the specific element that is one instance of a selector-match. I think that distinction might end up being important. 18:07:30 Right, that's the issue that I need put more thought into to decide whether it's important or not. It's a muddle in my head currently. 18:10:39 Ah right, yes, okay, so like `.foo { & > & { ...} }` is valid and meaningful currently, but `@scope (.foo) { :scope > :scope { ... } }` isn't, that's the big difference driving it. 18:12:18 right 18:13:14 Okay so I think I'm fine with continuing to spell it :scope, I'm just still left on whether we want to *require* the :scope or rely on the absolutizing rules to fill it in when it's missing 18:17:11 ooh, that spec is breaking my brain a bit. Gotta read it more throughly. 18:18:36 Requiring the :scope (or rather, just not filling it in automatically) does mean you can avoid adding in the container's specificity when you don't want it. You'll still get scoped (the @scope rule still filters the results of any contained selectors), you just won't get magic specificity added. 18:20:35 So like `@scope (#foo) { .bar { /* 0,1,0 */ } }`, but `@scope (#foo) { :scope .bar { /* 1,1,0 */ } }` would select the exact same elements but with (hopefully) more obvious specificity 18:22:07 oh, that's an interesting take. Does it make sense that the certain selectors which would require `:scope` (any relating to external context) should always get the added specificity of `:scope` while some selectors can avoid it? I'm not totally convinced. 18:23:04 Regarding relationship to specificity, I did also talk to a number of authors, and ran a twitter poll (for whatever that's worth): https://twitter.com/mirisuzanne/status/1351247559738621952 18:26:02 miriam: What selectors are you thinking of that require :scope? 18:26:11 (Not saying they don't exist, just making sure I"m thinking of the same thigns you are) 18:27:38 Any that want to reference external context, where `:scope` is no longer the "front" of the selector: `@scope (.dark-mode) { .sidebar :scope a { ... } }` 18:28:19 Okay, cool. You can use `.sidebar :where(:scope) a {...}` if you don't need the container's specificity, at least. 18:29:37 That's true 18:30:05 I lean towards the idea that specificity being *predictable* from looking at the selector is a little better for authors than trying to keep the specificity *consistent* in ways that might be slightly magical. 18:31:07 I did also consider `:scope` always having the specificity of a pseudo-selector. Which would match exactly to current tooling that uses generated-attributes 18:31:53 That breaks further from Nesting and current CSS that just writes out the selectors entirely, so I'd be lightly against that. ^_^ 18:32:12 Yeah, in conversations, that seemed a bit less expected to people than the nesting approach 18:36:33 fantasai: Check the above poll from Miriam tho - the strong Nesting we worked on before prevents the outside page from *ever* overriding a scoped declaration (it would need to use another scoped block anchored at the same or descendant element). Having it just slot into existing specificity lets you poke thru the membrane when you want to, and all the other controls we have for adding stronger protection (layers, shadow DOM) still work. 18:39:00 Exactly - my feeling was that this approach gives me much more control as an author to set the boundary where I want it with existing specificity. If scope is more powerful, I have very few options to penetrate from the global scope. 18:40:18 And in the use-cases I looked at, it seemed to me that use cases (like light-mode/dark-mode) which rely on proximity _also_ have matching specificity. 18:41:21 (Worth noting that the existing tools have _no_ proximity rules, but authors achieve the same impact by adding lower boundaries.) 18:44:27 Notably Shadow DOM's behavior preserves the "outer page can poke in when it feels it's important", for exactly this reason. Previous @scope behavior was at least partially because, lacking a lower bound, we needed strong proximity to give better behavior for sub-scopes. 18:55:07 jensimmons has joined #css 19:07:28 becky has joined #css 19:27:20 jamesn has joined #css 20:01:25 Zakim has left #css 20:19:56 I have made the request to generate https://www.w3.org/2021/03/10-css-minutes.html fantasai 20:27:45 ankh___ has joined #css 20:40:45 iank_ has joined #css 21:30:34 ZoeBijl has joined #css 23:06:20 BoCupp has joined #css