- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 14 May 2025 19:20:15 -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.
=========================================
CSS Position
------------
- RESOLVED: Change stretch alignment case to allow the size to
stretch when the normal alignment case allows stretching
(Issue #11195: Absolute positioning - Is the new inset &
auto-size behaviour web-compatible?)
CSSOM & CSS Grid
----------------
- RESOLVED: Shorthands serialize using the resolved value of the
individual longhands (Issue #11382: Do shorthands
serialize with the resolved value of their longhands?)
CSS Grid
--------
- RESOLVED: Start defining a `grid-collapse` property (Issue #5813:
grid-gap is still taking up space when an element defined
in grid-template-area is not on the page)
CSS Align
---------
- RESOLVED: Values of `justify-self` other than normal or stretch
treat the automatic size as fit-content, just like in
flex/grid (Issue #12102: Clarify how `justify-self`
affects automatic size of block-level box)
- RESOLVED: Auto margins do not prevent justify-self from imposing
fit-content (Issue #12102)
- RESOLVED: Anonymous block boxes always stretch (go with option 1)
(Issue #11461: `justify-items` and anonymous block boxes)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025May/0004.html
Present:
Kevin Babbitt
Andreu Botella
Justin Breiland
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Paul Greiner
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Rune Lillesveen
Vladimir Levin
Jen Simmons
Gaurav Singh Faujdar
Alan Stearns
Miriam Suzanne
Josh Tumath
Munira Tursunova
Bramus Van Damme
Regrets:
Rachel Andrew
David Baron
Daniel Holbert
Chris Lilley
Scribe: emilio
Scribe's scribe: fantasai
CSS Position
============
Absolute positioning - Is the new inset & auto-size behaviour
web-compatible?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11195
oriol: This was discussed a few weeks ago and I couldn't attend
oriol: Not sure if the consequences of the resolution were fully
understood
oriol: The implication is that you can have an abspos with auto
margins that if it has normal alignment it'd stretch, but if
you change self-alignment to be stretch, then it will stop
stretching
oriol: I think that doesn't really make sense and would just cause
confusion
oriol: In flex and grid auto margins don't stretch even if they have
stretch alignment
oriol: but this happens both for stretch and normal alignment
oriol: so I think it's better to have abspos be consistent
oriol: and avoid having the align-self: stretch align with flex / grid
oriol: Also the argument for making consistent with flex/grid feels
weak
oriol: In block layout auto margins don't prevent block level items
oriol: from stretching
oriol: So I'd like to change the previous resolution
oriol: so that if they stretch with normal alignment they also
stretch with stretch alignment
fantasai: Whichever way we go we are going to introduce
inconsistencies
fantasai: in terms of alignment I think being consistent with flex/
grid is more important because that's what authors are
used to
fantasai: in block layout only blink has implemented and it's very
recent so we can probably change it
fantasai: for normal we're stuck with css2, but for the other
keywords it'd introduce inconsistencies
fantasai: are you proposing that auto margins are stronger than
centering in flex/grid but not abspos? That seems like a
bad idea
fantasai: maybe changing stretch only is better than the current
situation, I admit it's quite weird that stretch is less
stretchy than normal
oriol: Not sure the right way to look at this is properties winning
over other
oriol: the way I see it is both margin and alignment have some effect
simultaneously
oriol: e.g. both may affect the auto size to be fit-content
oriol: also auto-margins work by changing the margin box and
alignment works in terms of that box
oriol: so if you have auto margins that fills the whole container
alignment won't do anything, but it's not like it is disabled
oriol: it's more like it doesn't matter which value you use
oriol: whether we decide that self-alignment forces auto size to be
fit-content or auto margins do that I think it's independent
decisions
oriol: and it's not like some values win and some don't
oriol: e.g. even though in flex and grid auto margins prevent
stretching
oriol: then center alignment could prevent stretching even with a 0
margin
oriol: so we could say that center alignment is "winning" over the 0
margin
oriol: so what wins and loses can be subjective
oriol: I prefer seeing it as different things applying simultaneously
fantasai: So iiuc, if you have auto margins and stretch, the first
thing you do is stretch
fantasai: then auto margins end up having no effect (unless max-size
is involved)
oriol: Exactly
oriol: so in this case for abspos neither auto margins nor stretch
alignment force fit-content size (so it can stretch)
oriol: typically alignments won't matter because auto margins will
resolve to 0 and then alignment would do nothing
oriol: but if you have a max-size then you can align stuff using the
alignment properties
fantasai: I think that makes sense. There's a weird clause about
negative and auto in this case, need to go back and check,
but should be fine
astearns: So prev resolution is no change to the spec, what should
the spec say
oriol: A way to word could be "change stretch alignment case to allow
the size to stretch when the normal alignment case allows
stretching"
astearns: Makes sense, what do you think fantasai?
fantasai: Yeah
<emilio> +1
RESOLVED: change stretch alignment case to allow the size to stretch
when the normal alignment case allows stretching
CSSOM & CSS Grid
================
Do shorthands serialize with the resolved value of their longhands?
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11382
oriol: Some longhands have special getComputedStyle behavior, so you
get the resolved rather than computed value
oriol: it's not clear what happens when you're serializing a
shorthand that involves these
oriol: in the issue I have various examples
oriol: e.g. margin: auto and you serialize margin-top you might get
zero, but if you try to serialize the margin longhand itself
you get auto in firefox but 0 in blink/webkit
oriol: it's particularly weird in grid properties
oriol: because the implicit tracks and repeat() expansion
oriol: we have cases where all browsers are different
oriol: I think I prefer what webkit does
oriol: which is you serialize the shorthand as if the computed value
of each longhand was set to each special resolved value
oriol: I think that's the most consistent
emilio: I agree.
emilio: FWIW, I consider the Firefox behavior to be a bug. Haven't
gotten around to fixing, because the getters are in C++
and ...
emilio: What WebKit is doing, resolving each individual longhand, and
then serializing shorthand with that is the right thing to do.
emilio: This is what Firefox does for all things that don't involve
layout
astearns: Web compat concerns or other opinions?
oriol: If webkit isn't having compat issues this is probably fine?
<TabAtkins> +1, I *suspect* this is reasonably safe
<TabAtkins> and we can always add exceptions as necessary
<fantasai> +1 TabAtkins
PROPOSED: Shorthands serialize using the resolved value of the
individual longhands
RESOLVED: Shorthands serialize using the resolved value of the
individual longhands
CSS Grid
========
grid-gap is still taking up space when an element defined in
grid-template-area is not on the page
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5813
oriol: The problem here is that's typical for authors when using grid
to define some tracks in case some optional content is there
oriol: if the optional content is not there, then if they use
grid-gap you get extra space
oriol: they basically want gaps to collapse together if there's no
content in the track
oriol: proposal is an `empty-tracks` property with an initial value
of `normal`
oriol: so empty tracks only collapse gaps with autofit
oriol: then another value (`height` for `empty-cells` or `collapse`
for consistency for `visibility`) that makes a track with no
items in it or crossing it collapse
oriol: there's other proposals which would make it collapse only if
the sizing function is guaranteed to be zero
oriol: or collapsing when the item spans
oriol: but that adds a fair amount of complexity, and the simple
solution already covers the vast majority of use cases
oriol: for other variants we could consider other keywords in the
future
oriol: so I'd go with the simplest way
fantasai: I think this value makes sense
fantasai: some of the other behaviors are probably also valuable
fantasai: so I think the name should maybe be more extensible
fantasai: my suggestion is the `grid-collapse` property (`none` /
`normal` as initial, `empty-tracks` as the value oriol is
proposing)
astearns: `grid-track-collapse` might be better?
emilio: I was going to bring up the name as well
emilio: but seems like a good idea
astearns: Is this always going to be grid specific? Flexbox doesn't
have this implicit things, but masonry might?
astearns: just asking whether this should be layout agnostic since
gaps are more layout-agnostic
fantasai: Conceptually it's about collapsing tracks, more than gaps
fantasai: regarding grid vs. masonry they both use the grid-* track
management properties
fantasai: if we're not making it grid specific we could do
track-collapse, but I think grid- might make it easier to
see they play together
fantasai: was going to bring up that the default value could maybe be
more useful
fantasai: maybe if the track is completely empty and there's an
intrinsic size it should collapse by default
fantasai: not sure about compat though
astearns: Yeah compat is a bit concerning here
oriol: A bit concern about changing the default for web compat
oriol: the doing something different when the track sizing function
is just intrinsic
oriol: might be a bit weird. `auto` is intrinsic, but auto tracks
stretches to fill, should it still be considered empty?
oriol: this is related to the thing I talked about about whether the
track is guaranteed to have a size of zero
oriol: so in general more magic behavior worries me
astearns: So details are going to be fuzzy, but sounds like starting
to specify a `grid-track-collapse` property might be a good
idea?
fantasai: If we call it `grid-collapse` we can expand it to
`grid-collapse-{rows,columns}`
fantasai: the `track-` extra typing might be very wordy. Grid is
mostly about tracks
<kbabbitt> +1 fantasai
PROPOSAL: Start defining a `grid-collapse` property
RESOLVED: Start defining a `grid-collapse` property
CSS Align
=========
Clarify how `justify-self` affects automatic size of block-level box
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12102
oriol: Two implementations of justify-self on block boxes (blink and
servo). We interpreted some things that the spec says in
different ways
oriol: some things we agree on fantasai disagreed on
oriol: want to clarify this
oriol: two questions:
oriol: first could be the effect of `justify-self` on the auto size
of a block level box
oriol: spec says that values other than stretch makes auto size
fit-content
oriol: so it applies to grid/flex items and block level items
oriol: both blink and servo did this
oriol: fantasai was interpreting it as this property doesn't affect
block level sizing, only in over-constrained cases
<iank> +1 to Oriol - it makes it more consistent w/ grid/flex
oriol: I kinda prefer the fit-content behavior unconditional
oriol: allows to explain tables
oriol: could be explained as `justify-self: normal` on keywords is
`start` rather than `stretch`
oriol: on the other hand means diverging from `<center>` and html
`align` attributes since those don't prevent stretching
oriol: I prefer treating block-level boxes as other boxes
oriol: but if fantasai wants to argue for an exception...
fantasai: This also plays into the related issue about the effect of
these properties when anon boxes are present
fantasai: anonymous boxes always stretch
fantasai: so there's an issue there where if you take the position
that this affects fit-content you get inconsistent behavior
if you have anon boxes
fantasai: I initially thought that this was fixing the alignment of
stuff given how long block layout has existed
fantasai: guess we could go either way
iank: In my opinion this makes the feature useful by default
iank: so kinda prefer how servo and blink interpret it
emilio: Don't disagree, but was curious about the anonymous box
situation
emilio: justify wouldn't apply to the anonymous box, right?
iank: Concern for top-level anonymous boxes that are generated
iank: consider our previous behavior a bug, so changed so that
anonymous boxes ignore justify and always stretch, but we can
talk about that issue separately
emilio: Makes sense to be consistent with block (???) to not
introduce other issues
iank: What do you mean?
emilio: If it doesn't do weird things if you have an anonymous block
inside.
emilio: If that's ok, then making it work by default makes sense.
astearns: Do we have consensus? what's the resolution?
oriol: Values other than normal or stretch treat the automatic size
as fit-content, just like in flex/grid
astearns: Does everyone agree?
fantasai: I'm ok with it.
fantasai: we should acknowledge that this makes justify-self not work
for html centering stuff
<TabAtkins> yeah, we've abandoned doing <center> with this now
PROPOSED: Values of `justify-self` other than normal or stretch treat
the automatic size as fit-content, just like in flex/grid
RESOLVED: Values of `justify-self` other than normal or stretch treat
the automatic size as fit-content, just like in flex/grid
oriol: There's another thing about how auto margins behave with this
oriol: in servo we have different interpretations
oriol: there's an example in the issue. If you set `justify-self:
right` then the size will be `fit-content`, however if then
you add auto margins, then these prevent `justify-self` from
forcing fit-content
oriol: in servo justify-self still prevents the stretching even with
auto margins, and I think that makes more sense
<fantasai> +1
<oriol> https://github.com/w3c/csswg-drafts/issues/12102
iank: Yeah basically, do auto margins disable justify-self or just
the alignment part of it
<emilio> +1
<fantasai> If stretching is disabled for zero margins, then it should
definitely be disabled for auto margins
<fantasai> which are applied after sizing decisions
fantasai: This goes back to the first issue, where alignment is
applied after margins
oriol: Right in this case the size of the margin box fills the
container
oriol: so you don't see the effect but it's not "not working"
fantasai: If the box is larger than the container the auto margins
will not absorb that space
fantasai: not sure we want the alignment to take effect in that case
fantasai: if you have auto margins you were expecting a particular
alignment
fantasai: or do you just start-align it
oriol: I think if you have unsafe alignment then why not
oriol: but yeah, not sure
iank: I think auto margins are safe by default, so I think the
defaults are actually the same
fantasai: Right but in this case the margin can't absorb the negative
space
iank: But by default it's safe alignment so the default should be
fine?
fantasai: Not sure it falls out of the definitions
iank: To be clear I'm fine changing blink here
<fantasai> I think CSS2.1 is written in a way that this wouldn't fall
out.
astearns: Does the previous resolution apply here?
oriol: Probably should be a separate one
oriol: The question that fantasai raised could be for a separate
issue. We can resolve for the non-overflowing cases
PROPOSED: alignment values different than stretch cause sizing to be
fit-content, regardless of auto margins
PROPOSED: auto margins do not prevent justify-self from imposing
fit-content
RESOLVED: auto margins do not prevent justify-self from imposing
fit-content
`justify-items` and anonymous block boxes
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11461
<oriol> https://github.com/w3c/csswg-drafts/issues/11461#issuecomment-2842434810
oriol: Since we resolve justify-self can force fit-content size, if
you use justify-items on a block container, a block container
with inline level contents, justify-items won't apply
oriol: if you then add a block, you add an anonymous block level box
and justify-self applies to it
oriol: so it's very unexpected that adding a block-level sibling
changes the alignment
oriol: option 1 would be that anon block boxes would always stretch
rather than using justify-items of the parent
oriol: another option would be that justify-items other than initial
you'd still wrap stuff
oriol: IMO option 1 is the easiest to implement in servo, also avoids
some questions about what to do with percentages and so on
<iank> +1 Oriol - There is a whole can of worms involved w/ option (2)
oriol: percentages in the block axis skips anon boxes, should we skip
them in the inline axis if we consider the other option?
oriol: miriam preferred option 2 since it's more useful for authors (
no need to wrap in implicit elements)
miriam: oriol described what I think, alignment is one of the more
common things to do and doing it easily makes sense
miriam: but either option feels better than the alternative
<fantasai> https://www.w3.org/TR/css-text-4/#text-group-align-property
fantasai: There's one property that allows you to wrap things, not
sure it's implemented
fantasai: the behavior you want is not the behavior that would fall
off from wrapping in anon boxes
fantasai: consider a paragraph with text, block level, then text
fantasai: if we wrap each in a box then they'd be independently
aligned which I'm not sure is what you want
iank: Pretty against option 2
iank: quite a large can of worms
iank: probably big source of confusion for web devs too
iank: a little concerned about compat too
iank: so prefer option 1, authors ??? text-align
astearns: We could resolve on updating the spec to option 1 with
a note
miriam: Ok with that
PROPOSED: Anonymous block boxes always stretch
RESOLVED: Anonymous block boxes always stretch (go with option 1)
Received on Wednesday, 14 May 2025 23:20:46 UTC