- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 25 Sep 2025 19:32:12 -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 Images
----------
- RESOLVED: Update WD of css-images-4 (Issue #12756: Updated WD of
CSS Images 4)
CSS 2 & Sizing
--------------
- The group was given an overview of the proposal to address issue
#12218 (How do min/max block sizes affect bottom margin collapse
with last child?); first resolve intrinsic height, not including
end margins of contents, then check the actual height, and if
they're the same we allow collapse. Concerns were raised about
the implications of how the proposal would handle height:auto and
calc-size(). Discussion will return to the issue and a few
interested folks will discuss more offline.
CSS Align
---------
- RESOLVED: When resolving align-content:normal on a table cell, we
use safe alignment (Issue #12220: Does `vertical-align`
on table cell set `align-content` safely or not?)
CSS Tables & Sizing
-------------------
- RESOLVED: width:max-content prevents table-layout:fixed from
working (Issue #10937: What sizing keywords allow fixed
table mode?)
CSS Anchor Position
-------------------
- In order to determine the best solution for issue #12732
(position-visibility: anchors-visible should be clear about when
is visibility determined), the group will start by trying to
understand what types of clipping should position-visibility be
checking for. Once that is clear, the group can move on to answer
some sub-questions.
- RESOLVED: 'any' keyword is allowed wherever 'span-all' is allowed,
and omitted values that would default to 'span-all'
default to 'any' for queries (Issue #12610: Add `any`
keyword support to `anchored(fallback)` container queries)
- RESOLVED: No change for the default, we'll investigate a switch
(Issue #12682: fallback-position behavior: spec vs.
expectation)
Web Animations/CSS Animations
-----------------------------
- RESOLVED: Syntax of animation-trigger is [<dashed-ident> <behavior/
actions>]+# (Issue #12652: animation-trigger CSS syntax)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0016.html
Present:
Rachel Andrew
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
Oriol Brufau
Kurt Catti-Schmidt
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Rune Lillesveen
Chris Lilley
Alison Maher
David Marland
Romain Menke
Eric Meyer
Cassondra Roberts
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Anne van Kesteren
Lea Verou
Regrets:
Mason Freed
Josh Tumath
Scribe: TabAtkins
Scribe's scribe: fantasai
Winter F2F Dates
================
<fantasai> -> https://app.rallly.co/poll/JVvrK6xuIeIK
fantasai: Reminder to fill out the poll for dates so we can plan the
winter F2F!
Publications
============
Updated WD of CSS Images 4
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/12756
RESOLVED: Update WD of css-images-4
Flexbox Publication
-------------------
ChrisL: other is flexbox
fantasai: last I checked, it needed Changes compiled, and I haven't
finished that
ChrisL: we were waiting on an edit from you, and you posted that
you'd done it
fantasai: yes. so now it's just compile the changes list and publish
astearns: so let's get that Changes list updated, we'll come back to
CRD when it is
CSS 2 & Sizing
==============
How do min/max block sizes affect bottom margin collapse with
last child?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12218
oriol: a container can collapse its bottom margins with its contents
bottom margins *if* the height property computes to auto (plus
border/padding/etc)
oriol: but it's not clear how min-height and max-height should affect
that
oriol: behavior in webkit and servo is they just check 'height'. if
it's auto, they collapse. even if min-height is large enough
that the margins don't overlap
oriol: I don't think this makes sense, want to change to match gecko
and blink
oriol: they check that the final height is the intrinsic height, and
only allow collapsing bottom margins in that case
oriol: some weird things. intrinsic height is 20px, max-height:0,
min-height:20, the heights will match
oriol: but the height that actually wins is an extrinsic height. if
specified in 'height', that would prevent collapsing
oriol: also not clear how this works with the intrinsic keywords in
the *-height props
oriol: Ian has a proposal in the issue which sounds fine to me
oriol: we just stop checking that the height computes to auto
oriol: instead we first resolve intrinsic height, not including end
margins of contents, then check the actual height, and if
they're the same we allow collapse
oriol: I think this is fine, so long as it's web compatible
oriol: not sure if Ian's on the call, but I suppose he's willing to
try it
iank: yes, I'm willing. scariest thing I can think of is if you have
a container with height:100px, and a direct child with
height:100% and margins, that margin will start poking out.
iank: it already pokes out the top, so there's at least symmetry.
it's a relatively simple change for us so we're willing to try
it out
oriol: so I guess we can resolve, and if it's not web-compat we can
revisit
fantasai: checking understanding...
fantasai: you set height to 20px and intrinsic size happens to be
20px, you'd collapse margins
fantasai: but setting to 21px wouldn't allow collapse
oriol: yeah
fantasai: that seems like a problem if you're animating between
values, just as you touch the intrinsic height
fantasai: so I think it's not great
fantasai: but sympathize with simplifying the logic
oriol: good point. maybe instead of completely dropping the
height:auto condition... we could keep it but
oriol: for example, non-zero padding bottom. that prevents collapsing
bottom margins. then you include the content margins into
intrinsic height
oriol: I think if height also prevents collapsing bottom margins, we
should also include bottom margins in intrinsic height
iank: not wild about that
iank: note we already have the problem Elika brings up with animating
max-height
iank: and animating max-height is quite common
emilio: and you almost always clip due to it being a BFC anyway
fantasai: with max-height you don't have a single point, you have a
flip point where you go from collapsing to not collapsing
fantasai: this behavior is weird because you collapse at only one
single point
astearns: is that weirdness worse than the current, where things
collapse or not only based on whether you have height:auto
set?
fantasai: I think that's worse, yeah. happy to extend the height:auto
stuff to include intrinsic sizes
fantasai: especially in block layout, all the intrinsics are
equivalent
fantasai: and height:auto is interesting because it's.... your BFC
won't collapse anyway
fantasai: I think if you have any kind of intrinsic size on height
you can be allowed to collapse
fantasai: but if your height value is a fixed size it shouldn't clamp
iank: if we go down this route I'd like to do what blink does
iank: we take the initial block size, and see if that's definite or
not. that's subtlety different from checking the keywords
iank: we try to resolve the block size with no intrinsic sizes,
there's rules that fall out of that. calc-size() complicates,
for example. and if that's indefinite we allow collapsing
margins
fantasai: not sure I understand
iank: it's close... the reason we've gotten into this situation is
the rule was written with css2 in mind, where only 'auto' was
intrinsic
iank: we've added so much more, especially calc-size()
iank: so the current thing we do in blink is in each layout, you
always calculate an intrinsic block size
iank: I'd like to use the same logic here for margins
fantasai: followed until the last
iank: so we calculate the initial block size. if it's indefinite, we
allow collapsing margins
fantasai: is "initial block size" - what is it?
iank: at the start of every layout algorithm you compute this size...
fantasai: say a <p>, what's the initial
iank: indefinite, since those are height:auto
TabAtkins: Ian's brought up calc-size() a few times. I want to make
sure calc-size(auto, 20px) is not meaningfully different
from 20px
TabAtkins: that should act, for all purposes, the same of having an
actual intrinsic size of 20px
TabAtkins: but because directly specifying 20px, would be nice if it
matched 20px directly
TabAtkins: but those should be the same, I think
fantasai: I was gonna say opposite. it might make sense to have
calc-size() always allow margin to collapse
fantasai: the same as if it was just "auto"
fantasai: margin collapse is just real weird with min/max etc. you
can have margins collapse that aren't actually lined up, if
you imagine margins as a transparent boundary around the
element, because partial collapse doesn't exist. they
either collapse or don't.
fantasai: so having calc-size() behave as always collapse probably
makes sense to me
astearns: we're finding more ways to disagree, let's take this back
to the issue
<fantasai> iank, TabAtkins we can maybe discuss this on Friday if
iank's in the office
CSS Align
=========
Does `vertical-align` on table cell set `align-content` safely or not?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12220
oriol: when align-content:normal on table-cell, spec says to use
vertical-align
oriol: so vertical-align:bottom acts like align-content:end
oriol: in some corner cases it might be possible to have contents of
a table cell overflow the cell
oriol: these corners cases aren't very interoperable, but I could
trigger them in both blink and webkit
oriol: wondering if these alignments, then should be safe or not
oriol: spec doesn't say whether it's safe or not, so I suppose it's
the default safety
oriol: but browsers don't agree with that or each other
oriol: Gecko I couldn't trigger overflow anyway
oriol: fantasai said probably safe is better, I'm fine with that
fantasai: in general a lot of css2 stuff did safe overflow
fantasai: it's a better default behavior in many cases
fantasai: so given it's a legacy behavior, I'd prefer safety for
vertical-align
astearns: other comments?
oriol: proposed resolution: when resolving align-content:normal on a
table cell, we use safe alignment
astearns: concerns?
RESOLVED: when resolving align-content:normal on a table cell, we use
safe alignment
CSS Tables & Sizing
===================
What sizing keywords allow fixed table mode?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10937
iank: we had a resolution to just have width:auto trigger fixed table
layout
iank: this isn't web-compat, there's a library that sets
width:max-content on tables and assumes they'll go into
fixed mode
iank: so my proposal is we have width:auto *or* max-content, we
trigger fixed layout.
iank: not including a calc-size(), it's those keywords literally
astearns: so just adding one more condition to the list?
iank: yes
oriol: correction, auto/max-content *prevent* fixed layout.
fantasai: so you can set table-layout to fixed or auto. if you set
'fixed', but width is 'auto' (or, proposed, max-content),
you'll instead get auto layout.
fantasai: can we instead just say that only extrinsic sizes allow
fixed?
iank: no, doesn't work
oriol: also if we add more conditions it's harder to opt into this
behavior
<emilio> So we're resolving on Gecko's behavior right?
astearns: so proposed resolution: add max-content to the list of
exceptions that prevent table-layout:fixed
iank: I believe yes, gecko's behavior
RESOLVED: width:max-content prevents table-layout:fixed from working
CSS Anchor Position
===================
position-visibility: anchors-visible should be clear about when is
visibility determined
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12732
emilio: the spec doesn't say when the anchor's visibility is checked
emilio: and when I was looking to implement, I realized the spec
technically allows....
emilio: if it did something more complicated you could only do it as
post layout
emilio: but the clipping thing specified is at layout time
emilio: the issue is about defining *when*
emilio: webkit does it during layout. blink does some intersection
observer thing, which is a bit more flexible
emilio: but might be more confusing
emilio: if you change layout in a way that overflows, then
elementFromPoint(), whether that hit test succeeds or not
depends on timing
emilio: no strong opinion on what happens, just want it specified
emilio: I think Tab added an edit
emilio: should check with WebKit. and spec edit should use some of
the post-layout things Rune is doing.
TabAtkins: I specified "just before ResizeObserver", because that's
what Philip said and Emilio agreed. More details would be
great.
emilio: it needs to be a bit more detailed, because ResizeObserver
loop is more stuff - content-visibility, scroll size
observer... it needs to be specced in a more detailed way.
rune can give details
futhark: sorry, don't have specific context on position-visibility,
but it does make sense to happen at same time
futhark: also on whether post-layout snapshot happens before or after
resizeobserver
futhark: ties in, I agree
fantasai: I pinged Antti to see if he has feedback. I have no idea
how this timing fits in with anything
fantasai: I just want authors to have something that generally works.
not sure to what extent we care about exact nuances beyond
that
fantasai: so how much of this is about authors caring about timing,
and how much is about writing WPTs
fantasai: so long as the author-observable behavior is something
they're happy about, and we have interop on aspects that we
need *for authors*
emilio: not about locking things down. timing issue ends up... if we
don't define it, we'll hit compat issues.
emilio: it's pretty different observable behavior. if you do it
before resize, then layout changes from an RO won't hide an
anchor until next frame
emilio: on flip side, if you do it during layout, that's most CSS-y
it's not really observable, but it's less flexible. can't
check for intersection with other elements.
emilio: I'm assuming blink is actually reusing Intersection observer,
which does a lot more than just checking scroll overflow
emilio: that's a big behavior different, should use one or the other
emilio: IO uses overflow-clip, o-c-margin, etc
emilio: and those are probably something the author would expect
to work
fantasai: yeah, defining whether we check clip is definitely defined
TabAtkins: I think that's already defined
TabAtkins: We should define behavior we want
emilio: right now I think spec is just overflow based
astearns: so how to resolve on this?
emilio: if we want to check IO things, we need to define a fixed
point in the frame timing
fantasai: I think we should just be checking for what's in the spec
right now
fantasai: if we did clip path and other stuff.... I don't think
that's necessarily what authors would expect
emilio: if you did this as an author you'd do IO
fantasai: sure but I'm not convinced it's really what you *want*
fantasai: so we have some questions to investigate. what do we think
authors expect about clip behavior and anchor visibility?
and the timing question
fantasai: which depends on that first question, so let's answer that
one first
emilio: I think that makes sense
emilio: I think spec currently only does check from the anchor to the
CB of the positioned El, and that's another big change from IO
fantasai: right, I think IO isn't what we want to do
emilio: maybe. I think it's weird, for example, to not intersect with
the viewport.
astearns: take back to the issue, then?
fantasai: yes
Add `any` keyword support to `anchored(fallback)` container queries
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12610
fantasai: discussion about anchored() query for anchor-position-2,
where you can ask which area it's anchored in
fantasai: proposal was to add an 'any' keyword, combinable in the
same way span-all is combinable, so you can query "I want
to check if it's on the left, in any track"
fantasai: Tim brought up that if you omit the keyword from an axis,
it would make more sense to default it to 'any' in queries,
rather than span-all like in the property
fantasai: so proposal is that a duplicated keyword is duplicated as
normal, but if it would instead default to span-all in the
property, it defaults to 'any' in the query
<TabAtkins> +1
TabAtkins: Sounds good. Tim's argument makes sense.
<fantasai> PROPOSED: 'any' keyword is allowed wherever 'span-all' is
allowed, and omitted values that would default to
'span-all' default to 'any' for queries.
futhark: is it possible to ask for fpwd for anchor-position-2 once
this is in?
astearns: let's get this in first
astearns: objections?
RESOLVED: 'any' keyword is allowed wherever 'span-all' is allowed,
and omitted values that would default to 'span-all' default
to 'any' for queries.
fantasai: I'd like a week to review the new spec before fpwd
astearns: Rune, could you add a comment to #6900 to ask for
publication next week?
Web Animations/CSS Animations
=============================
animation-trigger CSS syntax
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/12652#issuecomment-3292939040
fantasai: two things. first here is the syntax of animation-trigger,
which binds a named event to an animation
fantasai: given that comma-separated is already used to align them
with the animations
fantasai: we need something else. could use a trigger() function, but
maybe awkward
fantasai: I think the current syntax proposed is to use space
separation, with name first then actions
fantasai: and because the event is syntax unique, it would go first
and dictate what arguments would apply to it
<flackr> something like [<dashed-ident> <behavior/actions>]+ ?
fantasai: yes, like that
flackr: seems reasonable
ydaniv: sounds fine. Robert had some concerns about later having
multiple triggers....
flackr: that's implied here
flackr: the dashed-ident doesn't clash with the behavior/action values
fantasai: an alternative is to flip the order.... but that could be
confusing
proposed resolution: syntax of animation-trigger is [<dashed-ident>
<behavior/actions>]+#
RESOLVED: syntax of animation-trigger is [<dashed-ident> <behavior/
actions>]+#
CSS Anchor Position (continued)
===============================
fallback-position behavior: spec vs. expectation
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12682
fantasai: emeyer raised this. there was previously behavior
differences in fallback choosing
fantasai: we were previously greedy with fallback behavior
TabAtkins: When you have multiple fallbacks, current spec behavior is
to run through the list to pick the first one that doesn't
overflow
TabAtkins: If layout changes such that an earlier option would now be
valid, current spec doesn't go back.
TabAtkins: it only changes which fallback is used when your current
fallback choice stops being valid
TabAtkins: then it re-evaluates the list again
TabAtkins: Alternate behavior is to check after every layout
TabAtkins: so that you're always taking the most favorable option, if
it is valid
TabAtkins: This "greedy" behavior is what WebKit did have earlier,
but spec has for some time focused on "stable" version
TabAtkins: Eric noticed the different and ran some polls on what
they prefer
TabAtkins: Respondents seemed to strongly prefer the "greedy" behavior
TabAtkins: If you resize an element such that first element causes
overflow, and then the popover flips to the other side,
then you widen element again, it still stays on that other
side until you do something to make it invalid
TabAtkins: Preference was to flip back to the first option if possible
TabAtkins: fantasai and I discussed this, and a few points
TabAtkins: We thought the preferred behavior might differ based on
whether you are responding to layout changes, or whether
you are responding to something more passive like scrolling
TabAtkins: Also point out that you would need to re-run multiple
anchor layouts every time layout changes if we went with
"greedy" behavior
TabAtkins: which is therefore less efficient
emeyer: I ran the poll not because I had a preferred, but because I
discovered there were two behaviors
emeyer: when I put up the poll I expected it to be about 50/50
emeyer: it wasn't, which is why I opened the issue
emeyer: even in the small poll there was such a strong tilt
emeyer: there are arguments in both the poll and the issue for both
behavior
emeyer: roman and I are probably in agreement that this should be
switchable
emeyer: as some people say, they'd prefer that, for a given layout
state, the popover should always be in the same place
regardless of history
emeyer: in my slider example, a given slider position should always
give a consistent label position
emeyer: while a11y people said having things jump around more is an
a11y problem
emeyer: I don't think I have a strong preference but it needs to
either be more clearly explained, or given authors an option
kizu: I think we definitely need an option. each version has pros
and cons
kizu: I think current spec behavior is okay as default if it has
better perf and makes less layout jumps
kizu: but as seen by the poll, people do expect greedy behavior. it's
what the libraries do.
kizu: and it'll be needed for migrating from those js libraries, as
the behavior change might not be wanted
kizu: so I think current spec is okay for default if there's an
option to have a less stateful version
<emeyer> +1 to everything kizu just said
emilio: I'd rather stick with the current spec behavior rather than
having an option
emilio: this option would mean running layout on scroll every time
you're in any fallback beyond the first
emilio: which is annoying
emilio: for a small tooltip that's probably fine, but a sidebar,
something big that's in a fallback state most of the time,
that's not great
fantasai: I think I agree with Emilio that running the choice algo on
scroll is a bad idea
fantasai: definitely not default to it
fantasai: but for cases where you're running layout anyway,
re-evaluating might not be that bad
fantasai: so I'd be open to allowing greedy behavior but not for
scroll. only for CB changes
astearns: I'm hearing even the folks that want a switch are fine with
current default
astearns: should we resolve to use the current spec text as default,
explore a switch in the issue?
<TabAtkins> +1
<Kurt> +1
<fantasai> https://www.w3.org/TR/css-anchor-position/#position-try-order-property
fantasai: a place to have the switch is probably in position-try-order
astearns: proposed resolution is no change for the default, we'll
investigate a switch
astearns: objections?
RESOLVED: no change for the default, we'll investigate a switch
emilio: can we resolve on not being greedy on scroll changes?
<fantasai> SUMMARY: Significant concern about re-running selection on
scroll
astearns: we'll discuss whether we have the greedy switch at all
emilio: ok
Received on Thursday, 25 September 2025 23:32:44 UTC