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