Meeting minutes
astearns: We'll wait a minute or two and then get started
astearns: We can get going.
astearns: We are going to skip items 2-4 on the agenda b/c chris can't make it today
astearns: Any other changes people would like to make?
CSS Ruby review + republication
Changes: https://
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
<fantasai> https://
fantasai: That's all defined in ^
fantasai: defined interaction of ruby-align more closely. Lots of changes around alignment and positioning
fantasai: Lots of open issues, but would like update WD with this to get wider review and snapshot progress
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
astearns: Prop: Publish updated WD
Resolution: Publish updated WD
astearns: Please take a look.
astearns: Will you ask for review outside WG?
fantasai: Not quite yet. Lots of open issues. Will look and see if particular groups can look now
[css-color-adjust-1] accent-color in Forced Colors Mode
github: https://
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.
alisonmaher: Does that sound good or are there other options to look at?
fantasai: If it's none we shouldn't force system colors. Main q is do we force it to auto or do we allow it to be a color
astearns: Other opinions?
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
astearns: fremy comment seems to imply if adjustment is set to none other colors are reset?
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
fantasai: Could add a note UA could do that
fremy: Yeah
fantasai: Prop would be add a note what UA can ignore accent color in forced colors mode where it wouldn't otherwise
astearns: Add to the list but then say not really?
<nicole> what would happen with say a black and white display on an ereader
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
fantasai: We do require if you have something desc as an accent color then the property does change it
astearns: fremy you okay force to auto?
<fantasai> nicole, that e-reader wouldn't have an accent-color, so accent-color would not have any effect
fremy: Yeah. Doesn't matter sinc can't observe as a user. Whatever is easier
astearns: Prop: Add accent color to list of properties adjusted and have it adjusted to auto
alisonmaher: Sounds right
astearns: Obj?
Resolution: Add accent-color to list of properties adjusted and have it adjusted to auto
[css-ruby] visibility:collapse on ruby annotations
github: https://
<nicole> fantasai thanks, makes sense
florian: When you have ruby and base is identical to annotation we have auto-hiding behavior. This needs to be impl
florian: What's not nice is it's only auto-applied. No way to manually invoke that hiding behavior. Only auto
florian: There are use cases to do it
florian: Since we have behavior, use cases, and syntax that would match to the behavior- proposal is map the syntax to the behavior
astearns: I brought up if this can interact with real world markup, but I'm not that concerned. Happy to go witht he proposal
astearns: Other opinions?
astearns: We could resolve to spec this up and see how it goes
florian: Spec is easy. Behavior is spec, just need to say this syntax matches the behavior
<fremy> I really like that the behavior in a browser that does not implement this is decently good
<fremy> So
<fremy> I don't see harm in adding this, worst case we remove later
fantasai: It gives you control over the hiding. You can hide things that wouldn't be auto-hidden
astearns: Any idea if any engine is interested in impl this?
fantasai: Seems like easy to do in FF b/c they already impl auto-hiding. Wouldn't require a lot to make it work
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
astearns: Worth adding bugs to systems to please try to impl?
florian: Sure
astearns: Prop: Add this defined hiding behavior to spec and ping engines to impl it
Resolution: Add this defined hiding behavior to spec and ping engines to impl it
[css-align-3] What is supposed to happen to abspos in an end-aligned scroll container?
github: https://
iank_: I think we didn't have information previously. Perhaps we forgot to agenda- it
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
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?
fantasai: Yeah, TabAtkins and I can
astearns: We'll discuss more in the issue
[css-scroll-snap] Scroll snap areas for fragmented boxes (like in css-multicol)
github: https://
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
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.
fantasai: I don't have a good answer. Wanted to ask the WG
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.
fantasai: If on sep pages you have to snap within page. No other poss interpretation. Multiple frag on same page, how to handle?
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
astearns: Other ideas?
astearns: Looks like we have 2 behaviors impl and we're not sure either is what we want to spec
smfr: Examples of pages that show different behavior? Any real world ones? Basically, does it matter?
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
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
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
smfr: My suggestion would be to ask if anyone obj to bounding box solution
TabAtkins: In particular if FF objects b/c that's a change for them
fantasai: I will not original person who raised issue was looking for per fragment
TabAtkins: They wanted to snap to columns
fantasai: Yes, particular use case can be done in other ways
TabAtkins: B/c asking for something different we shoudln't worry about satisfying thier case
fantasai: I think it would be good to get author feedback
astearns: One way of getting feedback is spec bounding box and ask for examples of how we're getting it wrong
fantasai: We have both impl so they can compare. We need people to pay attention
Rossen_: Will bounding box be compat with multicol?
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
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?
jfkthame: Even inline element could run cross fragments in a multicol, couldn't it?
florian: Yeah. Double fragmented
iank_: I was going to ask same question fantasai asked, what do webdev expect here
fantasai: WE should try and reach out to dev community. Maybe jensimmons or rachelandrew
rachelandrew: If we ask webdev might get confused with the snap to column boxes. Trying to think how to separate
fantasai: Need a diagram. One of a multicol with a hot pink box starting near the bottom of the first column or something
rachelandrew: Happy to have a go at writing blog. need to make sure we're getting feedback for the thing we want
fantasai: How about you and I work on that
rachelandrew: Sure
astearns: Alright, I'll take the tag off this and we'llg et feedback
[css-scoping] Proposal for light-dom scoping/namespacing with re-designed `@scope` rule
github: https://
miriam: I have slides, but talk through without?
<miriam> https://
miriam: Link ^
[trying to see if miriam can present]
miriam: I'll talk through them
miriam: There has been several threads open about having a scoping in css
miriam: There was even attempt in 2014 to spec it. not impl.
miriam: Looking into it I found differences with shadow dom. Proposal is what is see is missing from shadow dom.
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
miriam: A lot of tools out there try and do this manually. Putting together special selectors
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.
<fantasai> [slide 32]
<fantasai> [slide 33]
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.
<fantasai> [slide 34]
miriam: High power in the cascade as well. It overrides specificities
<fantasai> [slide 35]
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.
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
<fantasai> [slide 38]
miriam: All these tools do it lower impact. It's reused across leements. Priority is handled through ownership rather then specificity
<fantasai> [slide 40]
<fantasai> [slide 41]
<miriam> https://
miriam: Prop bringing back scope rule and scope pseudo class. Proposal is a syntax like &
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
miriam: Scope selector is the root. It's implied when not used
<fantasai> [slide 42]
<fantasai> [slide 43]
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.
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
<Zakim> TabAtkins, you wanted to react to a previous speaker
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
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
leaverou: I would like to agree with TabAtkins this is highly needed. I support it
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
leaverou: Worth exploring how the donut scope could be done through selectors syntax so @scoping can just have the scoping and not the selection
leaverou: Does that make sense?
fantasai: You're prop selector in addition to @scope where selctor is a limit on what's selected, but doesn't affect the cascade?
leaverou: Yes
<argyle> like `@scope .tabs - .panel {}` like this? where the dash is showing a range?
fremy: Makes a lot of sense to me
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
leaverou: Both problems need solving
<TabAtkins> Hm, I'm not sure how we would work a lower-boundary into the normal selector syntax
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.
miriam: That's right
<TabAtkins> Currently, @scope basically *is* just a selector (allowing nesting)
fantasai: Can you explain the reasoning behind why this is the appropriate choice?
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
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
miriam: Tools do it with an added attribute now, but that only increases spec by a small amount
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.
<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
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
fantasai: spec of selector in @scope condition is added to all selectors within scoped block
miriam: Right
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.
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
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
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
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
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
fantasai: I have strong reservations about the proposal
astearns: Are they about the specificity for the rules inside the block?
<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).
fantasai: Basically, everything except syntax. 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 based on what I know, I don't think this is right.
nicole: Speaking to use in design systems. You would end up with simple seelctor in root selector
nicole: I would have expected that as a part of specificitly b/c how nesting works in sass
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
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
<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.
fantasai: I think you want things to leak in, but leak in at a lower priority
leaverou: That's what I meant
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.
fantasai: Both cases are different. Question is how does scoping interact with specificity
<fremy> I agree with TabAtkins here
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.
fantasai: I think layers helps a lot, but not quite the same. But yeah, can create a layer for every component. Seems overkill
leaverou: Layers are supposed to contain enitre library, not every component
TabAtkins: I don't htink you'll be worrying at that level
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.
fantasai: Overall outer page has slightly different colors for links in a list. B/c that's higher specificity it overrides the sidebar.
<argyle> Sime Vidas showing donut scoping with complex `:not()` https://
fantasai: So it doesn't solve the scoping problem b/c specificity
<leaverou> argyle: I've made this point too, but this fails with nested structures
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
fantasai: It's not nec page specific. It could be for my whole site
florian: What's wrong with a layer
fantasai: Rest of page could have layers and now they're sibling layers, and ordering matters. 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
<leaverou> argyle: I've written more about how it fails with nested structures here: https://
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
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.
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
<TabAtkins> leaverou, argyle: Yeah, current selectors are definitely just too weak to handle lower bounds.
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.
astearns: I think that's all the time we can give to this today
<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.
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.
end
astearns: We're done for the day and we'll talk next week. Thanks all.
<TabAtkins> 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.
<nicole> It seems like we might need to back up and decide which use-cases this particular feature is trying to solve
<fantasai> +1 nicole
<nicole> 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.
<TabAtkins> But otherwise, `@scope (.foo) { .bar { color: red; } }` and `.foo { & .bar { color: red; } }` are identical in every way.
<TabAtkins> (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.
<TabAtkins> )
<nicole> 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.
<TabAtkins> (But I'm not sure about either of those issues, and the current spec might be okay, just need to give it more thought.)
<TabAtkins> nicole: Right, I wasn't suggesting dropping @scope and just having Nesting auto-apply scoping, I just meant spelling it like `@scope (.foo) { & .bar { ... } }`
<nicole> ahhh
<nicole> gotcha
<miriam> `&` 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.
<TabAtkins> 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.
<TabAtkins> 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.
<miriam> right
<TabAtkins> 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 <https://
<nicole> ooh, that spec is breaking my brain a bit. Gotta read it more throughly.
<TabAtkins> 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.
<TabAtkins> 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
<miriam> 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.
<miriam> Regarding relationship to specificity, I did also talk to a number of authors, and ran a twitter poll (for whatever that's worth): https://
<TabAtkins> miriam: What selectors are you thinking of that require :scope?
<TabAtkins> (Not saying they don't exist, just making sure I"m thinking of the same thigns you are)
<miriam> Any that want to reference external context, where `:scope` is no longer the "front" of the selector: `@scope (.dark-mode) { .sidebar :scope a { ... } }`
<TabAtkins> Okay, cool. You can use `.sidebar :where(:scope) a {...}` if you don't need the container's specificity, at least.
<miriam> That's true
<TabAtkins> 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.
<miriam> I did also consider `:scope` always having the specificity of a pseudo-selector. Which would match exactly to current tooling that uses generated-attributes
<TabAtkins> That breaks further from Nesting and current CSS that just writes out the selectors entirely, so I'd be lightly against that. ^_^
<miriam> Yeah, in conversations, that seemed a bit less expected to people than the nesting approach
<TabAtkins> 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.
<miriam> 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.
<miriam> 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.
<miriam> (Worth noting that the existing tools have _no_ proximity rules, but authors achieve the same impact by adding lower boundaries.)
<TabAtkins> 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.