- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 6 Aug 2025 19:49:30 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
please respond by starting a new thread
with an appropriate subject line.
=========================================
Gap Decoration Breakout
=======================
- RESOLVED: Change name to rule-overlap (Issue #12540: Bikeshedding
rule-paint-order)
- RESOLVED: Update definition of gap with gutter terminology (Issue
#12084: Gap intersection point definition might need
updating for multi-col)
- RESOLVED: Apply all decorations from left to right (Issue #12527:
Values after an auto repeater when there's fewer values
than gaps)
- RESOLVED: Define gap decoration animations using LCM methods (Issue
#12431: Define interpolation behavior)
- astearns will tag additional folks in issue #12201 (Serializing
`column-rule` shorthand from separate longhands) to get those
with expertise in shorthands to weigh in.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Aug/0001.html
Present:
Kevin Babbitt
Kurt Catti-Schmidt
Sam Davis
Javier Fernandez
Alison Maher
Alan Stearns
Miriam Suzanne
Sebastian Zartner
Scribe: Kurt
Gap Decoration Breakout
=======================
Bikeshedding rule-paint-order
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/12540
kbabbitt: Suggestion for renaming rule-paint-order to rule-overlap
kbabbitt: what this property does is determine whether row
decorations are painted above column decorations
kbabbitt: I've seen arguments in both directions, motivation is that
paint-order sounded jargony. On the other hand we do have
other properties that use "order", such as "paint-order"
in SVG
kbabbitt: wanted to run a poll
Javier: I can see both points, someone suggested overlap. I first
agreed, but someone else mentioned precedent for order, which
I do agree with to align with already existing vocabulary.
SebastionZ: I mentioned order properties
miriam: Do we use order for paint order? I thought we used z-index
for what's on top.
SebastionZ: We do have order in paint-order - in flex and grid, it's
also specifying the order in which things are render in
addition to laid out
astearns: It's a secondary thing, paint order is incidental
SebastionZ: In SVG we have a paint-order property
astearns: Is the difference in how order is used in CSS a good reason
to choose a different name
mirian: It's not a good reason for keeping that name, feels jargony
because I wouldn't understand what that means without
understanding browser paint as a concept, feels jargony and I
don't see the connection to other order properties. I think
rule overlap makes more sense.
kbabbitt: Can we have some other term in CSS to use what we do with
paint?
miriam: z-index is the main one
kbabbitt: I guess so, rule-z-index?
miriam: it's a thing that people think of as "layering" in design
tools, but we have a different concept
alisonmaher: I agree with miriam, current naming might be confusing,
rule-overlap might be more intuitive based on name alone
astearns: I'm hearing maybe not overwhelming consensus, but it sounds
like we could go with rule-overlap because the uses we have
for order in CSS aren't quite the same
kbabbitt: I'm hearing the same thing, if folks are ok with that, I'm
ok, or straw poll
SebastionZ: I don't hold a strong opinion, but we should do a straw
poll
astearns: we'll do a straw poll in irc, two options are 1) keep paint
order 2) change to rule-overlap
<miriam> 2
<alisonmaher> 2
<kbabbitt> 2
<SebastianZ> 1
<diekus> 2
<astearns> 2
<oSamDavis> 1
<javierct> 2
oSamDavis: to Sebastion's point, I feel order is more css jargon
rather than order in flex in grid, but like you mentioned,
it's secondary. I don't have a strong opinion but I prefer
order over overlap
astearns: we are resolved for rule-overlap, value names are also ok
RESOLVED: Change name to rule-overlap
Gap intersection point definition might need updating for multi-col
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12084
scribes: kurt & kbabbitt
javierct: as we've defined gap intersections in the spec currently
javierct: center of an intersection between gap and content edge of
container
javierct: or center of an intersection between gaps
javierct: we need to tweak this a little for multicol
javierct: because with spanners, with this definition we would have
no intersection where the spanner in multicol meets a gap
javierct: which means we always paint behind the spanner across
javierct: what we want to do is tweak the definition to account for
this
javierct: so we can not paint behind the spanner, instead break
before and continue after
javierct: suggestion we floated is twofold:
javierct: 1 tweak the language in spec to define where we define the
gap
javierct: to reflect better what multicol does
javierct: so that now that we use gutter in all three, we can update
the definition of a gap such that the gap will end when
it's in contact with a multicol spanner
javierct: updated definition of a gap would be the center of the
start edge and end edge of a gutter
javierct: and the center of an intersection between gaps in different
directions
javierct: does imply going back and modifying that bit in the flex
spec about the gap
oSamDavis: question, are we saying that we aren't ever going to paint
behind spanner in multicol case?
oSamDavis: if we tweak the definition but control the break rules
oSamDavis: would it allow us to get the decoration behind the spanner
oSamDavis: with `none` today we get that ability
javierct: yes, with `none` we would get that ability
javierct: right now, with column rules without gap decorations, we
never paint behind
javierct: with this change we can control whether we want to or not
oSamDavis: I think the question is, with the change of intersection
definition, would we be able to control whether we want
to, or never paint behind spanner?
oSamDavis: because having intersection at spanner would mean we never
paint
javierct: I assumed we would, because we'd have an intersection right
before and right after
javierct: so we could control, by saying `none` we would go right
through
oSamDavis: that makes sense
kbabbitt: I think the question of whether we can paint behind, I
agree the intent is that we should allow painting behind,
we may need to tune wording to allow that. I can't remember
if each row of blocks in a multicol.
kbabbitt: in multicol-2, we're adding the ability to wrap rows of
columns, and those rows of columns are considered separate
gaps...
astearns: is the change to defining things in terms of gutters
separable from the question of whether we paint behind
spanners - do we have to solve that?
javier: I think defining things in terms of gutters makes things
easier to describe in a generic sense, would work for
multicol and all containers...
astearns: Is the motivation for the change to provide this painting
switch, or is it separate?
Javier: I would say it's the first, the motivation to make the change
to gutter is to generalize painting behavior for gap
alisonmaher: is there a distinction between an intersection from a
spanner vs a wrapping multicol?
Javier: they are different, you would get an intersection - that
doesn't follow with spanners because you wouldn't get a
row-gap
alisonmaher: so there would be row-gap in between
Javier: our current definition already handles wrapping, because it
says a row-gap would form. Spanner is different because it's
not like a row gap. That's where it differs from row-gaps in
other containers and row gap with wrapping.
oSamDavis: Just to also confirm, when you have a spanner, the column
gap is two separate gaps in a multi-col. You wouldn't be
able to paint behind because they don't belong as the
same - even though they look alike, painting behind a
spanner wouldn't exist with new definition
Javier: I guess I'd have to look at it again, because there's an
intersection before and after
oSamDavis: but that intersection is before and after the gap, we'd
have to paint before
Javier: even with "none", we'd paint behind. But that's the behavior
column rules already have. We'd have to decide to support
painting behind the spanner. As now, we'd have to paint
behind spanners, which column rules don't currently
Javier: seems like two different things: give ability to paint behind
spanner, control or just paint behind...
Javier: if we do, maybe we'd need some tweaking, or the other thing,
to modify definition so that we're consistent with existing
column rules to not paint behind spanner for now...
Javier: could leave painting behind spanner for later, but would want
to be consistent with column rules and not paint behind
spanner
astearns: makes sense to me to have new stuff match column rule
behavior. Not aware of any requests for multi col rules to
paint behind spanner, could leave for future. Let's not add
complications no one has asked for.
Javier: that's fair, I agree. As far as definition, are we ok with
change in gutter naming?
Javier: if so, that generalizes the problem and solves not painting
behind spanner, how are people felling about change in gutter
terminology
astearns: I'm inclined to make the change, we have a solution and no
alternative suggested
alisonmaher: I agree. If we do decide to not allow painting behind
span for multicol, I believe we allow configuring this.
We should be consistent w/grid that.
Javier: that's a good point with grid spanners, we do allow that,
there might be more tweaking needed
astearns: For now, we can resolve on updating definition of gap with
gutter terminology
astearns: objections?
astearns: then we are resolved
RESOLVED: update definition of gap with gutter terminology
Values after an auto repeater when there's fewer values than gaps
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12527
oSamDavis: in an earlier issue 11492 we resolved that we would
prioritize non-repeating gaps over repeating gaps
oSamDavis: non-auto over auto
oSamDavis: if the number of gaps was less than number of decorations
oSamDavis: we'd start with leading, then trailing, then auto
oSamDavis: we didn't resolve on the part where the number of gaps
after is less than the number of decorations
oSamDavis: currently according to spec we use the traiing decorations
right to left
oSamDavis: I found that to be confusing as to why we would apply
trailing decorations from right to left rather than left
to right
oSamDavis: as we do in the leading section
oSamDavis: this issue is looking for a resolution in this case where
there are fewer gaps than decorations in the trailing
section
<miriam> +1
<kbabbitt> (I have no objection to changing this.)
astearns: chair hat off, this sounds like a fine change
astearns: other opinions
javierct: I think this makes sense too
javierct: more intuitive I think, initially hadn't even realized we
defined this until it came up
alisonmaher: agree, I think if an author wants all these but doesn't
have enough gaps to do it
alisonmaher: it would be confusing
alisonmaher: going chronologically makes more sense
astearns: Proposed: Apply all decorations from left to right
astearns: objections?
RESOLVED: Apply all decorations from left to right
Define interpolation behavior
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/12431
javierct: for interpolation, part of what we're trying to achieve is
to define what interpolation behavior will be
javierct: currently the way we've been going about it is how
grid-template-rows/columns does it
javierct: specifically we're concerned about repeater part
javierct: grid-template-rows/columns will only interpolate repeaters
if list lengths match exactly
javierct: that's how we started going about it, then there was some
discussion
javierct: makes sense for grid to do that but not necessarily gap
decorations
javierct: might want to interpolate repeaters with different counts
javierct: been some discussion about this, some ideas that have been
floated
javierct: ideas about lining up repeaters, pulling out certain values
so things line up
javierct: I thought about it multiple ways, couldn't find a way to
generalize that behavior
javierct: I put my notes in the issue, but my conclusion / suggestion
was that maybe the best way is to lean towards treating
repeaters as list of values
javierct: expanding it
javierct: and then as a second step, use LCM based method of
repeatable list interpolation we have for other properties
javierct: match lengths of resulting lists that way
javierct: question would arise, as we mentioned before, what we'd
lose before with this way of doing it is that, intermediate
values wouldn't necessarily reconstruct repeater
javierct: if the author interpolates a repeater with another
repeater, intermediate steps would get list of values
rather than repeater
javierct: might be a way to reconstruct repeater
javierct: from these intermediate lists of values
javierct: but I haven't been able to generalize this
javierct: even if one exists, maybe it would be easier for an author
if it's not a lot of math to
javierct: if they inspect an arbitrary keyframe, it's easier to think
about what these lists of values should be
javierct: but if we have a complicated formula to reconstruct a
repeater, authors might not expect that
astearns: it's fine to have intermediate values be explicit lists
astearns: main thing is intermediate values need to be representable
in a way the property can accept
astearns: if we're fudging the list of values in order to recreate a
repeater, that makes it harder for script to process
javierct: agree with that
javierct: lean towards this idea of expanding lists
javierct: even if they don't line up in repeat count, match up lists
with lcm method
javierct: that would solve interpolation between repeaters of
different counts
javierct: but there's the question of auto repeaters
javierct: we don't know the number of gaps at computed-value time
javierct: so we can't expand those lists
javierct: if we see an auto repeater, would we only be able to match
it with another auto repeater?
javierct: and if not, don't interpolate?
javierct: that would be the trickier part
javierct: my gut would be, lcm method solves all cases except this
one, maybe we need to find some sort of exception
javierct: treat auto repeaters as their own element in the list and
only interpolate between auto repeaters if the list lengths
are the same
astearns: you mentioned we don't know how many gaps there are
astearns: but do we need to?
astearns: could the rule be to expand auto repeaters to point where
there's a common multiple between them?
javierct: so repeat(auto, 10 5) and repeat(auto, 2 10)
javierct: expand auto into into 10, 5
astearns: Haven't worked through an example in my mind
astearns: Would expect that interpolation shouldn't have anything to
do with how many or which values are actually used in a
given layout
javierct: I can see that
javierct: can't think of any issues that would come up with that
<kbabbitt> +1, I think we can lcm() between auto repeaters
astearns: want to go back to motivation
astearns: solution makes some sense but we passed over the 'why'
javierct: we don't have the interpolation behavior for gap
decorations defined
astearns: definition could be as simple as flip at 50%
astearns: would an author want to interpolate between different gap
decorations?
javierct: want to change color going smoothly from one to another,
smaller to bigger
javierct: I think smooth works correctly for these rather than
discrete
javierct: ability we want to give the author
javierct: as far as I'm aware, with colors, that's what we usually do
javierct: at the very least match it, because that is what we do when
interpolating colors
javierct: border does it this way
javierct: want to match author expectation
astearns: makes sense
kbabbitt: at minimum, the existing column-rule width/style are
interpretable, we need to keep for back-compat
kbabbitt: the question is what we do for lists now, LCM makes sense
for non-auto repeater, it works...
kbabbitt: for auto repeater to auto repeater, we can take the two and
LCM the combination of those, I can't see why that wouldn't
work
Javier: can you see a case for going from non-auto to auto, or auto
to a list of values
kbabbitt: because of how auto repeaters work, they take up the slack,
so it would be an auto repeater to another auto repeater
with a list length of 0, and I don't know how that would
work
astearns: maybe it makes sense to resolve to define interpolation to
use the LCM method, and define new issues later
astearns: any objections?
RESOLVED: define gap decoration animations using LCM methods
Serializing `column-rule` shorthand from separate longhands
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12201
oSamDavis: column rule shorthand, with gap decorations, you can use a
list and repeat syntax
oSamDavis: when you have longhand, the issue is when you have
individual longhand properties that don't align
oSamDavis: the question is how do you serialize or get shorthand from
individual longhands
oSamDavis: when no repeaters are used, you can line up using LCM, but
using repeaters, you can expand and then using LCM
oSamDavis: this would mean some cases don't preserve auto repeat
syntax for column rule, we would see values blown up to
match separate longhand
oSamDavis: CSSOM serialization rules say either no shorthand or if
you cannot represent, return empty string
oSamDavis: how hard to we want to try to get shorthand, or if we
don't align return empty string
astearns: not aware of escape hatch, where else is it used
oSamDavis: I have seen in border IIRC
oSamDavis: not sure of specifics
astearns: I'm not aware of any, but I might not know about it, where
we go to great lengths to make a longer shorthand value in
order to accurately represent the longhands, seems not
useful
oSamDavis: I'm hearing we could return an empty string when it's
difficult
alisonmaher: do we have a precedent in grid?
oSamDavis: I looked at grid, but grid's shorthand is can have columns
or rows separated by a slash, so it's easier. Can have
properties as part of shorthand, which is not the same as
column rule
astearns: on this one, I think we need to take it back to the issue
or do another call, need shorthand experts with strong
opinions
astearns: I will tag folks in the issue, hopefully will define soon
Received on Wednesday, 6 August 2025 23:50:02 UTC