07:08:13 RRSAgent has joined #css 07:08:17 logging to https://www.w3.org/2025/08/20-css-irc 07:08:17 RRSAgent, make logs Public 07:08:18 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 07:08:18 alisonmaher has joined #css 07:08:23 present+ 07:10:08 present+ 07:10:55 kizu has joined #css 07:10:59 mike has joined #css 07:10:59 geheimnis` has joined #css 07:10:59 projector has joined #css 07:10:59 sylvaing has joined #css 07:10:59 shans has joined #css 07:10:59 dbaron[m] has joined #css 07:10:59 plinss has joined #css 07:10:59 leaverou has joined #css 07:10:59 dustinm has joined #css 07:10:59 hober has joined #css 07:10:59 zrhoffman has joined #css 07:10:59 tobie_ has joined #css 07:10:59 Rossen has joined #css 07:10:59 hayato has joined #css 07:10:59 jyasskin has joined #css 07:10:59 CSSWG_LogBot has joined #css 07:10:59 cwilso has joined #css 07:10:59 cbiesinger has joined #css 07:10:59 smaug has joined #css 07:10:59 jeroen has joined #css 07:10:59 hdv has joined #css 07:10:59 rachelandrew has joined #css 07:10:59 chrishtr has joined #css 07:10:59 futhark has joined #css 07:10:59 vmpstr has joined #css 07:10:59 faceless has joined #css 07:10:59 JakeA has joined #css 07:10:59 tink has joined #css 07:10:59 rbyers has joined #css 07:10:59 astearns has joined #css 07:10:59 bramus has joined #css 07:10:59 ntim has joined #css 07:10:59 slightlyoff has joined #css 07:10:59 gregwhitworth has joined #css 07:10:59 timeless has joined #css 07:10:59 iank_ has joined #css 07:10:59 alice has joined #css 07:10:59 weinig has joined #css 07:10:59 emilio has joined #css 07:10:59 drott has joined #css 07:10:59 devsnek has joined #css 07:10:59 TabAtkins has joined #css 07:10:59 dandclark has joined #css 07:10:59 miriam has joined #css 07:10:59 koji has joined #css 07:11:01 present+ 07:11:02 fantasai has joined #css 07:11:12 ydaniv has joined #css 07:11:15 diekus has joined #css 07:11:25 present+ 07:11:31 present+ 07:12:02 moonira has joined #css 07:13:26 lea has joined #css 07:13:26 fantasai has joined #css 07:13:26 mike has joined #css 07:13:26 geheimnis` has joined #css 07:13:26 projector has joined #css 07:13:26 sylvaing has joined #css 07:13:26 shans has joined #css 07:13:26 dbaron[m] has joined #css 07:13:26 plinss has joined #css 07:13:26 leaverou has joined #css 07:13:26 dustinm has joined #css 07:13:26 hober has joined #css 07:13:26 zrhoffman has joined #css 07:13:26 tobie_ has joined #css 07:13:26 Rossen has joined #css 07:13:26 hayato has joined #css 07:13:26 jyasskin has joined #css 07:13:26 CSSWG_LogBot has joined #css 07:13:26 cwilso has joined #css 07:13:26 cbiesinger has joined #css 07:13:26 smaug has joined #css 07:13:26 jeroen has joined #css 07:13:26 hdv has joined #css 07:13:26 rachelandrew has joined #css 07:13:26 chrishtr has joined #css 07:13:26 futhark has joined #css 07:13:26 vmpstr has joined #css 07:13:26 faceless has joined #css 07:13:26 JakeA has joined #css 07:13:26 tink has joined #css 07:13:26 rbyers has joined #css 07:13:26 astearns has joined #css 07:13:26 bramus has joined #css 07:13:26 ntim has joined #css 07:13:26 slightlyoff has joined #css 07:13:26 gregwhitworth has joined #css 07:13:26 timeless has joined #css 07:13:26 iank_ has joined #css 07:13:26 alice has joined #css 07:13:26 weinig has joined #css 07:13:26 emilio has joined #css 07:13:26 drott has joined #css 07:13:26 devsnek has joined #css 07:13:26 TabAtkins has joined #css 07:13:26 dandclark has joined #css 07:13:26 miriam has joined #css 07:13:26 koji has joined #css 07:13:26 oriol has joined #css 07:13:33 present+ 07:13:59 matthieud has joined #css 07:14:06 Topic: Mixins 07:14:42 TabAtkins: [presents an example of mixin] 07:14:48 TabAtkins: Looks just like custom functions for the most part 07:15:02 TabAtkins: env() is the way that arguments are presented in mixins, rather than var() 07:15:13 present+ 07:15:13 TabAtkins: As part of this, there is a way to create scoped environment variables 07:15:43 TabAtkins: Using @env rule to declare locally scoped env() 07:15:56 TabAtkins: apply them with @apply rule 07:16:23 TabAtkins: There are use cases for passing an entire block into a mixin, uses @contents 07:16:36 q+ 07:16:39 present+ 07:16:50 Tab is presenting https://drafts.csswg.org/css-mixins-1/ 07:16:53 TabAtkins: Where you use @contents in will sub in the argument block 07:17:30 q+ 07:17:32 ack emilio 07:17:33 emilio: Some high-level questions 07:17:35 present+ 07:17:53 emilio: At which stage are these substituted? How does CSSOM look like for these? 07:18:04 TabAtkins: I think the OM should reflect the @apply rules, not the substitued values 07:18:09 TabAtkins: so not technically at parse time 07:18:18 TabAtkins: but they apply before anything interesting happens in CSS, so just post parsing 07:18:25 TabAtkins: You do the rest of CSS with fully substituted rules 07:18:34 TabAtkins: Exactly what the OM shows, I don't have an opinion 07:18:57 emilio: Right now when you scan rules of style sheet to figure out source order etc, that's a single pass 07:19:11 present+ 07:19:20 emilio: It seems that, depending on when you resolve these, if you have multiple names etc., you may need to do multiple passes over input to figure out 07:19:24 andruud: yes 07:19:40 emilio: You might have mixins after using them, and then media queries inside mixins 07:19:50 emilio: so you need to resolve mixins, then media queries, then put the final ... 07:20:02 emilio: MQ you can do after substituting mixins, so you need second pass 07:20:22 TabAtkins: 2nd pass after substitution, but shouldn't need more 07:20:31 emilio: Depends if you have custom media definition inside 07:20:47 TabAtkins: Some unanswered questions, but would like to keep this as simple as possile 07:21:03 emilio: Should behave as transparently as possible, right? As if copy-pasted 07:21:19 TabAtkins: Yes, exactly as if you dropped the resulting declaration block as-is in place of @apply 07:21:24 emilio: If you define @layer inside the mixin? 07:21:37 TabAtkins: I think they should ignore the layers they're in so that they're globally defined 07:21:43 SebastianZ has joined #css 07:21:47 present+ 07:21:51 ack matthieud 07:21:51 miriam: that's the 1st issue on the agenda :) 07:21:58 matthieud: You can nest mixins, right? 07:22:05 q+ 07:22:08 TabAtkins: You can call a mixin from inside a mixin definition, but you can't nest definitions 07:22:11 [missed] 07:22:20 TabAtkins: Same way you can't do recursion in custom functions 07:22:23 ack SebastianZ 07:22:31 SebastianZ: Saw also an @env rule, which you didn't explain? 07:22:36 TabAtkins: Questions later 07:22:51 Subtopic: [css-mixins-1] Are @mixin rules valid within other at-rules? 07:23:43 andruud: Question of @mixin within e.g. @container -- are they allowed? are they conditional? 07:24:03 andruud: My thought was surely these are not not affected by the @container rule 07:24:14 andruud: Other than @media and @supports 07:24:22 andruud: This issue evolved into discussing @layer 07:24:34 andruud: We have to support layered mixins because @import can be layered 07:24:56 q+ 07:24:58 andruud: Proposal that we landed on is allowing mixins inside @layer, but, not letting the mixin name be affected by the layer 07:25:02 q+ 07:25:30 andruud: still have to do multi-stage resolution because if you have @apply before mixin 07:25:57 andruud: We didn't want multiple layer orders, because you could get one layer order while looking for mixin, and then different layer order if you mix in a mixin with layers inside? 07:26:10 TabAtkins: If your mixin has @layer inside, that can theoretically add to the layer list 07:26:20 TabAtkins: we want to allow you to put layer rules in the mixin body 07:26:40 TabAtkins: but then we either have to do one layer order to figure out how mixins resolve, and then do another to do styles, and that seems not great? 07:26:50 ack fantasai 07:27:04 fantasai: the first q I have is about putting @mixin in @container 07:27:16 ... if they're not responding to @container which won't make any sense 07:27:20 ... they should not be allowed 07:27:26 ... because that'd be confusing 07:27:31 ... should just be invalid 07:28:18 ... I think what makes sense is that @layer inside mixing is ignored until substitution 07:28:32 (on the que to suggest we rethink layers inside mixins) 07:28:59 andruud: the question is what happens if you define the same mixin name inside an `@layer` 07:29:10 TabAtkins: right it'd be possible to change the layer order post-application 07:29:13 q? 07:29:16 q+ 07:29:25 ... because @apply would be able to change the layer order 07:29:28 q+ 07:29:31 fantasai: I think we probably want that 07:29:37 TabAtkins: disagreed 07:29:51 ack miriam 07:29:56 miriam: I'm skeptical if we want to allow layers inside of mixins 07:29:57 miriam: I'm skeptical about layers _inside_ mixins 07:30:01 ... I understand why it feels useful 07:30:04 miriam: I understand why it feels useful 07:30:33 miriam: I think it will be confusing if layers inside of mixins interact with layers outside of mixins 07:30:40 miriam: I don't mean at the definition site, but at the call site 07:30:40 +1 07:30:44 q- 07:30:58 miriam: I have a feeling that layers inside of mixins should be contained to the mixin in some way, or not visible, not interacting with outside layers 07:31:07 miriam: you would think of them as inside of their own anonymous layer 07:31:24 miriam: say I create a mixin with 3 layer names inside of it, default states and overrides 07:31:32 miriam: I'm hoping they would interact with my globla states and overrides 07:31:45 miriam: but when I use them they'll be states.states and override.override 07:31:49 miriam: They won't interact correctly 07:31:58 q- 07:32:09 miriam: so layers inside of mixins should be contained by anonymous and not otherswise interact with stuff 07:32:24 TabAtkins: I think that would remove any reason to use layers inside mixins 07:32:32 TabAtkins: at which point we should just disallow layers inside mixins entirely 07:32:37 Was thinking the same as Tab there 07:32:44 miriam: OK with that. Could relax it later if needed 07:33:02 miriam: Yeah, might not need it 07:33:12 +1 to make layers a v2 thing. Even if useful, it's clearly not MVP and would slow down shipping the MVP 07:33:21 TabAtkins: contents of your rule could use layers, but at that point could just use specificity hacks 07:33:35 miriam: Interaction of inside out and outside in ... 07:33:38 +1 to lea 07:33:50 ack emilio 07:33:51 TabAtkins: I am disappointed they won't be purely transparent, but this is something we could do in v2 so OK with it 07:34:00 q+ to say the same thing 07:34:03 emilio: That still doesn't change the complexity of allowing them to be affected by the layer order 07:34:20 emilio: if you allow mixin definition to depend on layers, you still need to perform the whole layer traversal 07:34:24 emilio: which is annoying 07:34:33 TabAtkins: propose to not do that 07:34:41 andruud: You would need to do that if you want to cascade the mixin rules 07:34:51 andruud: at least the new layers are stable, and can reason about them 07:35:03 andruud: As we implemented it, we saw would solve everything, except the pass you don't like 07:35:13 TabAtkins: you're assuming we need to use layers to resolve names 07:35:24 emilio: We need to decide whether global or not, and I think they should be global 07:35:42 emilio: regarding @container etc, there's precedent to make some of these rules unconditionally valid. E.g. @layer does this. 07:35:53 emilio: I'm fine allowing inside @container ... but I guess you can have nested mixins 07:36:07 emilio: But we have precedent for unconditionally apply these contextual rules, might be easier 07:36:25 emilio: In terms of keeping conditional rules syntax consistent and interchangeable with @media 07:36:42 andruud: Could move the @container inside the mixin 07:36:55 emilio: Then you have to pull in the whole stack of conditional context 07:37:13 TabAtkins: Should purely based on body of mixin 07:37:24 emilio: Arguably could have said @layer inside @container is invalid 07:37:30 ack lea 07:37:30 lea, you wanted to say the same thing 07:37:51 TabAtkins: @mixins can't "carry in" their external context, any conditionality needs to be purely based on the body of the mixin, and where it's @apply'd. 07:38:05 lea: It's very clear to me that, even if there are use cases for layers inside mixins, it's hairy, and we're not sure it's useful, so moving it to next level unblocks shipping, I would vote for that, because this is a really important feature that authors want a long time 07:38:11 lea: even if very simple version now 07:38:16 lea: we can add it later 07:38:21 lea: so let's defer any complicated things to later 07:38:29 ack fantasai 07:38:35 fantasai: support what lea said 07:38:44 ... but strongly disagree that we should pretend @container doesn't exist 07:39:00 +1 we need to be able to add them later, so they should be *invalid* now 07:39:07 ... if we put an @mixing inside @container it'd be really confusing if it's unconditionally existing 07:39:40 ... @layer is a bit different, the layer existence is a side effect 07:40:04 +1 fantasai 07:40:11 ... but that's not what they're thinking of when writing @layer inside @container 07:40:13 I'm fine with that, too 07:40:25 ... the only thing that'd make sense is to shift the conditionals inside if we wanted to do that 07:40:29 q+ 07:40:34 ... making it an unconditional declaration is a no go 07:40:46 Strong, strong disagree on "shifting the conditional into the @mixin" 07:41:05 ... wrt to layers, making them invalid at first is fine. Another option might be that layer inside mixing can interact with existing layers but can't create it 07:41:08 +1 to everything fantasai just said 07:41:13 ack matthieud 07:41:14 Yeah, that's a reasonable possibility 07:41:33 matthieud: example: @scope inside ??, we don't provide a scope 07:41:42 s/??/@feature-value 07:41:46 matthieud: we ignore the @scope 07:41:51 emilio: same for @font-face 07:41:54 matthieud: re. the outer / inner at rules, if you have @font-face inside @scope the scope is already ignored 07:42:58 emilio: We do the ignoring for @scope etc for virtually every other global at-rule 07:43:10 emilio: It would be weird if this worked different from @keyframes 07:43:22 emilio: Maybe we shouldn't have allowed @keyframes inside @scope etc, but doesn't seem worth changing 07:43:30 andruud: We could try. Maybe no one is doing it 07:43:38 emilio: Yeah, seems uncommon. Fix is easy, too. 07:43:59 andruud: Suggest resolve that, for now, @layer is invalid inside mixins 07:44:19 andruud: Less sure about other one, @mixin is invalid inside @rules other than @media or @supports 07:44:26 TabAtkins: could have it inside @layer, but not act as if it's layered 07:44:34 emilio: That would be preferable 07:44:51 TabAtkins: Given elika's suggestion to allow @layer inside mixin by allowing it to work if already exists, but otherwise drop the block 07:44:59 TabAtkins: that would mean that mixin application cannot change layer order 07:45:03 I don't like that idea much 07:45:09 TabAtkins: so it would be safe to allow them to care for name resolution 07:45:15 TabAtkins: that would be a consistent model, I'd be happy with that 07:45:22 TabAtkins: let's go through the first resolutions 07:45:30 astearns: So for now, @layer is invalid inside mixins 07:45:42 RESOLVED: @layer is invalid inside mixins (for level 1) 07:46:18 astearns: Should @mixin be invalid outside of @media / @supports, or discuss @layer? 07:46:43 emilio: I think consistent thing to do would be to allow them inside @container etc. but ignore the outer condition, like we're doing for @keyframes, @keyframes, @feature-values, etc. 07:47:05 emilio: but maybe more aggressive thing to do here, which is not allow mixins to be conditional at all 07:47:09 emilio: it mitigates the 2-pass thing 07:47:13 emilio: not sure how we feel about that 07:47:21 andruud: not even subject to media queries? 07:47:35 TabAtkins: Invalid inside @media? 07:47:50 TabAtkins: Then you cannot do a media-conditioned stylesheet include 07:48:01 TabAtkins: those are super common, so want to avoid if possible 07:48:14 emilio: sad we'd need to walk the rules twice. Gets worse and worse 07:48:20 andruud: and maybe more for custom media 07:48:26 andruud: we can come back to that point ... 07:48:49 andruud: need to decide if they are ordered by layer when inside @layer 07:48:59 andruud: Is that something we want? if layer is not allowed inside, can we do it? 07:49:08 emilio: No precedent for this, but similar thing for custom media stuff 07:49:40 Q: these rules that are ignored inside @scope, are they only ignored inside literal @scope, or also @import ... scope() ? 07:49:42 emilio: these parse-time kind of things would be more reasonable to implement and less weird if we made them more like a traditional programming language, where if it's not declared before use it's not declared, and is invalid 07:49:51 emilio: That would mitigate the perf concerns while allowing stuff to be conditional 07:50:09 emilio: so you could have the current mixin set while processing the stylesheet, and you add to that set as you progress through the stylesheet 07:50:19 TabAtkins: we have precedent -- layers work like that 07:50:33 emilio: That means we don't want to make them depend on layer order, but could maybe make it work 07:50:52 emilio: I think that mitigates the interactions among parse-time thingies 07:51:09 emilio: you can conceptually define a custom media query after applying a mixin and it would kinda work 07:51:13 ack fantasai 07:51:32 fantasai: I think making it order dependent is probably fine because people are going to declare it before use 07:51:34 +1 07:51:48 ... whether we allow it inside media / layer, we need to handle @import 07:52:14 ... so you'd still need to handle the import level but not the rest 07:52:25 ... that might be a way to start with something a bit simpler 07:52:38 ... but disallowing inside conditional rules for L1 seems fine 07:52:53 emilio: I htink if we do declaration order thing, no problem making them conditional 07:52:53 emilio: I think if we do the parse-order thing, then no issue with making them conditional 07:53:12 emilio: With disallowing inside conditional rules, want to avoid having to figure out which mixins apply and which don't 07:53:28 emilio: if we do order thing, then can process everything in a single pass 07:53:37 emilio: it allows you to do conditional application just like you do layers 07:53:41 emilio: I think that's preferable 07:53:52 emilio: Mixins would be effectively a state in this pass where we compute the applicable rules 07:54:02 emilio: WebKit called it ruleset building, Gecko has something too 07:54:09 andruud: Are the mixin names affected by layer order? 07:54:15 emilio: that's a question to answer. I'd rather not 07:54:24 TabAtkins: I think it's independent at this point, could go either way 07:54:35 emilio: The layer where the mixin is define dalready exists, and you can compare them 07:54:42 emilio: So you can keep around the later mixin and layer order 07:54:51 andruud: At that point you can already figure out which is stronger 07:55:05 emilio: Yeah, you can calculate it on the fly 07:55:23 emilio: On one hand I'd like to think of mixins as independent of layers, as a "parse-time" feature, where you define things to apply 07:55:33 emilio: but if we're making conditional on MQ, can make it depend on layers 07:55:38 emilio: but either way it's non-problematic 07:55:56 TabAtkins: I propose you can put them inside the layer, and defer question of whether they respond to the layer strength 07:56:09 TabAtkins: only options are purely global, or if layered 07:56:24 TabAtkins: only matters if you have the same mixin name declared multiple times 07:56:38 andruud: we go with order-dependent, that way they can be valid in @media and @supports 07:56:48 emilio: we have to decide if valid inside @container and @scope 07:56:59 TabAtkins: Existing precedent of ignoring the conditional seems fine 07:57:14 emilio: we could file an issue to reconsider that, see if we could make these invalid at parse time rather than unconditionally applying 07:57:24 emilio: but I'd argue that we should be consistent with existing precedent 07:57:27 [several nodding] 07:57:34 emilio: and change all if we think it's worth the pain of changing 07:57:41 miriam: I agree 07:57:51 miriam: other precedent I note is that name-defining @rules are affected by layers 07:58:05 emilio: but @mixin is different, it's more like layers 07:58:09 fantasai: that's also affected by layering! 07:58:21 emilio: If we go with approach of, must declare before use, then not problematic either way 07:58:28 emilio: might be a bit weird but seems fine 07:58:37 astearns: So should we need resolution that mixins must be defined before use 07:58:42 astearns: any objections? 07:58:48 RESOLVED: Mixins have to be defined before use 07:59:01 fantasai: Do we want a similar resolution for custom MQ 07:59:08 astearns: any objections? 07:59:26 RESOLVED: Custom media queries need to be defined before use 07:59:33 (My only other approach I think could have worked for these resolutions would be to use pure lexical scoping, so they didn't leak outside of stylesheets. But that's pretty limiting.) 07:59:56 emilio: Let's make consistent with @keyframes etc. and file issue to change if we don't like it 08:00:09 astearns: objections to being consistent with @keyframes wrt where valid? 08:00:29 RESOLVED: @mixin is valid wherever @keyframes is valid 08:01:30 SUMMARY: Still open question of whether @mixin declarations are layered -- either way is acceptable implementation-wise 08:02:07 ACTION: TabAtkins to file issue on whether global name-defining things should be invalid inside contextual conditionsl such as @container or @scope 08:02:32 Subtopic: [css-conditional-5] Clarify behavior of named container queries in shadow trees 08:02:49 astearns: Miriam, you had a question about the resolution here? 08:03:00 miriam: Rune clarified his intent, but we didn't clarify intent as a group 08:03:19 miriam: This keeps coming up where authors want a way for container queries to be usable across shadow roots, that includes names 08:03:30 miriam: we've gone back and forth on what containers rae visible 08:03:37 miriam: but in some implementations names are not available 08:03:48 miriam: can you reference a container name across the shadow boundary? 08:03:51 q+ 08:03:55 q+ 08:04:01 ack emilio 08:04:10 emilio: On one hand, we resolved that CQ work on flat tree rather than shadow tree 08:04:22 emilio: so seems potentially consistent to expose the name 08:04:26 emilio: I don't mind either way 08:04:32 ack futhark 08:04:48 futhark: Wrt whether container-name is global or tree-scoped 08:04:53 futhark: working with slotted 08:04:59 futhark: would have to make it global 08:05:10 futhark: but we need to make it explicit in the spec if we want to make it global 08:05:19 futhark: because scoping spec defaults to making names tree-scoped 08:05:54 I don't think I have a strong opinion here, but the arguments given by the author in the thread sound reasonable. I'm okay with making them global. 08:05:57 miriam: My proposal is to make ti global 08:06:09 astearns: any concerns with making this change? 08:06:26 lea: Is this that named container queries inside shadow would be global, or light dom would be global? 08:06:29 TabAtkins: both 08:06:31 emilio: global is global 08:06:49 emilio: sketchy case is whether a slotted element can observe a name inside the shadow tree 08:06:51 q? 08:06:56 emilio: I don't feel strongly either way 08:07:02 emilio: but size containment follows flat tree 08:07:15 futhark: we have interop on anonymous containers 08:07:46 lea: what happens if you're slotting an element inside a component with shadow dom around it, there is a named container inside the shadow DOM, and you have same name in the light DOM 08:07:56 lea: seems to me the light DOM should take precedence 08:08:02 emilio: well in this proposal it wouldn't 08:08:30 emilio: but if you are CQ against an anonymous container, you'd reference the shadow DOM container, not the light DOM ancestor container 08:08:45 lea: Seems surprising when, as an author, I use a component that idk internals 08:08:55 lea: and I'm using my own names for my stuff 08:09:04 lea: and shadow DOM happens to use the same name, stuff breaks, and Idk whay 08:09:16 emilio: Could make the same argument with CQ units 08:09:27 lea: I think anything that doesn't define a name is inherently looser 08:09:37 lea: container units can't specify a name, but we have an issue on that 08:09:50 lea: but in cases where you name things, you can be more specific 08:09:57 lea: for actual names to leak out it's a problem 08:10:13 lea: what issue is asking for is reasonable: if there are no conflicts in the light DOM 08:10:34 miriam: that also doesn't match how container names are used, can use them multiple times, and match to the closest one 08:10:40 miriam: so shadow vs light DOM seems ... 08:10:46 miriam: names aren't expected to be unique 08:10:55 lea: if light DOM names leak into shadow DOM, seems ok 08:11:03 lea: it's leaking from shadow outside that's a problem 08:11:16 noamr has joined #css 08:11:19 lea: should be possible to define whatever names you want inside a shadow component, and not worry about leakage to outside 08:11:28 lea: could always prefix stuff, but point of shadow DOM was to avoid having to do that 08:11:39 emilio: Well, people disagree what shadow DOM is for. :) 08:11:48 lea: I usually argue in favor of less encapsulation 08:12:01 lea: but there's a difference between making light DOM visible to shadow, vs other way around 08:12:11 emilio: custom properties inherit through 08:12:27 miriam: CQ you're looking at close context, so more similar to custom property inheritance 08:12:31 lea: that's a good argument 08:12:46 astearns: My understanding is that current WPT do have this leakage 08:12:48 emilio: no? 08:12:55 emilio: Firefox behaves as we want to resolve 08:13:20 futhark: Yes, based on test results, FF makes them global while WebKit/Blink make them scoped 08:13:26 emilio: I've never found a compat issue, fwiw 08:13:35 q? 08:13:36 lea: I find the inheritance argument compelling 08:14:04 astearns: so the proposed resolution is that CQ names are global, whether or not they're declared in the shadow DOM 08:14:07 emilio: They're not tree-scoped 08:14:30 RESOLVED: Container names are not tree-scoped 08:15:06 Subtopic: [mediaqueries-5] Defining `@custom-media` inside conditional at-rules 08:15:20 As previously discussed... 08:15:30 RESOLVED: @custom-media need to be declared before use 08:16:01 Subtopic: [css-conditional-6] Behavior of style(0 = 0px) 08:16:32 andruud: Parser has behavior for that you can supply 0 without unit 08:16:46 andruud: question came up during range queries, whether we should keep that behavior for comparison 08:16:55 andruud: e.g. is 0 = 0px for style queries? 08:17:07 andruud: zero is a number, 0px is a length, so not equal 08:17:20 q+ 08:17:27 andruud: in terms of consensus, it seems to be everyone against tab ;) 08:17:28 q+ 08:17:30 q+ 08:17:34 ack miriam 08:17:43 q+ 08:17:45 ack emilio 08:17:48 q+ 08:17:48 miriam: I don't have a strong opinion either, just unhappy that neither option is consistent across the board 08:17:52 emilio: I will side with Tab on this one 08:17:57 emilio: style queries are generally untyped 08:18:05 q? 08:18:06 q 08:18:11 emilio: and you have the same issue with calc(), don't know if zero is degrees length etc. 08:18:13 q+ 08:18:21 TabAtkins: unitless zeros in calc() screw up figuring out the type of the calc() 08:18:27 TabAtkins: that doesn't apply here, just comparing two things 08:18:35 romain has joined #css 08:18:45 TabAtkins: We could go either way 08:18:59 emilio: for something like width > 0, you know width is a length 08:19:27 andruud: yeah, we'd need to do different special casing 08:19:30 like, is `calc(0 / 10px)`, is that unit 1/length, or just ? 08:19:50 TabAtkins: but you can use width > 0 in MQ 08:19:59 emilio: you know you're parsing a length at that point 08:20:10 TabAtkins: yes but because they're zeros... 08:20:20 emilio: implementable, not a big issue 08:20:27 ack kizu 08:20:45 kizu: I think I want them ... 08:20:51 kizu: if you define custom registered property [missed] 08:21:13 kizu: for type, getting type of a custom property and you want to understand later on, you explicitly say "I'm checking the type on this" 08:21:27 kizu: but authors will expect 0 to 0px, so consistent for if() etc. to work this way 08:21:30 ack noamr 08:21:37 noamr: aren't style queries also typed? 08:21:45 https://codepen.io/kizu/pen/azvYVJw 08:21:49 noamr: can't we do something where if both values when parsed ... 08:21:55 TabAtkins: no, we don't necessarily know 08:22:04 noamr: they're all matching a property 08:22:11 TabAtkins: not necessarily, e.g. inside an 'if' 08:22:13 ack oriol 08:22:24 oriol: I'm slightly more with Tab here 08:22:42 oriol: I could go either way for lenghts, but other dimensions that can accept unitless zeros so weird to accept 08:22:51 ack lea 08:22:52 oriol: even for lenghts, lean more towards Tab, but it's a weak opinion 08:23:09 lea: My expectation is to compare the unitless zero to the other side 08:23:14 lea: if they're valid, then they should match 08:23:40 lea: e.g. zero for angles is not generally valid 08:23:49 lea: so would expect not to match in that case 08:24:12 lea: Where did we resolve to use style() for these comparisons 08:24:24 ack fantasai 08:24:29 fantasai: what lea said 08:25:24 q+ 08:25:24 noamr: I think it would be sensible to start by shipping something more rigid, and then add type-based equivalence later, maybe more than just unitless zero 08:25:36 q- 08:25:39 astearns: that would be type coercion 08:25:41 q+ 08:25:52 q- (sorry) 08:25:54 noamr: start with that and then do === later 08:26:10 noamr: more use cases than just unitless zero 08:26:25 s/be type/be explicit type/ 08:26:40 ack lea 08:26:43 lea: My concern is case where you have a custom property (token stream) and then you register as a length, and now it stops matching 08:26:57 lea: would be better if consistent with how lengths generally work 08:27:01 ack fantasai 08:27:16 fantasai: from a user perspective we’re used to 0 = 0px 08:27:16 +1 08:27:34 I would be okay with a literal 0 allowing matching against a 0 *or* a 0 08:27:45 but a calculated 0 shouldn't be, maybe? 08:27:47 +1 to fantasai 08:28:02 +1 (but that inconsistency is already confusing people in calc) 08:28:17 1. calc()-consistency, 0 != 0px 08:28:30 2. property-consistency, 0 == 0px (but no other unit) 08:29:20 TabAtkins: it is the case that calc(0) is invalid in [missed], so it would have to be a literal zero 08:29:32 s/missed/width prop/ 08:29:53 astearns: Proposed resolution that literal zero does equal a 0 length for conditions 08:30:04 astearns: Anyone want to argue against? 08:30:10 astearns: Anyone want to object? 08:30:25 RESOLVED: 0 and 0px are quivalent for conditions 08:30:26 (making clear, i mistyped above; "no other type", not "no other unit". 0 == 0rem, too) 08:31:59 Subtopic: [css-conditional] `@supports-condition`, for larger feature queries and named reuse 08:32:31 lea: We have a bunch of issues around "how do we express this thing in @supports" 08:32:39 lea: we're creating a parallel syntax to describe CSS syntax 08:32:54 lea: makes it difficult to design, and also confusing for authors who don't understand CSS syntax well 08:33:11 lea: e.g. authors don't understand difference between descriptor and property 08:33:27 lea: What if you could just stuff an entire block of stuff into a condition and ask if it's valid? 08:33:31 lea: ... 08:34:00 (thanks to anders, too, for css parsing being robust) 08:34:03 lea: CSS parsing is robust enough to handle all sorts of invalid things, so what if we had something like @supports-condition where you can stuff whatever you want 08:34:18 lea: could be a selector and rule, or properties, or any at-rule, and you would check if it's valid 08:34:29 lea: could even check at-rules inside at-rules 08:34:39 lea: avoids needing to invent a meta-syntax for everything 08:34:53 lea: and also gives us more complex feature queries 08:34:59 lea: parallel to custom-media 08:35:06 lea: also provide maintainability benefit 08:35:29 lea: we still need special functions for things that don't cause a parse error but need to check support 08:35:47 lea: Even at-rule() could have simple version for does this at-rule exist 08:35:56 lea: but for more complicated things, better to say the syntax you're testing 08:36:00 lea: some issue raised 08:36:16 lea: but seems reasonable you might want to combine named feature queries with inline feature queries 08:36:23 lea: also, should be able to name inline queries 08:36:34 lea: so rule could have block syntax and non-block syntax 08:36:48 lea: also question of how do you combine named feature queries with inline queries to create higher-level queries 08:36:53 lea: maybe useful for v2 08:37:05 lea: main issue is that condition token requries parens around condition 08:37:36 lea: so either have two syntaxes, e.g. @supports --named-condition { ...} 08:37:44 lea: or a parenthesized version 08:37:59 q+ 08:38:13 lea: do we allow plain --ident syntax? or parenthesize? 08:38:27 lea: I think it's common to parenthesize only when need to group, not in advance 08:38:39 lea: kbabbitt: raised issues wrt at-import and supports conditions 08:38:41 q+ 08:38:52 lea: maybe you defer loading until the name is defined 08:39:02 lea: multiple conditions with same name, last one wins 08:39:18 lea: question of ordering wrt @import 08:39:29 lea: but we should have a JS method also 08:39:41 lea: JS method could even give you more info 08:39:50 ack kbabbitt 08:39:53 kbabbitt: I like the set of ideas presented here 08:39:58 kbabbitt: I have some reservations around the edge cases 08:40:01 q+ 08:40:13 kbabbitt: I do agree that we still want the simple at-rule method on @supports for simple cases if an at-rule is recognized at all 08:40:31 kbabbitt: useful for cases such as @starting-style where you don't want to bother setting up extra context 08:40:42 kbabbitt: for JS query, just have a method that accepts a fragment of CSS 08:41:03 kbabbitt: other interesting case that came up is MQ, where the parsing is forgiving for cases where particular media feature can be parsed successfully but not supported 08:41:18 kbabbitt: need some additional handling there 08:41:29 q? 08:41:45 kbabbitt: one other thing, in terms of dealing with supports conditions on import, what could happen if author adds supports condition later 08:41:50 q+ 08:41:58 kbabbitt: doing it with media queries already 08:42:08 kbabbitt: maybe some weirdness there 08:42:16 q+ 08:42:23 kbabbitt: overall, I like it as a direction. I think it's simple and more extensible than adding functions for support 08:42:23 q+ 08:42:23 ack TabAtkins 08:42:34 q+ 08:42:35 TabAtkins: +1 to what kbabbitt said, good idea in general 08:42:44 TabAtkins: question about parsing context of stuff inside the rule 08:43:01 TabAtkins: proposal make sit as if you're inside an existing style rule, so immediately test for properties 08:43:13 TabAtkins: Need to be careful so that those things not allowed inside a style rule would work 08:43:28 TabAtkins: issues wrt cyclic resolved by earlier discussion about define-before-use 08:43:39 q+ 08:43:48 q- 08:43:56 TabAtkins: Final bit about using inside an @import, I think we should have the new custom whatevers to have a JS API so you can register them in JS 08:44:04 TabAtkins: and that can be globally available 08:44:11 +1 on kbabitt's points 08:44:18 ack astearns 08:44:22 TabAtkins: treated as appearing before start of all styles 08:44:38 astearns: I like the idea, a bit skeptical of the promise that this will save us from inventing other syntaxes 08:44:51 astearns: places where we do parse things more liberally 08:45:02 astearns: I think we should have this, but I think we're going to keep adding microsyntaxes anyway 08:45:20 astearns: and this reminds me of conversations with miriam and she says "this is another mixin isn't it" 08:45:39 astearns: various ways to name a block of CSS, can we have a generic solution for all of them 08:45:46 ack fantasai 08:45:52 scribe+ 08:46:21 fantasai: For @import, we should allow declaring these conditions as well as custom media, before @import so they can be used for conditional imports 08:46:28 fantasai: we already allow this for layer order 08:46:41 fantasai: for exactly this reason, you need to be able to control the layering of the imports, so there's precedent 08:47:06 fantasai: wrt this the context opened up by the custom supports condition should be a top level context, if you want to be inside a style rule, be inside a style rule 08:47:17 +1 to it being a top-level context 08:47:30 fantasai: if you want to test declarations that's already easy for @supports 08:47:45 in fact, I'd go slightly stronger and say it should be "brand new stylesheet context" so various features of @import can be tested 08:48:08 fantasai: if we want to do inline @supports opening bracket should already get you in that context 08:48:16 kbabbitt +1 08:48:19 q- 08:48:21 @supports ({ top-level context check thing }) { stuff } 08:48:29 equivalent to 08:48:42 @supports-condition --foo { top-level context check thing }; 08:48:42 q+ 08:48:44 ack lea 08:48:45 @supports --foo; 08:48:52 s/;/ { stuff } 08:49:08 (we avoided inlining rules into @supports before because it's just unreadable. nothing wrong with it parsing-wise, it's just kinda ridiculous to actually look at) 08:49:18 lea: I agree wrt supporting these declarations prior to @important 08:49:33 s/@important/@import/ 08:49:36 s/ @important/ @import/ 08:50:07 lea: for testing media query features that are parsed vs supported, same as font-tech(), still need microsyntax 08:50:14 lea: but not having to create a new one for everything is a gain. 08:50:32 lea: For Tab, I was going to say, I'd have least constrained context 08:50:47 lea: but suggested that should be most unconstrained existing context, i.e. start of new style sheet 08:51:02 lea: some things are less easy, e.g. declarations, but like fantasai said it's easy to do already 08:51:18 lea: consistency of using existing well-defined context outweighs being able to nest raw declaraitons 08:51:35 lea: Alan said we'll still need functions that parallel syntax, I don't see why except as shortcuts 08:51:45 lea: we don't even need a descriptor arguemnt for at-rule, just test the at-rule 08:51:55 lea: it cuts down scope very much for these functions, even when a convenience 08:52:08 lea: so I do think we should try to make sure verything we want to test for can be done 08:52:24 lea: it is interesting idea to combine with mixins, but some things aren't allowed in mixins 08:52:27 lea: and here everything is allowed 08:52:29 +1, this reduces the value of new testing functions from "we need this to make it testable at all" to just "this will be a common test and it's inconvenient to write out fully" 08:52:45 fantasai: yea, I think they have to be separate. Mixins take argument,s bunch of other stuff 08:52:45 q? 08:52:45 q+ 08:52:50 ack SebastianZ 08:52:59 TabAtkins, depends how you format your source code really 08:53:10 SebastianZ: I think this should be specced and implemented ASAP 08:53:17 SebastianZ: we added at-rule() in 2022 and still not in a spec! 08:53:27 SebastianZ: in the meantime many ne at-rules which can't be tested for 08:53:34 SebastianZ: I'm totally for this @supports condition 08:53:44 ack matthieud 08:53:56 matthieud: right now, @supports selector() doesn't take context into account 08:54:05 matthieud: e.g. relative selector won't check out 08:54:08 (I fell really behind around the end of my full-WFH isolation, sorry about that.) 08:54:12 q- 08:54:16 ack noamr 08:54:32 noamr: Maybe this could be an extension of custom-media, rather than another thing 08:54:49 noamr: idk if this is too much, but feels like we're having a lot of tidbits of names that are used in the same name 08:54:54 noamr: that'll simplify things 08:54:59 q? 08:55:07 noamr: custom-media is just an at-rule with a semicolon, not complicated 08:55:10 ack fantasai 08:55:38 fantasai: at supports conditions and @media are doing largely the same thing, declaring a name for a condition, and should be more consistent 08:55:38 q+ 08:55:47 ack lea 08:56:00 s/at supports/@supports-condition/ 08:56:07 s/@media/@custom-media 08:56:14 They should be `@custom-supports`. Unless we can finally agree on `@when` and make them mergeable... 08:56:36 lea: Value in harmonizing, but my understanding of @custom-media is defining an alias over what you can do in media 08:56:48 lea: whereas this allows new stuff 08:56:58 +1 on TabAtkins 08:57:04 fantasai: I was suggesting to be able to do it inline also 08:57:11 lea: Seems awkward. As long as it's not the only way. 08:57:25 TabAtkins: Until we have merged conditional, I think they should be separate at-rules 08:57:33 fantasai: They should at least have similar naming pattern 08:57:37 TabAtkins: yes, @custom-supports 08:57:51 lea: or @media-condition 08:58:17 fantasai: I like media-condition and supports-condition 08:58:28 or @media-query and @supports-query 08:58:47 astearns: Lots of feedback and enthusiasm, seems like we should work on it 08:59:00 lea: Draft into next level of conditoinal? 08:59:19 astearns: Add it to a new diff spec? Happy to take that resolution, or put it off if ppl wnat more details before a draft 08:59:25 fantasai: seems ready for a draft 08:59:53 lea: Shoudl be in the same spec as @custom-media 08:59:56 fantasai: yes 09:00:03 other naming idea: @supports-test @media-test 09:00:14 RESOLVED: Draft this into the same spec as @custom-media 09:00:57 RESOLVED: Add Lea as editor of that spec 09:02:01 scribe+ 09:02:19 github-bot, take up https://github.com/w3c/csswg-drafts/issues/6966 09:02:19 Topic: [css-conditional-5] Add ability to test for at-rule preludes 09:02:19 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6966. 09:02:33 kbabbitt: this is about @supports at-rule(...) 09:02:37 kbabbitt: resolved to add a few years ago 09:02:46 kbabbitt: discussion in this issue to expand the resolution... 09:02:56 kbabbitt: previous we resolved to just test at-rule name, or at-rule name + descriptor value 09:03:08 kbabbitt: original proposal was to let you test an entire at-rule 09:03:08 s/Topic/Subtopic/ 09:03:14 kbabbitt: we just resolved to change that 09:03:25 kbabbitt: to do it with the new custom thing 09:03:39 kbabbitt: But being able to test for just a simple name is useful, much simpler for an easy check 09:03:46 q+ 09:03:48 kbabbitt: Versus writing out the entire rule 09:03:53 +1 09:03:55 +1 09:04:00 ack noamr 09:04:06 kbabbitt: So based on the resolution from earlier, i propose we scale at-rule() back to just allow an at-rule name, and let descriptors be handled by the rest 09:04:30 noamr: at-rule name is boudn to be foot-gunny, you could test the name expecting the "modern" version of an at-rule, but a browser only supports an older version 09:04:44 lea: that's why we have the more elaborate syntax 09:05:07 noamr: yeah, but for a plain name, you just rely on the browser having a list of at-rules 09:05:13 it _is_ the same argument where we resolved against doing this for bare properties 09:05:16 noamr: and you hope that list matches everything you actually want to do 09:05:16 q+ 09:05:19 it's not, i'll q+ 09:05:21 q+ 09:05:28 q- 09:05:29 q+ 09:05:45 noamr: so if we add something to @font-face, your at-rule(@font-face) test might not be useful 09:05:55 noamr: not necessarily a reason not to do it, just to consider 09:05:59 ack TabAtkins 09:06:21 TabAtkins: Lea will say this is the same argument we use to test a bare property name 09:06:33 TabAtkins: it is broadly the same, but different in particulars 09:06:46 TabAtkins: specifically, we change properties a lot more than @rules, we add new values constantly 09:06:53 TabAtkins: we change @rules sometimes, but not all the time 09:06:59 TabAtkins: so naming is more stable for @rules 09:07:06 TabAtkins: test property + value is not much to type, usually 09:07:20 TabAtkins: typing a whole @rule to test the existence of something is a large burden 09:07:32 TabAtkins: amount of work is different, so shortcut is worth it 09:07:51 noamr: not an objection, just to make sure we considered this 09:08:00 ack lea 09:08:11 lea: I was going to say this is basically the same argument that we decided against testing bar eproeprties 09:08:24 lea: bc we were worried about changing the syntax of proeprties causing authors to make bad assumptions 09:08:40 lea: i do agree with tab's argument abou tnot needing the indirection of a custom supports 09:08:49 lea: But I also think we should allow testing against bare properties 09:09:04 lea: This also creates footguns because authors might test for the wrong thing 09:09:14 lea: but i definitely don't object to still ahving the at-rule() shortcut 09:09:23 astearns: other comments? 09:09:30 lea: I wonder if we could harmonize the syntax 09:09:47 `@supports (@foo)` 09:10:02 `@support at(foo)` 09:10:03 astearns: I'd object to the bare parens like that, i want more meaning 09:11:02 TabAtkins: At that point we might as well jsut use the full at-rule() name, and we need the @, as it's part of the name 09:11:10 TabAtkins: as proposed in the issue 09:11:28 astearns: objections to reoslving on that? 09:12:10 RESOLVED: Cut down the at-rule test to just `at-rule(@foo)` (no descriptor testing) 09:12:18 Woohoow! 09:13:11 github-bot: subtopic https://github.com/w3c/csswg-drafts/issues/11116 09:13:11 Subtopic: [css-conditional] Behavior of @supports(at-rule(@import)) 09:13:11 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11116. 09:13:30 kbabbitt: This is about what at-rules can be tested by at-rule(), partiuclarly those with positional requirements 09:13:37 kbabbitt: anders asked about @charset and @import 09:13:55 kbabbitt: proposed resolution is @import is testable, @charset is not, because @charset isn't actually an at-rule, it just looks like one 09:14:08 kbabbitt: from Tab's epxlanation, @charset is a legacy feature that authors shoudln't be using anymore 09:14:37 q? 09:14:40 q+ 09:14:48 astearns: so proposed resolution is at-rule(@charset) is not testable, but at-rule(@import) is? 09:14:49 ack lea 09:15:08 lea: does this apply just to at-rule(), or to the larger @supports-condition thing? 09:15:17 kbabbitt: this just applies to at-rule() right now 09:15:19 astearns: objections? 09:15:33 RESOLVED: at-rule(@charset) is invalid, but at-rule(@import) is allowed 09:16:34 github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/11117 09:16:34 Subtopic: [css-conditional] Nested at-rules within at-rule() 09:16:34 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11117. 09:16:51 kbabbitt: issue is whether at-rules that are only valid within another at-rule can be tested by at-rule() 09:16:55 kbabbitt: i propose yes 09:16:59 TabAtkins: I also say yes 09:17:04 astearns: seeing nodding 09:17:16 astearns: objections to allowing nested at-rules to be tested by at-rule()? 09:17:35 RESOLVED: at-rule() can test for at-rules that are only valid inside other at-rules (like at-rule(@swash)) 09:18:32 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12575 09:18:32 Topic: [css-pseudo-4] Proxying pseudo-elements as "real" (``) elements 09:18:32 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12575. 09:19:07 noamr: this is from a proposal for how to deal with pseudo elements 09:19:16 noamr: we're getting a lot more pseudo-elements added by VT, carousel, etc 09:19:23 noamr: plus older ones like before/after 09:19:37 noamr: lot of requests of how to get event listeners for them, getBoundingClientRect, etc 09:19:50 noamr: usually things related to layout and rendering. UI events, like clicks or pointer events 09:20:11 noamr: so an issue is, is this a bit more than style, or a little less than dom? 09:20:15 noamr: I think usually the former 09:21:00 noamr: discussed in whatwg, lot of objection to adding more DOM-ish thing (like addeventlistener) to things that aren't in the dom 09:21:11 noamr: my proposal then is a bit different, entirely in css 09:21:22 noamr: proposal is we add actual DOM elements that can represent one or more pseudo elements 09:21:41 noamr: the original proposal was to use , but has evolved a bit 09:21:57 noamr: do `display: pseudo-element`; it makes the element a layout/event proxy for the pseudo 09:22:09 noamr: it's regular dom, you can add event listeners, aria, popovertarget, etc 09:22:35 noamr: but everything to do with layout/rendering/etc is still normal css, per the pseudo-elmeent's definition 09:22:42 q+ 09:22:46 noamr: this is slightly radical, not sure if I've explained all the tidbits 09:22:56 noamr: thinking of this as a display value because it's not actually displayed at all 09:23:04 noamr: no layout, no rendering, similar to dipslay:none 09:23:11 ack futhark 09:23:14 q+ 09:23:15 s/Topic/Subtopic 09:23:21 I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai 09:23:28 futhark: what about like :nth-child() and such? should be skipped by selectors? 09:23:47 noamr: it's part of the dom, so yes, selectors will see it. but you can't add any meaningful styles for it 09:23:52 noamr: it's effectively display:none 09:24:03 i/Subtopic: [css-conditional-5] Clarify/Topic: Conditional Rules 09:24:09 I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai 09:24:15 noamr: as neutral as possible for DOM and related stuff 09:24:15 ack lea 09:24:24 lea: I quite like the idea. like that this is really a dom element 09:24:39 lea: also ahs potential for another pain point. pseudos can't currnetly be exposed by a web component 09:24:40 i/Subtopic: [css-pseudo/Topic: Pseudo-selectors/ 09:24:46 I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai 09:24:53 lea: you can expose elements as a part, but not pseudo-elements 09:24:53 lea: maybe there's some synergy there 09:25:09 lea: you can expose a as a ::part, after all 09:25:26 noamr: correct, it's a regular element, bu tit's not rendered 09:25:31 q+ 09:25:58 TabAtkins: That means Lea's request wouldn't work, the element isn't meaningfully styleable. 09:26:07 noamr: ah right, you can't style it from outside 09:26:28 astearns: for your use-case of a component using a native element and wanting to expose its pseudos, where would you put this new element backing for it? 09:26:48 lea: you usually have it in your shadow dom already... 09:27:02 lea: another complication. this assumes you can nest the slots inside the element, but not all elements take contents 09:27:07 ack astearns 09:27:22 TabAtkins: yeah, like a pseudo from an input? 09:27:23 s/lea: you usually have it in your shadow dom already.../lea: you have it in your shadow dom already — if it's nested within another component, you'd use `exportparts`/ 09:27:42 noamr: Possibly could use , so it doesn't need to be a direct child of the element it's targeting 09:28:01 noamr: we could perhaps start with tree-abiding, though, and then have some semantic for cross-referencing 09:28:39 noamr: But the main initial use-case is for things like carousel buttons or VT before/after, things that are content-ful 09:28:50 noamr: but there's space to make it all work with some extnesions, i'd say 09:29:35 q+ 09:29:39 q+ 09:29:41 q+ 09:29:43 astearns: anyone else ahve reservations about requiring users to chang emarkup to get this added functionality on pseudos? a little weird that css wants to add event listenres to its own pseudos, and to do that you ahve to go outside of css 09:29:52 q- 09:29:53 ack sakhapov 09:30:11 sakhapov: the alternative was CSSPseudoElement in JS, and we discussed the issue of existence 09:30:30 sakhapov: we decided the CSSPsuedoElement was a persistent handle even if the pseudo didn't exist at the time 09:30:46 noamr: I don't see it as CSS wanting to add something, the web platform needs something between DOM and CSS 09:30:54 noamr: pseudo-elements are in the middle there, and can fall behind the chairs 09:31:04 noamr: philosophical question of what's DOM and what's CSS is blurry 09:31:25 noamr: But this is really close to a DOM thing - bubbling event listernes, direct DOM access... everything becomes pretty DOM-ish rather than a style thing 09:31:36 dmangal has joined #css 09:31:41 noamr: So I don't see this as a problem, I see it as a feature, it's actually in the DOM 09:31:46 agreed that event listeners are DOMmish :) 09:32:03 noamr: so the css feature is just to dipslay it like it's styled by th enormal css feature 09:32:18 noamr: about the reflection thing, I think we can add things to cssom that lets you query info about the pseudo-element 09:32:32 noamr: that can be the CSSPseudoElement API, reflecting about this connection 09:33:33 TabAtkins: Because the pseudo-element doesn't actually do anything stylistically, its presence in the DOM doens't result in anything happening, whether pseudo exists is a CSS question, I'm ok with it 09:33:50 TabAtkins: I would be uncomfortable if markup was necessary to create the pseudo 09:34:02 TabAtkins: but since a proxy, it's fine 09:34:09 TabAtkins: They'll work if they need to, won't work if they don't need to 09:34:13 q+ 09:34:16 q+ 09:34:17 q- 09:34:19 TabAtkins: should be flexible wrt CSS, so happy with how this looks 09:34:28 ack sakhapov 09:35:07 sakhapov: one point, in carousel we have ::column pseudo which isn't really representable in DOM, and in there you can have ::scroll-marker. the number of these is layout-dependent, so you can't know in advance how many s you'll need. 09:35:14 sakhapov: not sure how that's addressable 09:35:30 noamr: I talked to that point a little bit. the proxy element can represeent one or more pseudo-elements 09:35:49 noamr: so if you have multiple scroll-buttons, etc, the proxy is a proxy for all the pseudo-elements with that name 09:36:05 noamr: in terms of events, there are a few things we'll have to figure out, like gBCR() 09:36:38 noamr: but I think some of those internall css reflection mechanisms... "this element supports ten pseudo-elements", we can start with the idea that represents 0-N pseudos 09:36:59 sakhapov: and with this approach you'll lose the ability to identify which marker, specifically, was clicked 09:37:10 noamr: I think we'll have to take some of the things from the addEventListnere proposal 09:37:34 noamr: a lot fo the concerns whatwg had with it will be gone. we have a proper element now that can bubble, etc. and then we can add info to the event about what the exact pseudo it's for 09:37:42 noamr: so we can have JS reflection about it to solve that 09:38:04 noamr: but those are details we'll need to discuss, it's not set yet. but i think ther'es a trajectory to solving it 09:38:13 q? 09:38:17 ack andruud 09:38:30 andruud: tab, you argued we'd be okay with it because the pseudos don't do anythign stylistically 09:38:40 andruud: but this'll change you sibling index. is that okay? 09:38:54 andruud: should we really not doing special about that? 09:39:39 q+ 09:40:12 q+ 09:40:23 TabAtkins: [missed, but re-explaining why they thin kthis is fine] 09:40:34 zakim, close queue 09:40:34 ok, astearns, the speaker queue is closed 09:40:37 andruud: sibling-index() would still just give changed results, tho 09:40:40 ack lea 09:40:46 TabAtkins: yeah, it would jsut need to get worked around 09:40:50 ^ sibling-count() 09:41:06 lea: I do think not being able to nest them into some elements would be a blocker, don't wnat to invent something new for or 09:42:07 lea: not as much of a blocker, i think it would be desirable to expose pseudos with this mechanism for shadows 09:42:18 TabAtkins: I have a proposal in an issue for allowing pseudos in exportparts="", fwiw 09:42:25 lea: ah, let's look at that then. but still the first point 09:42:33 ack kizu 09:42:34 noamr: point taken, we can make sure it's addressed in the proposal 09:42:42 kizu: two things, maybe long shot 09:42:52 noamr: I suppose it could use a relative element reference for empty elements, whatever we decide to do with those :D 09:43:28 s/noamr: I suppose it could use a relative element reference for empty elements, whatever we decide to do with those :D /noamr, I suppose it could use a relative element reference for empty elements, whatever we decide to do with those :D / 09:43:31 scribe+ 09:43:35 scribe- lea 09:43:47 kizu: would be nice to allow inline styles 09:44:00 ... so that they could be proxied to the pseudo-elements 09:44:19 ... we probably don't want to allow any content inside, and as an author I'd expect content to work 09:44:19 q+ 09:44:32 ... this could fix some of the potential a11y issues with pseudos 09:44:45 ... so anything that can translate the dom could translate it 09:44:53 ... so this could be some sort of templating solution 09:45:09 ... so you could put inline svg inside the button's before slot 09:45:34 astearns: I think we can take this back to the issue 09:45:40 astearns: roman just introduced an entirely new idea 09:45:50 emilio: if you do ::before, the 'content' property would create the content inside that element 09:45:56 emilio: that's why you don't want to mess with it 09:46:06 astearns: it's an interesting idea, we should explore more, but no more time to day 09:46:11 astearns: Noam, let's take this back to the issue 09:46:19 astearns: you'll also need to take this to WHATNOT 09:46:46 noamr: not introducing a new alement 09:46:58 noamr: let's take back to issue with minutes 09:46:58 (I think we do need a new element, we can discuss in the issue.) 09:47:04 noamr: seems fairly positive in the room 09:47:18 astearns: I am cautiously positive. :) Seems like an interesting idea but also very scary 09:47:22 Topic: Shapes 09:47:36 github-bot, subtopic https://github.com/w3c/csswg-drafts/issues/11662 09:47:36 Subtopic: [css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width` 09:47:36 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11662. 09:47:48 noamr: this is about border-shape 09:47:51 dmangal has left #css 09:47:52 zakim, open queue 09:47:52 ok, astearns, the speaker queue is open 09:47:52 noamr: border-shape receives two paths 09:47:58 noamr: unclear what to do with the border proeprties 09:48:07 noamr: researched a lot, discussed with smfr 09:48:21 noamr: concluded there's no solution for a non-uniform border width. no way to do it that's useful 09:48:40 noamr: and very few border styles are supported for general-purpose shapes (mroe than just a box) 09:48:57 noamr: i suggested we treat this whole thing a bit differently in terms of styling, and use the SVG fill and stroke props 09:49:16 q+ 09:49:17 noamr: so we ignore border width entirely, and use stroke to stroke the two paths, fill to fill between them 09:49:25 noamr: if you have only one shape, it's only stroked, no fill 09:49:38 noamr: you get all the svg functionality, dashing, paint servers, etc 09:49:50 noamr: i'd say it's a little confusing at first, but less confusing than having osme work and some not 09:50:03 noamr: when you're in border-shape, SVG styles your border. 09:50:09 ack fantasai 09:50:40 fantasai: i'm assuming border-width interactions still happen for layout purposes? 09:50:50 noamr: for layout it treats the border-style as none 09:51:02 fantasai: that's not great, you lose the border area entirely 09:51:11 noamr: we coudl also treat the border as transparent, can do either way 09:51:18 fantasai: yeah, that's what border-image does, should match 09:51:29 fantasai: wrt fill and stroke, we have a proposal for a long time to use fill/stroke for text 09:51:29 https://www.w3.org/TR/fill-stroke/ 09:51:48 fantasai: if we want to do something completely different for that, we have to decide which use-case gets to use these props 09:51:54 q+ 09:52:19 fantasai: like maybe we need text-fill and text-stroke, etc 09:52:24 ack SebastianZ 09:52:37 SebastianZ: just posted in the issue, i'm not yet convinced that the appraoch with fill/stroke is right 09:52:57 SebastianZ: i still think, for most use-cases, it's easier for authors and maybe impls to reuse the border properties for this 09:53:05 SebastianZ: maybe on top of this we could define how fill and stroke work for it 09:53:28 SebastianZ: see some issues - fill is defined to fill the whole geometry, not just the border 09:53:45 SebastianZ: issue was originally just for single-path border shapes, it seems it also wants to cover double-path border shapes 09:53:59 SebastianZ: but i'm not yet convinced this is the perfect solution 09:54:12 fantasai: i ahve a blocking issue, fill/stroke are inherited, and you really don't want these to inherit 09:54:16 noamr: hm okay 09:54:18 s/ahve/have/ 09:54:32 noamr: about the second point, there's no solution in isolation from thinking about how the borders are rendered 09:54:43 noamr: we originally thought about single border but the solution needs to think about the whole thing 09:55:17 TabAtkins: I think the inheritance just means we ahve to go the other way - introduce border-stroke and border-fill 09:55:37 noamr: I think it's cleaer border-style doesn't work. if we use border-stroke/fill, we can default them to the border-color or something. 09:55:59 noamr: smfr suggested using the four border triangles and clip their colors. complicated tho, the shape can go outside the border box 09:56:08 fantasai: i was thinking about that too. seems a straightforward way, but... 09:56:30 fantasai: for two-sided thing could go further. we draw the border then clip it to the shape. 09:56:44 TabAtkins: elaborate? don't understand 09:56:46 q? 09:56:55 fantasai: you have a solid border, there's angles at the corner where the color changes 09:57:13 fantasai: smfr proposed extending those lines until they intersect, this divides the plane into four colored segments 09:57:24 fantasai: then you clip that plane by the border shape 09:57:36 fantasai: in theory you could do the same with dashing 09:57:51 fantasai: where they extend infinitely in both directions. but could be weird 09:57:58 ack ChrisL 09:58:02 ChrisL: 3 points 09:58:14 ChrisL: is this meant to be a generalization that still applies to svg? so svg would use it? 09:58:31 fantasai: stroke/fill in svg are not affected 09:58:44 fantasai: i was just saying that becuase fill/stroke are inherited (from svg), we can't use those props for borders 09:59:27 ChrisL: second, if we apply this to text, can we define that th estroke goes behidn the fill? that's what you always want. 09:59:37 TabAtkins: separate issue, but yeah probably 09:59:53 re stroke behind fill, don't we have a property for this? 10:00:00 ChrisL: third, this reminds me of a concept we tried to do in svg where there's a boudning box, but sometimes you want stroke boudning box, etc 10:00:20 ChrisL: sounds like that's what we're needing here. stroking can make the element larger, may or may not care about it 10:00:39 (Yes, there is, `paint-order`: https://developer.mozilla.org/en-US/docs/Web/SVG/Reference/Attribute/paint-order Supported everywhere but WebKit) 10:00:41 ChrisL: fourth, mention of double borders reminded me, a11y wanted double borders, we introduced stripes(). wonder how this fits in? 10:00:48 q+ 10:00:57 q- 10:01:19 zakim, close queue 10:01:19 ok, astearns, the speaker queue is closed 10:01:23 fantasai: stripes() goes perpendiular from the border. could say the inner border edge is where you draw .... the outer border edge draws clipped 10:01:29 fantasai: that'll get you striped borders 10:01:37 fantasai: if you do a single path, so it's just stroked, you'll do something different 10:01:51 astearns: at time, can we resolve taht border-shape turns off border-size/etc? 10:01:59 fantasai: it should turn off the painting of the border 10:02:08 noamr: like the border is forced transparent 10:02:15 fantasai: yeah repalces the painting of the border, not the layout 10:02:29 noamr: yes. and can resolve on border-stroke/fill being separate from SVg stroke/fill 10:03:09 noamr: so first reoslution, if border-shape is not none, the normal border doesn't paint (but is still laid out) 10:03:51 SebastianZ: I'd prefer to talk about this in the issue. there was a comment yesterday about the comments to be discussed. 10:04:34 astearns: we'll take this all back to the issue. sounds like there's some details to work out, in future discussion we can discuss bits of it and resolve in different issues. adding new props, like border-fill/stroke, etc 10:04:50 fantasai: i have some comments. if we can reuse border width/color somehow, would be nice for authors 10:04:59 +1 on fantasai 10:05:00 noamr: sure. just haven't managed to do it so far 10:05:06 topic: end 10:05:12
10:05:22 noamr, even if we color-mix all 4 colors together and use the result, it's better than not using it :) 10:07:02 fantasai: or use progress along perimeter :D 11:00:03 alisonmaher has joined #css 11:08:13 noamr has joined #css 11:14:55 andruud has joined #css 11:18:26 ydaniv has joined #css 11:21:04 kizu has joined #css 11:22:14 kbabbitt has joined #css 11:23:39 lea, that definitely won't work for a number of reasonably common things, e.g. 4 straight sides and a squiggly one 11:23:59 github-bot, topic https://github.com/w3c/csswg-drafts/issues/12593 11:24:00 Topic: [css-multicol-2] Should multicol wrapping happen in paged media and nested multicols? 11:24:00 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12593. 11:24:30 rachelandrew: when i proposed block-direction:overflow, i'd only ever thought about continuous contexts (web), not paged media 11:24:48 rachelandrew: as i discussed with morten, he wondered if that's what we wanted. also brought up complexity around nested multicol 11:24:53 zakim, open queue 11:24:53 ok, astearns, the speaker queue is open 11:25:02 q+ fantasai 11:25:04 rachelandrew: i don't see any particular reason to do this in paged media. lots of complexity when you already have a fixed-size thing 11:25:17 diekus has joined #css 11:25:21 rachelandrew: if it's only for continuous context, then, we could also say it doesn't happen in a nested multicol context. morten agree with this 11:25:39 rachelandrew: i've never seen an example of nested multi-row multicol in the wild 11:25:42 q+ 11:25:45 rachelandrew: so that's my proposal 11:25:45 ack fantasai 11:25:50 fantasai: I disagree with doing this. 11:26:00 fantasai: I think we shoudln't transform the layout so substantially when printing 11:26:16 fantasai: also sometimes people use nested multicol to simulat epagination 11:26:39 fantasai: that said, fragmenting these rows doesn't make sense. we def shouldn't do that 11:26:47 fantasai: i think the right thing is to say that... 11:26:52 fantasai: ahven't thought this thru yet 11:27:02 fantasai: we dont' want to break inside a column row, just between 11:27:18 fantasai: so q is how tall are the columns - do we shorten them near the bottom of the page, or push them to the next page? 11:27:21 rachelandrew: that's the next issue 11:27:50 fantasai: so if block-direction wrapping does happen in nested fragmentation, you just never fragment a row of columns 11:27:59 +1 11:28:16 rachelandrew: that does simplify things a bit. we'll have to decide what to do with th eleftover space, i think there's an issue for that 11:28:18 ack astearns 11:28:28 astearns: we did consider this when we were going thru Regions 11:28:44 astearns: so there are bit in Regions about nested fragmentation contexts, and in the Fragmentation module about nested flows 11:28:58 astearns: don't recall our use-cses. but there's something there to build on. 11:29:22 astearns: but generally i agree with elika, there are layouts with reason to have multiple rows to be displayed on each page. 11:29:33 astearns: not working when nested will break some people's sites 11:29:50 rachelandrew: okay, that's about it for this topic then 11:29:59 astearns: should we take a resolution that column-height does apply in paged media? 11:30:03 rachelandrew: in nested contexts in general 11:30:16 astearns: so proposed resolution is that column-height does apply in nested contexts 11:30:18 astearns: objections? 11:30:26 RESOLVED: column-height does apply in nested contexts 11:30:34 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11977 11:30:34 Topic: [css-multicol-2] `column-height` and nested fragmentation 11:30:34 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11977. 11:30:46 moonira has joined #css 11:31:08 rachelandrew: so this is what we just discussed, what happened if we have things broken into rows... 11:31:15 rachelandrew: the issue is what if the row is taller? 11:31:29 astearns: i think we can define that a column row is monolithic in a nested fragmentation context 11:31:48 fantasai: right now, if you don't set column-height, the multicol will generate multiple rows, one per page 11:31:53 https://github.com/w3c/csswg-drafts/issues/11977#issuecomment-3135646117 11:32:07 romain has joined #css 11:32:46 fantasai: if we set column-height, that row is fragmented into two rows that are shorter. so when you generate a row, you take the maximum of ... 11:32:58 fantasai: the column-height is never taller than the remaining space on the page, we have to adhere to this 11:33:03 fantasai: within that constraint we ahve several options 11:33:26 fantasai: when you get to the bottom of the page and half a column height is remaining, you can decide that since column-height was set, i always want a full column-height, this row gets pushed to the next page 11:33:37 fantasai: another option is to clamp the column height to the remaining space on the page 11:33:45 fantasai: and we start a new one on the next page 11:33:51 astearns: not a fan of that one 11:34:10 fantasai: another is to split the row into two rows, the first takes up reamining space on th epage, the second takes the remaining space on the next page 11:34:11 also not a fan 11:34:21 fantasai: i think these are all somewhat reasonable 11:34:27 q+ 11:34:28 fantasai: not sure what i'd want as an author 11:34:31 q+ 11:34:32 (i agree with alan) 11:34:33 q+ 11:34:42 q+ 11:34:46 fantasai: possibly if it's close to filling the page, expand to fill the page. 11:34:54 fantasai: and if it's slightly too tall, shorten it a little bit to fit 11:35:24 fantasai: interesting thing about multicol is it takes the columns, you ask for 200px and you have 500px of space, we'll give you 250px columns, because that's what fits and looks good 11:35:38 fantasai: if we take that to the other axis, we can potentially tweak things so it looks reasonable 11:35:45 fantasai: but how do you make the decision? 11:35:47 ack alisonmaher 11:36:07 alisonmaher: I don't like the idea of clamping, might not have neough space to actually put anything in there, leaving an empty row on the page 11:36:17 alisonmaher: out of the otpions, i prefer moving it ot th enext page, treating as monolithic 11:36:34 ack florian 11:36:37 fantasai: i think it should at least get clamped by the page's full height 11:36:38 alisonmaher: yeah 11:37:13 florian: i think it depends on how you end up in this situation. you're designing for print, set up two rows, and you make it slightly too large. or designing for screen, it's doing something weird for print totally by accident. 11:37:45 florian: going by elika's point aobut column widths, maybe we can combine - for the one that moves to the next page, it lays out as normal, but the one that reamins does grow to fill the space 11:37:57 ack astearns 11:38:05 fantasai: i think varying growsh could be uncomfortable 11:38:25 astearns: i think it would be ?? to take any part of the column-width determining algo and apply them to these rows 11:38:30 if you have a row that 90% fits, pushing it to the next page and then extending the previous would be uncomfortable 11:38:37 q+ 11:38:39 astearns: authors have the ability to give a min width, max width, or any particular width 11:38:53 astearns: we should just use those to figure out what to do 11:39:00 astearns: if there's a definite or min height, and it doesn't fit, move on 11:39:03 q- 11:39:07 astearns: if there's a min height and it does fit, it stays there 11:39:21 astearns: then afterwards you can say what do do with the reamining one 11:39:28 fantasai: we don't have controls for those sizes 11:39:33 astearns: don't we have min-height? 11:39:43 fantasai: yeah, but those apply to the column container, not the column 11:40:08 fantasai: if you put max-height on a multicol container, it can contain multiple rows but they can overflow 11:40:28 rachelandrew: we're just talking about column-height right now 11:40:36 fantasai: yeah, but ther'es no min/max controls for that right now 11:40:47 q+ 11:40:53 ack rachelandrew 11:40:53 astearns: ah, k. I think we should just let things push to the next page if they overflow, then. 11:41:18 rachelandrew: i think i also agree with what florian said. the use-case that's most common for uncontrolled is someone pritning a webpage that was designed for the web 11:41:35 rachelandrew: if they're designing for print, they can just adjust it, they'll seee it before 11:41:50 rachelandrew: so treating it as monolithic is i think what's expected, from an author POV 11:42:05 florian: kinda agree, but maybe pushing back. 11:42:14 florian: you said treat it as monolithic and push it 11:42:31 florian: but for the thing left on the previous page, it might be useful to stretch to fill the page, maybe optional 11:42:39 ack florian 11:42:53 florian: maybe the alignment properties control it 11:42:56 florian: stretch vs normal 11:43:03 I think alignment is another issue :) 11:43:07 florian: just feels like something we shoudl bea ble to choose between 11:43:07 ack fantasai 11:43:18 fantasai: i don't think alignment is the right control for this. 11:43:26 andreubotella has joined #css 11:43:36 fantasai: other intresting questions - at what point is it close enough that you want to tweak the height? 11:43:52 s/be ??/be a mistake/ 11:43:58 fantasai: in terms of distorting the page, hard to tell what'll distort it less. leaving a big gap can also be an unexpected answer. 11:44:14 fantasai: if you have a table that 90% fits, could be more disruptive to move it vs just shrinking it by 10% 11:44:20 fantasai: so going back to use-cases is important. 11:44:58 florian: typically, either you multicol is a little too short or tall for you page, but it's usually not a mix of things 11:45:15 florian: if it's just a little short, using alignment is normal, centered vs stretch vs bottom, etc 11:45:21 q+ 11:45:31 fantasai: if it's a litle too tall... if you aim for 3 and get just 2, that could be okay 11:45:41 fantasai: it's not if there are other things on the page 11:46:01 fantasai: like if your columns are all 33% tall, but one page has a bit of header... 11:46:06 rachelandrew: i think that coudl be controllable 11:46:26 florian: if one row doesn't fit, shorten it, yeah. but if there are multiple and the last doesn't fit, do you really want to shorten it? I think usually no 11:46:48 fantasai: so i think trying to make it look like it fits rather than having weird gaps is better 11:46:49 q+ 11:47:13 TabAtkins: note that column-width only stretches to get wider, it never shrinks 11:47:18 fantasai: true, that's reasonable 11:47:32 astearns: i think the default of push to the next page and getting a gap is reasonable for now 11:48:00 astearns: if there's scenarios for handling a multiple of column-height not being an exact match for the container height, we should offer more controls rather than trying to intuit the author intent 11:48:05 rachelandrew: yeah, i think that's a future issue 11:48:29 astearns: where stretching can go wrong is if the columns are balanced and don't quite fill the page, stretching to fill the page can break teh balancing 11:48:39 +1 11:48:44 astearns: so i think we should start simple, and if there's a use-case for stretching to match the height, we provide an author control 11:49:05 florian: i think that's okay. but if one single row doens't fit, that can get squished 11:49:10 ack alisonmaher 11:49:14 ack astearns 11:49:16 fantasai: we already have rules for paginating multicol, it shortens the columns 11:49:22 alisonmaher: i agree this'll be an uncommon scenario 11:49:34 alisonmaher: if you were gonna stretch one of the columns to fill space, would we have to re-layout? 11:49:52 alisonmaher: if it's shorter, you'll end u pwith less content in th erow than if you hadn't printed? 11:49:57 alisonmaher: that's a bit weird 11:50:33 fantasai: we already do this. if you don't set column-height, and it ends up being 14" tall, and you paginate onto letter paper, we create columns on the first page, fill them, then put more columns on the second page for the reamining content 11:50:48 fantasai: so we don't cut it and shove to the next page, we fragment multicol to create more columns 11:51:32 q? 11:51:33 alisonmaher: with nested multicol today, you could set the constraight ahead of time, but here we're doing backwards because you don't know ahead of time. if there are multiple, do they stretch evenly across...? weird edge cases 11:51:55 fantasai: that's why i think shortening is better in general, you can tell that ahead of time 11:52:02 alisonmaher: then what if it doesn't fit? 11:52:03 q+ 11:52:11 fantasai: if you cna't fit anything, then you treat it like monolithic. 11:52:42 fantasai: it would be nice, i think, if we had a min property so you could ensure we get more than one line of content 11:53:05 fantasai: but i think with that in mind, shrinking the column-height to the last column does fit is consistent with how we paginate multicol in general 11:53:19 fantasai: pretend the c olumn-height is infinite by default, and we're letting you shorten it 11:53:35 alisonmaher: so in the next outer fragmentainer, do you subtract it from the next? 11:53:41 alisonmaher: that would be inconsistent... 11:53:45 ack florian 11:53:46 fantasai: not as much of an opinion there 11:53:52 florian: my sense if we might want a hybrid 11:54:07 florian: when you ahve set columnn-height, if 0 rows fit, you shrink that row (as we do today) 11:54:37 florian: but if several rows do fit, and the last doesn't, i'd do what alan said - treat as monolithic and move to the next page 11:54:44 florian: better than having two large column rows and one tiny one 11:54:49 florian: which probably isn't waht you want 11:54:57 +1 florian. Current multicol pagination rules should only apply to a not-even-one row fits scenario 11:54:57 florian: maybe having controls for that later 11:55:13 +1 11:55:35 TabAtkins: agreed 11:56:07 fantasai: i propose we put this into the issue as a proposal and see what Morten thinks 11:56:15 fantasai: can revisit if he has more ideas, otherwise agree on it 11:57:04 fantasai: would also be good to ping Murakami-san to see if they have ideas 11:57:15 fantasai: so put it in as proposal rarther than resolution yet, to apply less pressure 11:57:19 rachelandrew: sounds good 11:57:40 florian: and make it clear that we're not pursuing it yet, but might go for controls about stretching/aligning into the empty space later 11:57:47 fantasai: might also be good to ask the princexml folks 11:58:16 rachelandrew: I'll put the comment into the issue 11:58:29 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11976 11:58:29 Topic: [css-multicol-2] `column-wrap`, `column-height` and column balancing 11:58:29 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11976. 11:58:52 rachelandrew: lots of discussion, some was morten and me confusing eachother 11:59:00 rachelandrew: have a final comment that wraps up the questions we wanted 11:59:06 rachelandrew: resolution we need is around spanners 11:59:19 rachelandrew: want to make it clear that spanners don't wrap with columns 11:59:24 rachelandrew: don't think anyone would want that 11:59:45 rachelandrew: so want to make it clear that if your columns wrap, a spanner only spans across the inline direction, not "all" columns 11:59:58 rachelandrew: so want to amend column-span:all to say it only spans across the columns of the current row 12:00:16 +1 12:00:30 TabAtkins: did we... oh, we dropped column-span: a while back 12:00:37 fantasai: yes, we should resolve on this 12:00:53 astearns: objections? 12:01:03 RESOLVED: column-span:all only spans across columns of the current row 12:01:25 rachelandrew: another spanner issue 12:01:34 rachelandrew: if the spanner is too tall (in the block direction) for the column-height 12:01:40 rachelandrew: like column-height:100px, spanner is 120px tall 12:01:43 rachelandrew: what to do? 12:01:52 rachelandrew: we could avoid spanning, that's not ideal because we've already done layout 12:02:15 rachelandrew: we could push it to the next row, which works if there's already some content there and the spanner just doesnt' fit in the leftover 12:02:23 rachelandrew: or we could stretch the height 12:02:46 rachelandrew: concern is if people create a full page of columns, and then people have a "page" taller than the viewport because the spanner is too big 12:02:55 ack fantasai 12:03:18 fantasai: two ways to think about column-height. one is it's a max column height; a spanner restarts you 12:03:34 fantasai: but i don't think that's what you're suggesting 12:03:46 fantasai: we put in content, we balancee it, we put in the spanner, and then the spanner is too big 12:04:01 fantasai: given the spanner doesn't normally restart the columns, having it not restart the columns when it's too big also makes sense to me 12:04:09 romain has joined #css 12:04:18 fantasai: so if it pushes things down, the next row of content should end at the same place it woul dahve ended without the spanner 12:04:45 https://github.com/w3c/csswg-drafts/issues/11976#issuecomment-2754307956 12:05:07 fantasai: if you look at this diagram, there's rows without spanners, five lines of content 12:05:16 fantasai: suppose we had a one-line spanner after the first three words 12:05:26 fantasai: it would occupy the second line of content in that row 12:05:40 fantasai: but it woudln't shift anything else, it doesn't reflow... 12:05:49 fantasai: the row doesn't restart, it's still 100px tall 12:05:58 fantasai: in this next example the spanner is too big, it overflows 12:06:20 fantasai: this causes the next row of content to start a new row that's 100px tall, but no longer on the "grid" 12:06:27 fantasai: but we alreayd established that spanners don'ta ctually restart the height 12:07:00 fantasai: so consistent with that, we say the rows size and flow as normal, and the spanner just lives in one of those rows 12:07:29 rachelandrew: okay i think i understand that. 12:07:40 TabAtkins: you let it overflow and not affect the geometry 12:07:45 q+ 12:07:51 fantasai: i think this'll happen more with images 12:08:07 fantasai: a big image, but you want to preserve the vertical rhythm 12:08:09 ack alisonmaher 12:08:25 alisonmaher: similar question to last issue - if only part of the row fits below the spanner, do we restart the row in the next one? 12:08:43 alisonmaher: that's inconsistent with multicol today where you continue the columns below the spanner... 12:08:49 fantasai: ah, within the row you act like normal 12:09:11 fantasai: [draws something on the whiteboard] 12:10:10 fantasai: [explains her proposal via the drawing] 12:12:02 TabAtkins: so making sure i understand - if the spanner is taller than the remaining space, it just overflows the row, and the next gap+row starts wher eit would normally have (it's not pushed down), so th enext row overlaps it? 12:12:29 fantasai: the next row's placement isn't pushed down, but the content on the row is - the spanner takes up "content space" into the gap and next row that it intersects. 12:12:35 Basically, the column-height defines where the column rows start and end. The spanner doesn't change that. It just takes up room, potentially across multiple rows, and the following content starts after it ends -- and is broken into the next column row at the same physical location as it would have otherwise. 12:12:53 florian: so the spanner can stomp all over the gaps... 12:12:56 fantasai: yes 12:13:05 florian: and in the previous issue, if you have a page break, then what 12:13:18 fantasai: if the spanner is monolithic it'll move, otherwise you'll fragment it 12:13:51 fantasai: if the spanner is the first thing in the row and it doesn't fit, it pushes to the next 12:13:57 alisonmaher: and if it's already at the top of the page? 12:14:10 fantasai: oh, then you just lay it out and let it happen. we don't shrink things. 12:14:20 fantasai: so blockquotes would fragment, images would slice 12:14:31 rachelandrew: i think "treat as monolithic" is a good default case 12:14:53 astearns: our previous reoslution is that spanners only affect a single row of columns, this breaks that... 12:15:15 florian: it doesn'ta ffect the rows, just the content of the rows 12:15:25 rachelandrew: and it's only in the block direction, it's not extending in the inline direction 12:15:38 astearns: i dont' particularly like this but i dont' have a better idea 12:15:59 but I do think it’s an improvement (from what’s shown in the issue illustration) 12:16:01 noamr has joined #css 12:16:08 fantasai: so to summarize, a spanner which is too big to fit in its own row in the block axis can extend into later rows, pushing content in those later rows but not pushing the rows themselves 12:16:38 fantasai: content after the spanner lays out after the spanner, in a subsequent row (and possibly with less space now, due to the spanner) 12:16:46 astearns: but it doesn't affect the column-row geometry itself 12:16:59 astearns: so proposed resolution is we do all that 12:17:03 flackr has joined #css 12:17:10 present+ 12:17:12 astearns: objections? 12:17:16 RESOLVED: Do that 12:17:43 rachelandrew: next issue, what if there's not enough content for the column-height? 12:17:53 rachelandrew: some options - shrink them, or keep the height, or a mixture 12:18:01 rachelandrew: i think we want option 2, and in the future alignment can do something 12:18:08 +1 12:18:16 rachelandrew: that better supports carousel cases 12:18:28 TabAtkins: strong agree 12:18:51 fantasai: tricky is if you want to bring in alignment props, the natural thing to use is the stretch keyword; option 1 would be start 12:19:12 rachelandrew: feels similar to Grid, things are stretched by default in that direction. think authors would find it natural 12:19:59 astearns: can we resolve on that? 12:20:18 fantasai: i think this is the right option 12:20:44 astearns: proposed resolution is if there's not enough content to fill a column-height, we'll still maintain the column-height and just have empty space 12:20:48 astearns: objections? 12:21:00 RESOLVED: if there's not enough content to fill a column-height, we'll still maintain the column-height and just have empty space 12:21:35 github-bot, take up https://github.com/w3c/csswg-drafts/issues/8721 12:21:36 Topic: [css-overflow-4] Unexpected behavior of `continue: discard` on multicolumn containers with spanners 12:21:36 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8721. 12:22:07 andreubotella: i opened this when i was working on continue:collapse 12:22:16 andreubotella: continue:discard can be applied to block containers, and also multicol 12:22:59 andreubotella: if you have overflow columns, you can have content after those columns; continue:discard is meant to discard the contents of a fragment 12:23:36 andreubotella: for some impls, they could just do the whole layout and discard the fragment, but hope is that in browsers that can do fragmentation during layout (chromium does this, webkit is transitioning to this), you could stop the layout just before the discarded part 12:24:13 andreubotella: if you have a spanner you'll resume the layout, and ther's content from the overflow columns that can affect the layout of things, like counters 12:24:23 q+ 12:24:48 fantasai: so you're saying there's a break after column 3 in the text, then the overflow column... 12:25:17 andreubotella: for continue:discard, it's possible to ipmlement by laying out the whole thing then throwing away the excess, but for line-clamp the hope is that you can actually stop the layout at the clamp point 12:25:25 ack florian 12:25:58 florian: there's a bunch of things you could do, but many dont' make sense. the general idea is continue:discard on an overflow discard the overflow columns... a spanner rooted in those columns gets discarded too 12:26:15 florian: if we let the spanner exist it would create weird content, you'd miss the content between the break point and the spanner 12:26:25 fantasai: right, once you get to the discard point all further content is discarded 12:26:40 andreubotella: i think that's consistent with a multicol in fragmented content and you just discard stuff after the first fragment 12:26:52 alisonmaher: does this mean you'll have to keep laying things out? 12:27:09 andreubotella: i don't think so. the moment you know there are columns that would overflow, you stop layout for them 12:27:31 astearns: so, proposal? 12:27:48 kizu has joined #css 12:27:48 andreubotella: if there are overflow columns in a continue:discard element, any content after the first overflow column is discarded 12:28:22 s/after the/beginning with the/ 12:29:11 RESOLVED: if there are overflow columns in a continue:discard element, any content starting with the the first overflow column is discarded 12:30:08 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10868 12:30:08 Topic: [css-overflow] What counts as "immediately preceding" for `block-ellipsis`? 12:30:08 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10868. 12:30:38 andreubotella: block-ellipsis is a longhand for line-clamp. says it only affects a line box if it's immediately preceding a clamp point 12:30:48 andreubotella: when you clamp by line count, "immediately precedes" is clear 12:30:53 andreubotella: when you clamp by height it's not cleaer 12:31:03 andreubotella: here's two styles for the same html 12:31:06 https://github.com/w3c/csswg-drafts/issues/10868#issuecomment-2991132884 12:31:11 (one clamps by 2, one clamps by 2lh height) 12:31:51 andreubotella: in "2", line 2 is before the clamp point, so it's ellipsized 12:31:59 andreubotella: abspos is after the clamp point, but still shown (per issue) 12:32:21 andreubotella: but in height based, abspos is immediately before the clamp point, line 2 isn't. so it's not ellipsized, per naive spec reading 12:32:33 andreubotella: these two visually clamp at the same point but ellipsize differently. probably not what we want 12:32:43 andreubotella: two options. 12:32:51 andreubotella: first is ignoring abspos for "immediatley precede" 12:32:54 andreubotella: another is not allowing clamp points to be after abspos 12:33:17 andreubotella: currently continue:collapse already restricts clamp point to be a) at start, b) between line boxes, or c) between in-flow sibling boxes 12:33:21 abspos is not the only thing that can invoke this discrepancy, right? Anything that has not height… 12:33:32 andreubotellawe dont' allow clamping at start or end of the box (other than line-clamp container itself) 12:33:55 andreubotella: in this example there's no allowed clamp point before the abspos. but clamping after div shoudl probably ellipsize line 1 12:34:02 https://github.com/w3c/csswg-drafts/issues/10868#issuecomment-3045732790 12:34:12 andreubotella: how to spec this? 12:34:24 andreubotella: my feeling is we might want to do both these options 12:34:55 andreubotella: so if there are abspos between two siblings, clamp point goes before it 12:35:00 q+ 12:35:01 ack fantasai 12:35:02 andreubotella: but also tweaking "immediately preceding" text 12:35:12 fantasai: i think abspos should be ignored for determining ellipsis 12:35:16 fantasai: any out of flow 12:35:32 fantasai: we shoudl be consistent about whther the abspos is included before/after the clamp point 12:35:36 fantasai: seems like including it makes the most sense 12:35:58 andreubotella: yes. i suppose to some extnet it's an editorial question about how best to spec 12:36:10 andreubotella: "immediately before" is also a problem with the ??? 12:36:28 fantasai: so in this exapmle obvs the abspos should go with the element it's in, whereever it's clamped to 12:36:43 fantasai: but if the abpsos is between two siblings, including it if the clamp falls between the siblings makes sense 12:36:53 florian: is it observable whether it's befor eor after the clamp point? 12:36:57 fantasai: for discard, yes 12:37:01 ack florian 12:37:10 florian: do we ahve a variant of the same problem with empty divs? 12:37:34 andreubotella: currently in-flow with zero height count as something that blocks the ellipsis on the preceding line 12:37:42 florian: i don't mind that if they actually ahve content 12:38:04 florian: but if they're empty.... seems unfortunate to block the ellipsis just because an empty div follows it 12:38:19 fantasai: i don't feel too strongly about whether it's before or after those, i just want to consistent across the modes 12:38:32 fantasai: but empty boxes probably shoudl be ignored 12:38:37 fantasai: for ellipsis 12:38:53 fantasai: so clamping and ellipsis might not be exactly the same point. from the clamp point, you walk backwards until you find some content 12:39:35 florian: for the clamp and "immediately before", maybe if you have element boundaries or static position of OOF things, I'd like to skip 12:39:46 florian: empty elements id' like to skip, but an empty with padding/border, i'm less sure 12:39:56 florian: but a thing you'd margin-collapse thru should be ignored 12:39:57 florian: roughly 12:40:27 andreubotella: tying to match that might be pretty complicated 12:40:56 TabAtkins: i think if you ahve an element that can be collapse thru, that's your problem. don't do that 12:41:20 florian: so element boundaries and OOF things don't count for blocking ellipsis. anything else? 12:41:23 andreubotella: i don't think so. 12:41:34 andreubotella: for floats, you treat the whole float as monolithic, i think 12:41:42 florian: floats can be fragmented, but... 12:41:51 florian: a float:left isn't after the line, it's before 12:41:57 florian: a float:right, tho 12:42:41 andreubotella: the spec i drafted for finding the clamp point is... the block size (ignoring hidden elements) isn't larger than the clamp length 12:42:46 andreubotella: in that definition, floats are monolithic. 12:42:50 andreubotella: not sure that's what we want 12:43:08 florian: i think for continue:collapse, this is designed to be simple and usable, not sophisticated and doing fancy things in all cases 12:43:22 florian: so it's not meant to do something smart with floats. just define something simple. smart is for continue:discard 12:44:15 andreubotella: so conclusion is we should open an issue to talk about what to do with floats, open an issue about empty blocks, and for abspos, both abspos and end of an element are ignored for "immediately preceding" 12:44:48 astearns: we want to be consistent with where we clamp and where we place ellipsis 12:46:06 andreubotella: proposed resolution is, for purposes of block-ellipsis "immediately preceding", abspos and end of element are ignored 12:46:16 astearns: objections? 12:46:30 RESOLVED: for purposes of block-ellipsis "immediately preceding", abspos and end of element are ignored 12:47:04 andreubotella: for abspos, whether clamp point is before or after it doesn't matter, no visual difference i think. abspos will be shown regardless 12:47:18 astearns: for floats there might be a difference 12:47:25 andreubotella: for empty elements, it might have a difference 12:47:56 andreubotella: if an empty element has relpos and there's some abspos using it as CB, that would be a case where the clamp point would matter 12:48:10 astearns: okay so for this issue, clamp point doesn't matter. 12:48:18 astearns: you'll have more issues to get to, but we'll break for now 12:48:24 github-bot, end topic 12:48:31 astearns: we'll start with gap issues after the break 12:48:44 astearns: and if possible, return to overflow and border issues 12:48:54 astearns: after break, breakout in the other room for animation-trigger issues 12:48:57 astearns: in #houdini 12:49:16 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12289 12:49:16 Topic: [css-overflow-4] Allow scrollable overflow to be clipped in off-axis 12:49:16 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12289. 12:49:39 flackr: right now if you specify overflow in one axis, the other is forced to hidden (still programatically scrolalble) 12:49:51 flackr: so you can cause accidental off-axis scrolling with JS or a target 12:50:01 flackr: i think we should allow making one axis clipped, so it's always at the origin 12:50:08 flackr: but otherwise acts like a scroll contianer normally 12:50:15 flackr: woudl prevent accidental scrolling 12:50:18 fantasai: makes sense 12:50:38 TabAtkins: just say that "clip" can be used with the scrollable values? 12:50:48 fantasai: would no longer compute to hidden, the element remains a scroll container 12:50:50 fantasai: makes sense to me 12:51:04 astearns: so not changing current bheavior, just adding new? 12:51:26 flackr: technically it's a change, if people are using scroll+clip today (it computes to hidden). but should be rare, i think it's safe 12:51:58 Proposed resolution: Allow overflow: clip in other axis of a scrollable container. It is still a scroll container but prevents scrolling away from origin in that axis. 12:52:02 q+ 12:52:09 ack emilio 12:52:13 emilio: conceptually i think it seems okay 12:52:32 bkardell has joined #css 12:52:33 emilio: but this needs a bunch of spec changes to om-view, currently has a binary view of scroll container 12:52:41 flackr: it is still a scroll container 12:52:51 emilio: yeah, but the scrolling APIs currnetly will still do something 12:52:59 flackr: i'll have a look thru cssom-view and see what needs changing 12:53:27 emilio: k. i htink we need to change the style adjustment stuff, and change all the things that can scroll. 12:53:47 present+ 12:53:49 q+ 12:53:57 TabAtkins: i think we'd change it so say that scroll containers have 1 or 2 scrollable axises, and we'd redefine things to depend on scrollable axises 12:53:57 ack oriol 12:54:05 oriol: there's a bunch of things taht dpened on scroll container or not 12:54:27 oriol: if we're letting a scroll container only be one axis, maybe want to review those things, some might want to depend on it being scrollable in that axis 12:54:32 oriol: automatic min sizes come to mind 12:54:47 oriol: not opposed to this change, but there might be some mor eimplications to consider 12:54:47 TabAtkins: that makes sense to me 12:54:52 astearns: okay, still hearing no opposition. objections? 12:55:14 I think for almost all cases, we will consider to be a scroll container in both axes 12:55:20 RESOLVED: Allow overflow: clip in other axis of a scrollable container. It is still a scroll container but prevents scrolling away from origin in that axis. Figure out what needs to change to respond to an axis not being scrollable. 12:55:27 github-bot, end topic 12:58:50 so...
? 12:59:35 kizu has joined #css 13:02:05 bkardell has joined #css 13:02:05 matthieud has joined #css 13:02:05 oriol has joined #css 13:02:05 lea has joined #css 13:02:05 fantasai has joined #css 13:02:05 mike has joined #css 13:02:05 geheimnis` has joined #css 13:02:05 projector has joined #css 13:02:05 sylvaing has joined #css 13:02:05 shans has joined #css 13:02:05 dbaron[m] has joined #css 13:02:05 plinss has joined #css 13:02:05 leaverou has joined #css 13:02:05 dustinm has joined #css 13:02:05 hober has joined #css 13:02:05 zrhoffman has joined #css 13:02:05 tobie_ has joined #css 13:02:05 Rossen has joined #css 13:02:05 hayato has joined #css 13:02:05 jyasskin has joined #css 13:02:05 CSSWG_LogBot has joined #css 13:02:05 cwilso has joined #css 13:02:05 cbiesinger has joined #css 13:02:05 smaug has joined #css 13:02:05 jeroen has joined #css 13:02:05 hdv has joined #css 13:02:05 rachelandrew has joined #css 13:02:05 chrishtr has joined #css 13:02:05 futhark has joined #css 13:02:05 vmpstr has joined #css 13:02:05 faceless has joined #css 13:02:05 JakeA has joined #css 13:02:05 tink has joined #css 13:02:05 rbyers has joined #css 13:02:05 astearns has joined #css 13:02:05 bramus has joined #css 13:02:05 ntim has joined #css 13:02:05 slightlyoff has joined #css 13:02:05 gregwhitworth has joined #css 13:02:05 timeless has joined #css 13:02:05 iank_ has joined #css 13:02:05 alice has joined #css 13:02:05 weinig has joined #css 13:02:05 emilio has joined #css 13:02:05 drott has joined #css 13:02:05 devsnek has joined #css 13:02:05 TabAtkins has joined #css 13:02:05 dandclark has joined #css 13:02:05 miriam has joined #css 13:02:05 koji has joined #css 13:02:34 bkardell: yes, for 3 more minutes 13:03:18 alisonmaher has joined #css 13:06:50 JoshT has joined #css 13:08:37 fantasai has joined #css 13:09:21 Topic: Gap Decorations 13:10:20 Subtopic: [css-gaps-1] Gap decorations next to empty grid areas 13:10:37 scribe+ 13:10:39 SebastianZ has joined #css 13:11:09 present+ 13:11:09 kbabbitt: #1 feedback we got from authors so far is wanting more control over where gaps appear 13:11:15 kbabbitt: Layouts they wanted with unwanted decorations 13:11:26 kbabbitt: especially around empty areas 13:11:44 kbabbitt: Another example, they want the separators in second two rows, but no first 13:11:51 kbabbitt: Discussed different approaches 13:11:57 kbabbitt: one was to have a property similar to empty-cells 13:12:11 kbabbitt: another is concept of gap-decoration-areas, which was in original explainer but pushed out of Level 1 13:12:20 kbabbitt: in this case, you define an area based on grid syntax 13:12:26 kbabbitt: and override set of decorations for that area 13:12:41 kbabbitt: name the ara, refer to it in the gap decoration properties 13:12:50 kbabbitt: could define things for everything but the top, for example 13:13:02 q+ 13:13:14 kbabbitt: in both of these two cases, the authors did express preference for this over empty areas, but third example 13:13:23 kbabbitt: here is a responsive layout, where they have an outer grid and each headline article is a subgrid 13:13:32 kbabbitt: auto-fill grid, so as you size the window, columns reflow 13:13:49 kbabbitt: and you can't really identify the area 13:14:02 kbabbitt: so because of that, I'd like to solve with some sort of property to control decorations in empty areas 13:14:21 kbabbitt: some discussions about this, and I think the shape of it is a 5-state value to control where you want it 13:14:28 kbabbitt: current behavior is painting all the gaps 13:14:36 kbabbitt: might want to only paint if one side 13:14:47 kbabbitt: or only in left side or only one side or only both sides 13:14:55 kbabbitt: a few things to consider, one is what to name is 13:15:10 kbabbitt: another is do we want to do this 13:15:28 astearns: Would like to object to 1st solution where you define areas where rules apply 13:15:50 astearns: My concerns were, I like the fact that the syntax looks like grid-template-areas and has similar semantics 13:15:56 andreubotella has joined #css 13:16:00 astearns: but I think it would get easily out of sync with template definition 13:16:07 astearns: and out of sync with what parts of the grid the content is actually flowing 13:16:23 astearns: You set up your rule areas expecting your content is in one place, but then change it, and forget to fix it up 13:16:29 astearns: so prefer dealing with empty areas directly 13:16:36 ack astearns 13:16:40 ack fantasai 13:16:52 fantasai: same concern as astearns for the areas version, seemed a bit fragile 13:17:07 ... A property on the items themselves sounds like a good idea 13:17:20 ... if the default is draw all the lines and you have a bunch of empty areas 13:17:37 ... you can't turn those off easily 13:17:42 ... I think you'd want a grid level thing 13:17:51 ... and then a grid item thing that allows you to override it 13:18:01 +1 to fantasai 13:18:05 ... so certain elements you want rules around 13:18:14 oSamDavis has joined #css 13:18:30 ... instead of associating to a position on the grid 13:18:37 ... you associate it on the item 13:18:43 q+ 13:19:05 ... so the item decides based on the content around it 13:19:08 q+ 13:19:12 wondering whether someone will implement a CSS-only game of life with this new feature 13:19:37 ... and whether you want that unilaterally or only if the other item enables it 13:19:52 ... I think you still want a default behavior on the grid 13:20:15 kbabbitt: for the first example, I guess you'd turn it off on the grid and then turn it on for some items 13:20:24 fantasai: correct 13:20:31 q+ 13:20:34 ... and sometimes you want to make it visible in all adjacent places, or only if there's an item around 13:20:41 q+ 13:20:47 ... and you want some items to be able to ignore and so on 13:20:56 kbabbitt: so two props, one for the global state 13:21:01 ... is that an on-off on the grid? 13:21:11 fantasai: I think you need at most 3 states 13:21:40 astearns: let's not worry too much about the details, let's go through the queue 13:21:40 ack alisonmaher 13:21:49 alisonmaher: what if there's multiple items with conflicting instructions? 13:22:12 q+ 13:22:13 fantasai: I think we want items to turn things on and whether their presence turns things on, but not suppressing lines 13:22:22 ack emilio 13:22:30 fantasai: So an item could say "I want a line" or "I want a line if someone else wants a line" 13:22:55 fantasai: But can't turn it off 13:23:07 q+ turning on decs for specific cells 13:23:27 ack turning 13:23:27 turning, you wanted to comment on decs for specific cells 13:23:27 ack on 13:23:28 ack the 13:23:31 ack on 13:23:33 emilio: was going to raise the same kind of concern 13:23:34 ack the 13:23:48 ... would like to not allow for weird conflicts 13:23:54 q+ JoshT 13:24:00 kbabbitt: I think that model makes sense to me 13:24:12 ack oriol 13:24:30 oriol: My question was about the 'whether there's content or not' 13:24:42 ... do we care about absposes? Those are not technically a grid item 13:24:50 ack SebastianZ 13:24:56 fantasai: those don't count, if you are doing that you need to turn the lines unilaterally 13:25:21 astearns: re. fantasai suggestion, there's no way to turn on things for empty areas 13:25:31 ... because you can't target 13:25:55 fantasai: seems unlikely you'd want something like that where you want specific empty areas 13:26:10 s/astearns:/SebastianZ:/ 13:26:11 s/empty areas/empty areas to have grid lines, but the rest of the grid to not/ 13:26:34 fantasai: if you want to turn them on on a particular area you can put an empty div there or a subgrid 13:26:40 ack JoshT 13:26:58 JoshT: Coming back to the question around being more precise about where the decorations go 13:27:35 ... was talking to kevin about a potential use case we might have where you might have a grid, you don't want to show the lines above a cell that doesn't have an image on it? 13:27:50 ... I wonder if we should still consider that kind of use case 13:27:54 fantasai: can you review that example? 13:28:17 JoshT: let me share my screen 13:28:24 ... [shows bbc.cok.uk] 13:28:25 noamr has joined #css 13:28:35 ... we use border lines for dividers for things that don't have an image 13:29:11 fantasai: is the layout that you have there such that you only have that row or they overlap? 13:29:21 JoshT: they overlap and in this case it might be better to use border 13:29:30 ... but there might be similar cases 13:29:46 kbabbitt: is that something that you could do targetting elements that don't have an image? 13:29:50 JoshT: I think so 13:30:05 kbabbitt: then in this case you'd target non-image cards 13:30:14 ... and turn the decorations on there 13:30:39 q+ 13:30:48 astearns: but if you can target them why would we need this extra proposal? 13:31:02 astearns: I think what there's in the spec now allows to do this 13:31:13 kbabbitt: no it's not, but with fantasai's proposal we would be able to do this 13:31:32 astearns: I wanted to ask whether we were discussing this because this needs to be part of the first version of gap-decorations 13:31:47 ... you're pulling it back in after pushing it off 13:31:58 kbabbitt: What I pushed off was the grid areas version 13:32:08 ... so this is more about solving some of these cases 13:32:12 ack astearns 13:32:19 ... the empty areas here I'd like to explore more 13:32:26 ... because it's part of the feedback that we're receiving 13:32:29 rule-visibility-items: always | adjacent | between 13:32:29 rule-visibility-self: auto | always | between 13:32:43 s/adjacent/around/ 13:32:50 q? 13:32:55 ack SebastianZ 13:33:04 SebastianZ: maybe JoshT could share screen again? 13:33:16 rule-visibility-items: all | around | between 13:33:17 rule-visibility-self: auto | around | between 13:33:25 ... I think the bbc use case is not completely covered by this thing 13:33:36 ... you have an image aligned with the top line 13:33:44 ... I guess you'd use border line 13:34:10 emilio: fact that it's aligned with top of border is an artifact of using border 13:34:10 ... with gap decorations you wouldn't be able to achieve exactly that 13:34:20 s/.../sebastianz/ 13:34:40 fantasai: if you didn't have that alignment it'd be weird, that's why border would be the right tool here 13:34:49 ... my proposal is above, `rule-visibility-items` 13:34:59 ... `all` would be all borders 13:35:12 ... `around` is for all the cells around each items 13:35:13 q+ 13:35:23 ... `between` would be only if there's an adjacent item 13:35:46 ... `rule-visibility-self` `auto` does whatever the grid container says 13:35:54 ... the other values behave as expected 13:36:09 kbabbitt: I like that, also like how they're named around the grid alignment properties 13:36:16 q+ 13:36:34 fantasai: yeah and if we need extra control like per side you can split `rule-visibility-self` per side 13:37:02 q+ 13:37:07 SebastianZ: So you'd have `column/row-visibility-items` and `row-*`? 13:37:18 fantasai: first q is whether we need that control 13:37:24 ... but it'd be an easy extension 13:37:29 ack emilio 13:37:47 emilio: sounds good, but the items naming makes it sound like it will only put rules around the items, maybe use 'cells' or something 13:37:55 emilio: but otherwise seems like a reasonable start, and easy to extend 13:38:22 SebastianZ: but if you have a spanning item, you won't have it between those cells 13:38:33 ack oriol 13:38:39 fantasai: I think consistency with the alignment properties is probably more important 13:39:21 ack oSamDavis 13:39:53 oriol: What if there was one item and then a spanner that spanned over it, would there be a rule underneath the spanner? 13:39:59 fantasai: Not unless there would be one otherwise, I think. 13:40:07 oSamDavis: Would it affect layout? 13:40:13 kbabbitt: No, all it does is turn decorations on/off in certain places 13:40:35 astearns: Sounds like you have an outline of how to design this feature, so maybe take it and run with it and bring it back to us :) 13:40:54 Subtopic: [css-gaps-1] Asymmetric start and end offsets 13:41:26 kbabbitt: another piece of author feedback that we got. The property would control how far into or away from an intersection the gap decoration extends 13:41:40 kbabbitt: They might want to meet exactly, or overshoot, or undershoot, the intersection 13:42:14 kbabbitt: For flexbox, there was an author who wanted different offsets on different sides of it 13:42:39 kbabbitt: Suggestion was to have the outset value control start vs end independently 13:42:52 kbabbitt: e.g. taking two values, or make it a shorthand 13:43:08 q+ 13:43:15 ack SebastianZ 13:43:18 kbabbitt: another somewhat related issue is shorthanding the offset and the break, so keep that in mind 13:43:43 SebastianZ: Not up to date on how this is currently defined, but it take into account the expansion outside the grid, or also within the container, btween the items? 13:44:04 q+ 13:44:24 kbabbitt: Can specify outset either ith pixel value or percentage value, where percentage is relative to crossing gap 13:44:37 kbabbitt: you can extend outside the container if you want 13:44:42 kbabbitt: can keep it flush 13:45:13 SebastianZ: separate question wrt outside of container and internal 13:45:20 SebastianZ: but I like being able to control both outsets 13:45:23 ack JoshT 13:45:48 JoshT: The example with the landscapes is interesting, especially if we assume it's a grid of the entire page layout 13:46:09 JoshT: I don't think this proposal gives us a way to give a fixed width for the decorator 13:46:26 astearns: but did have a thought, might want 5em 13:46:35 alisonmaher: I don't think you can, because 100% is relative to gap 13:46:45 ack fantasai 13:47:08 fantasai: this example with a short line looks like a border in the preceding paragraph, but with a shortened border 13:47:15 thought that you’d be able to get a particular length with calc, but alisonmaher is correct that it would be centered 13:47:16 ... there's been various proposals in borders-4 13:47:27 ... this particular pattern is common 13:47:33 ... I think that's a separate feature from gaps 13:47:43 ... we should also do it, there's a spec and we should probably revisit it 13:47:54 ... so this seems tangential 13:48:02 ... just having the outset property is enough 13:48:13 ... each side independently I'd expect us to go in that direction at some point 13:48:25 ... so that it seems fine to do whenever there's sufficient demand 13:48:39 ... but the point about making sure we design so that the syntax can be accommodated makes sense 13:48:54 ... we should expand rule-offset to have more than one offset 13:49:06 kbabbitt: do you think this is one prop with 1/2 values or different props? 13:49:21 fantasai: if they don't need to cascade independently I don't think we should split it into longhands 13:50:03 fantasai: If an author would want to set one value in one style rule and another value in another style rule and have them combine, then you need longhands. otherwise not. 13:50:27 SebastianZ: Could be use cases wrt animating the outset-start individually from that 13:50:31 fantasai: yeah, you can do that 13:51:17 SebastianZ: i can imagine wanting to extend the lines outside the container, but not within 13:51:39 astearns: We can start with a single rule-offset with two lenghts, and split out to longahnds later 13:51:58 fantasai: important question -- here the proposal is start vs end 13:52:11 fantasai: what Sebastian is suggesting is interior vs exterior 13:52:23 kbabbitt: another issue on that 13:52:46 fantasai: the syntax might interact then 13:53:11 astearns: ok, let's go to that issue then 13:53:14 Subtopic: [css-gaps] Gap decoration outsets at the edges 13:53:53 kbabbitt: This is exactly the case, where an author might want to control the gap decorations differently at edges of container vs interior 13:54:01 kbabbitt: there was suggestion to set only interior using a switch 13:54:09 kbabbitt: but separate setters might be way to handle it 13:54:34 kbabbitt: another idea was being able to specify list of values, similar to alternating colors 13:54:45 kbabbitt: question is how do we want to handle this case? 13:55:18 fantasai: most common case when you're going to want outsets you're going to have interior outsets different from the outer ones 13:55:25 ... inner ones 50%, outers 0 13:55:32 ... I think that's common 13:56:02 kbabbitt: for the interior intersection the basis the width of the gap in the cross direction 13:56:03 q+ 13:56:11 ... for the exterior is 0 13:56:18 fantasai: I think that's not what you want to do 13:56:31 ... percentage basis should be same for both 13:56:52 ... if you want 25% on each side for the interior 13:57:13 ... you want the outer gap to not flush, but be the same amount 13:57:31 ... if you'd use an absolute value you'd get the outset on both interior and exterior 13:57:38 ... if you switch to percentages we shouldn't change that 13:57:49 ... what you want to do is to split it into inside/outside 13:57:57 ... rule-outset-inside/outside 13:58:14 ... that way you can set the outset for just the interior e 13:58:22 alisonmaher: rule-outset-edge? 13:58:29 fantasai: whatever, inner/outer... 13:58:35 ... but I think that'd give you the control you want 13:58:48 alisonmaher: the list approach would work...? 13:58:55 fantasai: no because you need to track the repeat 13:59:04 alisonmaher: if you are autorepeat you could 13:59:16 fantasai: you don't know how many columns you want with auto repeat 13:59:30 ... repeat might be useful for pattern-like thing 13:59:40 ... but for the exterior one you don't know how many columns you have 13:59:49 astearns: we've used positive / neg indices 13:59:52 ... if you want to target ends 13:59:58 ... not sure that's the right design here 14:00:09 kbabbitt: we have auto repeat for widths/colors to fill gaps not specified 14:00:17 ... but I agree in this case is edges vs. interior 14:00:24 ack SebastianZ 14:00:24 ... and we should design it that way 14:00:27 SebastianZ: you lost me a bit 14:00:37 ... but reading the minutes I think we agree on what I had in mind 14:00:46 ... so having different outsets for interior and edges 14:00:52 ... so we can control it differently 14:01:01 ... maybe we could resolve on that? 14:01:09 kbabbitt: yeah wonder if we could resolve on this 14:01:13 fantasai: we need 2 resolutions 14:01:20 ... one that percentages resolve to the same value 14:01:41 RESOLVED: percentages resolve to the same value for edges vs. interior decorations 14:02:08 PROPOSED: rule outset has two longhands, one for interior one for exterior 14:02:39 fantasai: interior one could be split up faster 14:02:55 s/faster/later 14:03:05 emilio: exterior as well theoretically right? 14:03:11 SebastianZ: do we want to resolve on names? 14:03:17 interior vs exterior is much more likely to be distinguished than start vs end 14:03:19 rule-edge-outset / rule-interior-outset ? 14:03:21 and to be set independently 14:03:37 fantasai: I think you want outset so that the shorthand is prefixed 14:03:45 SebastianZ: I wouldn't call it outset 14:03:50 ... the outset can still be an inset 14:03:56 fantasai: but that's an inset 14:04:01 rule-outset-edge / rule-outset-interior 14:04:06 ... negative 14:04:12 ... default direction is out 14:04:27 fantasai: should we go with interior vs. exterior? 14:04:33 astearns: I prefer edge 14:04:40 fantasai: less parallel 14:04:45 SebastianZ: I'd prefer inner / outer 14:05:01 ... interior / exterior might be difficult 14:05:18 astearns: rule-outset-{inner,outer}? 14:05:48 PROPOSED: Two longhands to set inner/outer outsets, names at editor discretion 14:05:52 RESOLVED: Two longhands to set inner/outer outsets, names at editor discretion 14:07:22 fantasai: the shorthand needs to set both, should it be inner outer or outer inner? 14:07:30 alisonmaher: one value applies to both 14:07:46 fantasai: but if you specify both should it be inside then outside or vice versa 14:07:52 SebastianZ: gut feeling says inside then outside 14:07:56 fantasai: let's go with that 14:08:05 RESOLVED: The shorthand lists inside first 14:08:22 Subtopic: [css-gaps-1] Asymmetric start and end offsets 14:09:20 fantasai: inner / outer should take too value, but shorthand will take four values 14:09:33 rule-outset: / 14:09:43 SebastianZ: three right? outer only one? 14:09:50 rule-outset: [/ ] 14:09:51 q+ 14:09:51 fantasai: it's reasonable to extend differently 14:09:59 ack alisonmaher 14:09:59 ... we should do it in both axes 14:10:21 alisonmaher: going back to this impacting layout... gap decorations are painted at the container level, so item level control we're proposing... 14:10:32 fantasai: we're not doing item-level control here, that's start v end 14:10:50 ... for the other issue the container is still painting the decorations, just consulting the items 14:11:03 emilio: just like tables :') 14:11:31 diekus has joined #css 14:11:55 q+ 14:12:03 kbabbitt: I propose single values for all, slash separates inside vs. outside, space start and end 14:12:16 ack SebastianZ 14:12:27 SebastianZ: wondering whether that targets the intersections between... 14:12:40 ... we should have a value for ?? both 14:13:01 ... to meet both? 14:13:06 fantasai: 50%? 14:13:09 SebastianZ: I think so 14:13:13 fantasai: we could add a keyword if we want 14:13:47 emilio: for the 50% thing, you need to be careful with transparency 14:13:54 emilio: don't paint two borders in the same place 14:14:17 emilio: when they meet, you either combine the borders into one and paint with that color, or paint both 14:14:28 emilio: are there use cases for these? 14:15:05 fantasai: I think what you want is that as long as they overlap you do one line 14:15:30 proposed shorthand syntax: rule-outset: [/ ] 14:15:32 emilio: but that's tricky right? that depends on DPI 14:15:48 emilio: some questionmarks missing I think? 14:15:56 ... but yeah that seems fine 14:15:57 PROPOSED: rule-outset: ? [/ ?]? 14:16:07 rule-outset: ? [/ ?]? 14:16:29 RESOLVED: rule-outset: ? [/ ?]? 14:16:56 Subtopic: [css-gaps-1] Serializing `column-rule` shorthand from separate longhands 14:17:23 oSamDavis: The gaps spec extended column-rule to support list of values 14:17:38 oSamDavis: but this becomes tricky when we have separate longhand values that don't necessarily line up 14:17:46 oSamDavis: I put an example there 14:17:52 oSamDavis: e.g. auto-repeat, or not 14:18:24 oSamDavis: Kevin brought up idea of [missed] 14:18:33 oSamDavis: also separate problem with serialization 14:18:45 oSamDavis: if it's impossible to get from longhand can serialize as empty string 14:18:48 q+ 14:18:53 oSamDavis: it's not impossible here, but challenging 14:19:10 q+ 14:19:11 oSamDavis: Should we return empty string here, or try to repeat to get them to line up 14:19:13 ack kbabbitt 14:19:36 kbabbitt: I think the tension here is how far do we want to make implementations go to be able to construct a shorthand when theoretically possible 14:19:46 kbabbitt: vs reflect what author originally specified 14:20:02 kbabbitt: I'm not sure what the right answer is 14:20:14 kbabbitt: don't want to go too far in reconstruction 14:20:32 kbabbitt: if the repeaters line up exactly, then reconstruct the shorthand; otherwise return empty string 14:20:34 kbabbitt: but would like more opinions 14:20:35 ack SebastianZ 14:20:49 SebastianZ: I don't have an idea, but currently, these are not list-valued properties, right? 14:21:01 SebastianZ: they use spaces, not commas for values, right? 14:21:06 SebastianZ: and they're not linked, right? 14:21:15 SebastianZ: so that's difference to the thing we resolved on in 7164 14:21:29 SebastianZ: so resolution of that issue doesn't apply here 14:21:50 kbabbitt: There isn't a core property, they're all co-equal 14:22:13 SebastianZ: should we introduce one, say one is the coordinating list base property , and then treat it like list-valued properties? 14:22:16 https://www.w3.org/TR/css-values-4/#linked-properties 14:22:38 kbabbitt: Idk if that would work, because you can have auto-repeaters, and we don't know how many that expands to 14:23:02 kbabbitt: the way coordinated list valued properties work, coordinating property has a fixed number of properties, and others repeat to match it 14:23:28 SebastianZ: I'm just imagining if we introduce slashes for the shorthand, can we allow repeat in all of them? 14:23:49 SebastianZ: maybe use the values defined in each longhand to serialize the shorthand 14:24:03 oSamDavis: Like grid? 14:24:24 SebastianZ: you can still distinguish them because 2nd part of repeat function is different for each 14:24:47 SebastianZ: won't repeat them, but just serialize how they're written in the longhand 14:25:11 oSamDavis: Only kind of issue is if we introduce slashes, then default width might present bacjward compat issues, because slashes would b enew syntax 14:25:25 SebastianZ: well, repeat function is new 14:25:34 SebastianZ: but then current syntax would be legacy syntax 14:25:48 SebastianZ: so old one without slashes and new one with slashes 14:25:54 SebastianZ: but repeat functions by second param 14:26:02 SebastianZ: so don't necessarily need slashes between them 14:26:16 ack fantasai 14:26:30 fantasai: was wondering why we didn’t want to do a coordinated list property 14:26:45 fantasai: but that was the coordinated repeat stuff 14:26:50 noamr has joined #css 14:27:08 astearns: 3 options 14:27:12 astearns: combinatorial explosion 14:27:15 astearns: slashes 14:27:20 astearns: giving up and returning an empty string 14:27:38 fantasai: slashes? 14:27:59 SebastianZ: to distinguish the 3 types of values 14:28:12 fantasai: they're syntacticaly distinct already 14:28:27 SebastianZ: makes it easier to read 14:28:34 fantasai: just put them on different lines 14:29:42 ... 14:29:43 fantasai: no slashes 14:29:58 fantasai: I think we should reserve punctuation for when we actually need syntactic disambiguation 14:30:28 SebastianZ: So we could just serialize the longhands in sequence 14:30:32 fantasai: without interleaving into a joint list 14:30:57 astearns: So just join the longhands with spaces 14:31:22 kbabbitt: just want to hear is to what extent we want to synthesize the list 14:32:43 fantasai: In background etc you can create a list of values, which allows you to specify the items that correspond together 14:32:44 column-rule: 1px solid red, repeat(auto, 1px solid black), 1px solid green, 1px solid blue; 14:33:30 fantasai: I guess if you can do that, then do that 14:33:40 fantasai: otherwise I guess returning empty string because you're out of sync is probably fine 14:33:43 PROPOSED: Serialize a shorthand if the longhands line up, otherwise return empty string 14:35:34 emilio: ... yeah, don't do that 14:35:48 emilio: if you combine them and then inherit, that would give you a different value 14:35:53 emilio: returning empty string is fine 14:36:10 s/that/that (aligning misaligned things via LCM)/ 14:36:12 SebastianZ: The shorthand is a list-valued property, but the longhands are not 14:36:14 fantasai: that's weird 14:36:16 noamr has joined #css 14:36:20 SebastianZ: maybe that's the issue! 14:36:51 column-rule-color: red repeat(auto, black) green blue; 14:36:53 kbabbitt: the longhands can take lists, but they don't need the commas to disambiguate 14:37:04 fantasai: if you have a list that's comma-separated in the shorthand, should use commas in the longhands also 14:37:33 SebastianZ: Normally, would epxect to group the different longhands 14:37:58 SebastianZ: You group first width, then colors, then style 14:38:04 kbabbitt: that seems awkward to maintain 14:38:32 (fantasai consults the spec) 14:39:01 SebastianZ: So before was one value each of width, color, style 14:39:07 SebastianZ: now extended to have multipel of these values 14:39:14 -> https://www.w3.org/TR/css-values-4/#linked-properties 14:39:49 fantasai: If we're doing coordinated lists, we should use coordinated list syntax, not something different 14:39:56 fantasai: should behave the same and use the same syntax 14:40:05 fantasai: If we need extensions such as repeat()s, then let's extend it 14:40:30 fantasai: but still should be compatible otherwise 14:41:06 kbabbitt: then which would be the base property? 14:41:53 ... 14:42:05 fantasai: maybe would need to take the max. Hard to say which shoudl be the base property 14:42:11 astearns: Way too much time on this issue 14:42:22 astearns: I'm not entirely sure how much ppl will care about the serialization of this shorthand 14:42:29 fantasai: when it's mismatched 14:43:04 SebastianZ: so maybe serialze to empty string if not matched 14:43:11 PROPOSED: Serialize a shorthand if the longhands line up, otherwise return empty string 14:43:46 RESOLVED: Serialize a shorthand if the longhands line up, otherwise return empty string 14:44:33 PROPOSED: this shorthand and its longhands should use consistent punctuation 14:45:07 RESOLVED: this shorthand and its longhands should use consistent punctuation 14:47:16 Topic: Line Clamp 14:47:23 diekus8 has joined #css 14:47:30 smfr_ has joined #css 14:48:06 Subtopic: [css-overflow-4] `line-clamp` shorthand syntax is ambiguous 14:49:14 (folks are convinced by the presentation) 14:49:55 andreubotella: [explains slight different between "" and none] 14:50:15 fantasai: why not just rename 'none' to 'clip' or something 14:50:23 florian: in any case we should handle empty string case better 14:50:41 fantasai: block-ellipsis: no-ellipsis 14:50:54 andreubotella: we weren't planning to ship the value in the initial rollout 14:51:12 andreubotella: but someone is working on text-overflow: so maybe we can do it anyway 14:51:51 florian: if there is a string, it needs to insert the string. if the string is empty, insertion of nothing and non-insertion, difference is not deliberate 14:52:15 florian: difference now is that when you insert empty string, in some rare cases you delete the whole line 14:52:23 noamr has joined #css 14:52:30 andreubotella: block-ellipsis clamps to the last line break opportunity where the ellipsis fits 14:52:45 andreubotella: if no line-break opportunities, then you replace the line with the ellipsis 14:52:49 florian: that is not deliberate 14:53:31 fantasai: still think having a keyword would be nice, even if you are fixing the string 14:53:54 ... 14:54:02 fantasai: isn't it the initial value? 14:54:12 andreubotella: no, but it is the default value when omitted in certain shorthand combinations 14:54:41 SebastianZ: my suggestion was to use a new keyword for max-lines, 'unlimited' 14:54:51 SebastianZ: because that was the part where 'none' in line-clamp and max-lines clashed 14:54:54 SebastianZ: right? 14:55:01 andreubotella: -webkit-line-clamp: none still needs to disable clamping 14:55:10 andreubotella: though behavior of all browsers is consistent now, used to be weird 14:55:30 andreubotella: line-clamp: none doesn't need to map to max-lines: none, but 14:56:08 SebastianZ: should introduce new keyword for not clamping, then it woudl solve the issue 14:56:21 andreubotella: because clas his between block-ellispsis: none and none 14:56:50 fantasai: so, suggest none -> no-ellipsis 14:56:56 florian: could just say "" 14:57:03 fantasai: but then you have to implement 14:57:09 florian: yeah 14:57:51 fantasai: It's useful to be able to separate that out as a feature 14:57:56 +1 for no-ellipsis 14:58:27 fantasai: there are other implementations than chrome. If is significant work, then don't make it required for basic behavior 14:59:09 florian: 'blank' is easier to type than ellipsis 15:00:07 SebastianZ: blank could be misinterpreted as a space 15:00:14 [nods in sympathy] 15:00:58 [more bikeshedding] 15:01:56 q+ 15:01:59 Florian points out that Chrome is only now implementing text-overflow: , despite how old the property is 15:02:07 ack oriol 15:02:15 oriol: can say it's a string, but only allow some strings 15:02:24 oriol: e.g. grid-template-areas restricts which strings are valid 15:02:31 oriol: it's weird, but could be expanded in the future 15:04:49 RESOLVED: Rename block-ellipsis: none to no-ellipsis, make empty string behave the same as it. 15:07:23 I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html fantasai 15:09:49 topic: end 15:09:57 zakim, end meeting 15:09:57 As of this point the attendees have been futhark, kbabbitt, rachelandrew, alisonmaher, florian, kizu, ydaniv, diekus, oriol, ChrisL, emilio, moonira, lea, SebastianZ, flackr, 15:10:00 ... bkardell, JoshT 15:10:00 RRSAgent, please draft minutes v2 15:10:01 I have made the request to generate https://www.w3.org/2025/08/20-css-minutes.html Zakim 15:10:07 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 15:10:07 Zakim has left #css 15:33:36 SebastianZ has joined #css 15:41:57 fantasai has joined #css 15:59:44 castastrophe has joined #css 16:01:12 fantasai has joined #css