- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 27 Jun 2025 18:39:04 -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.
=========================================
CSSOM & CSS Position
--------------------
- RESOLVED: Overconstrained insets return their used value prior to
adjusting for the overconstraint (Issue #3059: Resolved
value of over-constrained percentages in inset properties)
CSS Page
--------
- RESOLVED: Make @page/size a legacy alias of @page-page-size, will
get feedback from print formatters on this issue (Issue
#11925: Consider making 'size' a legacy alias of a new
descriptor ('page-size')?)
CSS Flexbox
-----------
- RESOLVED: Accept the PR, `stretch` falls back to `flex-start`, not
`safe flex-start` (Issue #11641: Should 'align-content:
stretch' use 'safe' in the fallback value?)
CSS Overflow
------------
- RESOLVED: Confirm that -webkit-line-clamp should become a shorthand
of line-clamp (unless we run into compat issue) (Issue
#10439: How do `-webkit-line-clamp` and `line-clamp`
interact when both are specified?)
- RESOLVED: Remove the "hidden longhands" text for line-clamp's
longhands, just make them normal longhands (Issue #10439)
CSS Align
---------
- RESOLVED: Change `safe` alignment on scroll containers to align
towards the scroll origin side (rather than the `start`
side) (Issue #11937: The `safe flex-start` fallback
alignment for `justify-content:space-between` is actually
unsafe)
CSSOM-View
----------
- RESOLVED: Actually specify getBoxQuads(), matching Firefox behavior
for now (Issue #10537: update description of getBoxQuads
API)
View Transitions
----------------
- RESOLVED: Make animation-timing-function, -iteration-count,
-direction, -play-state inherit in the VT tree (Issue
#11546: Have the `-image-pair`, `-old`, and `-new`
pseudos inherit `animation-timing-function`)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jun/0017.html
Present:
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Andreu Botella
Justin Breiland
Oriol Brufau
Stephen Chenney
Yehonatan Daniv
Elika Etemad
Robert Flack
Mason Freed
Simran Gill
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
David Leininger
Cassondra Roberts
Florian Rivoal
Daniil Sakhapov
Alan Stearns
Miriam Suzanne
Josh Tumath
Regrets:
Lea Verou
Scribe: TabAtkins
CSSOM & CSS Position
====================
Resolved value of over-constrained percentages in inset properties
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3059
oriol: CSSOM, when it's defining the resolved value for t/r/b/l
oriol: it says that if the property is over constrained, the resolved
value is the computed value
oriol: that's a problem with relative positioning
oriol: with relpos you can only set one of them in a given axis
oriol: if you set left and right, only one works, the other is ignored
oriol: so it's over constrained. per spec, you get the computed value
oriol: but if the value is a %, then no browser gives the %. they all
just resolve it to a px
oriol: so I had a proposed change in the issue
oriol: if the element is not positioned, or computed value is a
length, resolved value is computed value
oriol: otherwise, if property is not over constrained, resolved value
is used length
oriol: otherwise, resolved value is the length that would result from
resolving the computed value, handling the over-constrainment
oriol: I think this matches browsers and covers cases
oriol: so if you're over-constrained, instead of returning computed
value, you resolve the computed value as if it weren't over
constrained
<dbaron> I'd replace "over-constrainment" with "over-constraint"
<dbaron> but otherwise I think the proposal sounds reasonable if it
matches implementations
fantasai: so computing it through to a used value but not handling
the over-constrained adjustments, that makes sense
fantasai: consistent with the model in level 3. in level 2 we
actually changed the value of the weaker inset, now we keep
it and use alignment props to positioning within that
space. so I think that's better.
astearns: so is that actually interoperable? any impls that differ?
oriol: well this is from 2018 and I haven't checked recently. but I
believe it matched impls back then
astearns: I think we could resolve on "have the spec match impls,
using what Oriol outlined in their second comment". is that
good enough?
oriol: I guess that works, yeah
<fantasai> PROPOSED: Overconstrained insets return their used value
prior to adjusting for the overconstraint
RESOLVED: Overconstrained insets return their used value prior to
adjusting for the overconstraint
CSS Page
========
Consider making 'size' a legacy alias of a new descriptor
('page-size')?
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11925
florian: so we've decided we wanted 'size' as a shorthand for width/
height. but we already have 'size' descriptor in @page.
florian: so to limit confusion, might make sense to make @page/size a
legacy alias of a new better name. possible @page/page-size.
florian: though it's not really the size of the page, PDF calls it
the trim box. so naming is hard.
florian: but putting the name to the side, should we make it an alias?
astearns: in favor of the alias, but don't have better ideas on the
naming
fantasai: I think page-size is fine, it's what the user is gonna
think of. if you're printing on continuous paper it's
interesting, but this is what the user will think of as
"the page size"
fantasai: my main concern is if this is compatible with css-to-pdf
renderers
fantasai: if we're not gonna break anything, then sure, let's make
the alias happen
fantasai: but that's not a question I know how to answer
florian: I'm not under the impression we'd break anything, we're not
renaming anything. keeping the old name and making it an
alias to the new one.
florian: so just pages written with the new name and used on legacy
tools would fail
florian: though mike bemford was in the issue, he didn't have
objections to the concept of an alias
astearns: I suggest we resolve on making it a legacy alias of
page-size, and if people disagree they can weigh in
florian: we can prod people
florian: but can move ahead unless/until complains
PROPOSED: make @page/size a legacy alias of @page-page-size, will get
feedback from print formatters on this issue
RESOLVED: make @page/size a legacy alias of @page-page-size, will get
feedback from print formatters on this issue
<TabAtkins> (I also think "page size" is fine, I think "@page {
size: ...; }" is colloquially "page size" already
CSS Flexbox
===========
Should 'align-content: stretch' use 'safe' in the fallback value?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11641
fantasai: We'd tried to correct some of the flexbox values to fall
back to ...
fantasai: ...do safe alignment, and stretch is one that someone
raised a question about
fantasai: currently it's not clear. impls use flex-start as the
fallback, rather than `safe flex-start`
fantasai: I think the right thing to do is to use safe alignment so
we don't lose content off the unsafe edge, but we might not
be able to do that
astearns: so, due to webcompat, we should close no change?
fantasai: that seems to be the conclusion
oriol: I think it's the opposite. my understanding is spec is saying
it should be `safe flex-start`, we implemented in Servo,
everyone else is doing `flex-start`
astearns: right, I was confused about what was actually in the spec
astearns: so proposed is to accept the PR, changing the fallback to
not use `safe`
astearns: objections?
RESOLVED: Accept the PR, `stretch` falls back to `flex-start`, not
`safe flex-start`
CSS Overflow
============
How do `-webkit-line-clamp` and `line-clamp` interact when both
are specified?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10439
andreubotella: last time we discussed, we resolved to add
-webkit-legacy keyword to handle the prefixed property
behavior
andreubotella: we'd previously resolved, or at least agreed, that
it's not safe to change the longhand status of a
property without thinking about it. it's observable
while iterating getcomputedstyle results
andreubotella: issue 8398
andreubotella: so do we want to make this a shorthand, or just an
alias in getComputedStyle?
andreubotella: either way, result won't undo the previous resolution,
just clarifying how to expose it
andreubotella: also question of how to expose the unprefixed
line-clamp as a longhand. currently defined as a
shorthand whose longhands aren't exposed. should it be
a shorthand from the get-go?
andreubotella: if so, especially if -webkit-line-clamp is also a
shorthand, there will be no longhands in the
cssStyleDeclaration data model. it only contains
longhands, and computes shorthands on the fly.
andreubotella: so do we ship -webkit-line-clamp as a shorthand, and
what do we do about line-clamp
florian: I think -webkit-line-clamp should be a shorthand. yes, it's
a change, and we should be careful. but it was non-standard,
if we can't do that we're really stuck. making it a
shorthand is more sensible and consistent overall. if there
are actual compat problems we can talk about them, but this
isn't a property we've had since forever (like 'position'
was).
florian: question about longhands in general, when we drafted this
initially we weren't sure of the syntax space. so we drafted
something with the concern that we might need to change all
the longhands up.
florian: so this was a temporary warning in the spec
florian: but the spec has been this way for a long time now, and
we've revisited the feature a lot but the syntax has been
stable.
florian: so at this point I think it's not useful to hide the
longhands. so I think we should just act as normal now.
florian: the "don't show" was never intended as something permanent
andreubotella: there is one thing in the shorthand behavior that
might not be clear or well-tested, which is
inheritance of block-overflow
andreubotella: block-ellipsis, sorry
andreubotella: currently in my impl, it applies to the entire
line-clamp container, and that defines whether the
ellipsis would apply or not, and how
andreubotella: if that is equivalent to defining line-clamp as a
shorthand as currently defined... I think we need to
think more about the inheriting behavior and how to
disable ellipsis for a particular para or something
andreubotella: I don't think it's a bad idea, but it's something
folks might not be aware of
florian: I agree it's something to think of, but the intent of the
spec is indeed to implement exactly the behavior *as if* the
longhands were there, so this problem is already there.
florian: if we want to talk about whether the behavior of one
longhand should be changed, that's it's own issue.
florian: but the "hidden longhands" problem just opens up problems
that aren't actually interesting to answer, and we should
stop leaning on it
astearns: so first question is whether -webkit-line-clamp should
become a shorthand
florian: we resolved on this before, but we hadn't considered about
our other discussions about how changing longhands to
shorthands is something with compat risk
astearns: so a proposed extra resolution to affirm our shorthand
resolution, absent web compat
astearns: objections?
RESOLVED: Confirm that -webkit-line-clamp should become a shorthand
of line-clamp (unless we run into compat issue)
florian: so the other resolution, remove the "hidden longhands" text
and just spec them as normal
astearns: that's okay with you andreu?
andreubotella: yes, though I'd like to get emilio's opinion
astearns: so we can provisionally resolve to remove the hidden
longhands text
astearns: objections?
<fantasai> +1
RESOLVED: Remove the "hidden longhands" text for line-clamp's
longhands, just make them normal longhands
astearns: I'll tag emilio
CSS Align
=========
The `safe flex-start` fallback alignment for
`justify-content:space-between` is actually unsafe
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11937
dholbert: this is a case where the spec is clear, but browsers don't
match, and we tried to align with the spec and got breakage
dholbert: oriol observed that if we did an additional change we
wouldn't have the breakage, but as it currently stands I'm
not sure everyone is willing to implement both changes
dholbert: so more detail
dholbert: justify-content:space-between and its fallback value
dholbert: currently impls have it fall back to `flex-start`, spec
says to do `safe flex-start`. those differ when your axises
are reserved
dholbert: like row-reverse, flex-start and start are opposite side
dholbert: `safe flex-start` means if you overflow it'll overflow
towards the end side.
dholbert: but that's an issue, if you have -reverse keywords, the
scrollbars start on the end side, so overflowing toward
that actually does cause content to be clipped into the
unscrollable region
dholbert: oriol observed there's some additional spec text that if
you have a scroll container that would overflow off its
start side, you should adjust the positioning so it's not
overflowing. but it's not clear we want to do that.
dholbert: so for simplicity I think we might want to align with impls
and remove `safe`
dholbert: but I don't think I feel really strongly, maybe we want to
wait for both changes
dholbert: but right now spec and impls disagree
fantasai: I think for a scroll container, using the "unsafe" behavior
is the right thing to do, so it'll scroll in the direction
the author is expecting
fantasai: and the spec section about alignment overflow will ensure
the content can be scrolled to
fantasai: if it's not a scroll container, this can result in it
overflowing into the unscrollable area
fantasai: tricky is, don't think we can represent that - safe in
non-scroll containers, unsafe in scroll because it's
actually safe in practice
fantasai: that's probably what we want but it hasn't come up before
dholbert: all the spec text involved here sorta represents that
correctly, to get it you can start to adjust the scroll
position to make it scrollable
fantasai: I know webkit does the thing to expand the overflow area to
include area from the negative scrollable region from
overflowing alignment subjects, I implemented that
fantasai: but you'd be scrolled to the wrong side of the container.
if I have row-reverse, I'd expect scroll origin to be on
the right side (opposite of normal)
fantasai: but if you use safe alignment you'll be scrolled to the
left, so you see the left edge [think I might have gotten
confused here]
fantasai: it's outside of a scroll container that we want to enforce
safe alignment
<fantasai> But within a scroll container, we should use "unsafe"
alignment, because it's not actually unsafe -- the scroll
container makes sure we can see the content
astearns: so based on elika's feedback, think we should remove the
`safe` from the fallback, and see if we can conditionally
re-introduce it for non-scroll containers?
dholbert: makes sense to me
oriol: for scroll containers vs not, you can specify safe or unsafe
but can also omit, giving automatic alignment. that has
different behavior based on scroll or not. not sure if it's
exactly what we want, but we could use it.
fantasai: I think that's a bit challenging. right now, if you want to
center a box that's too small, it's going to overflow and
be absolutely centered. that's default behavior, probably
what people are depending on.
fantasai: one thing we might be able to do is change the definition
of safe alignment, so if the container is a scroll
container, safe doesn't change how you align - it's a no-op
fantasai: that would satisfy the idea that we're just trying to find
a safe alignment. might not be workable, but maybe worth
looking into
astearns: what to do right now?
fantasai: I think we can conclude that for scroll containers,
alignment is as specified (without `safe` adjustment)
fantasai: because you *can* scroll to them
fantasai: so further question is just whether it can be something we
can tie into `safe`, or make it something special for
fallbacks, or what
dholbert: if we don't do safe alignment, we have stuff potentially
overflowing off the top of the scroll container (with the
additional behavior making that stuff scrollable), if
*that* child still has stuff overflowing off of it... that
would be unscrollable regardless, I guess
dholbert: I think I maybe agree with fantasai
astearns: so trying to understand elika's suggestion
astearns: is it to keep the spec as-is but refine the behavior of
`safe`?
<fantasai> Option A) 'safe' alignment follows the specified alignment
on scroll containers, rather than restricting overflowing
content to start alignment, because the scroll container
allows scrolling
<fantasai> Option B) fallback alignment follows the specified
alignment on scroll containers (as above), as a magic
thing that isn't otherwise specifiable
<fantasai> Option C) B, but with a new keyword
fantasai: I think it'd prefer to avoid new syntax, so if we can get
away with changing `safe` to be a no-op on scroll
containers, might be the best option. not sure about compat
oriol: I think in this case, saying `safe` is a no-op on scrollers is
fine. it's a fallback alignment
oriol: but in general, people could set `safe center`, big children
could overflow both directions, not sure if ignoring `safe` is
the right thing to do
astearns: I'm a little concerned about stuffing more magic into the
safe fallback alignment, already complex and not adjustable
by authors
astearns: I'm not opposed to this, but think it's got a little smell
to it
oriol: maybe rather than changing `safe`, rather than it being no-op
we change it so instead of `start` side, we use the scrolling
origin side
oriol: so in a flexbox, it would align to the flex-start side
dholbert: that works if the flexbox itself is scrollable, but not if
the ancestor is
fantasai: we'd only do this for scroll containers
dholbert: okay. that would be making `safe` a little more magical
astearns: so is the proposed resolution that we redefine `safe`
fallback alignment for scroll containers?
TabAtkins: and just fallback, or `safe` in general?
dholbert: I'd say the keyword itself
PROPOSED: Change `safe` alignment on scroll containers to align
towards the scroll origin side (rather than the `start`
side)
<dholbert> looks good to me!
<fantasai> i.e. the item-flow start side :)
RESOLVED: Change `safe` alignment on scroll containers to align
towards the scroll origin side (rather than the `start`
side)
CSSOM-View
==========
update description of getBoxQuads API
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10537
astearns: seems like a reasonable simple request that we should
accommodate
TabAtkins: unsure what's actually being requested - filling in spec
text? get it implemented?
weinig: looks like Sam linked a PR
<weinig> This one is the one I meant -
https://github.com/w3c/csswg-drafts/issues/10968
TabAtkins: looks like Emilio has reviewed the PR, though his comments
haven't been responded to
<kbabbitt> the PR is https://github.com/w3c/csswg-drafts/pull/10538
astearns: let's propose "spec getBoxQuads matching the Firefox
behavior", leave it open whether we do that with the
proposed PR or otherwise
astearns: objections?
RESOLVED: Actually specify getBoxQuads(), matching Firefox behavior
for now
CSS View Transitions
====================
Have the `-image-pair`, `-old`, and `-new` pseudos inherit
`animation-timing-function`
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11546
fantasai: We inherit some of the animation properties through the VT
tree, so you only have to specify it on -group
fantasai: so they'll all sync up their animations
fantasai: Bramus brought up that animation-timing-function should
also inherit for the same reason.
fantasai: makes sense to me
<flackr> +1 sgtm
astearns: looks like Vlad wasn't sure about inheriting *everything*,
but animation-timing-function made sense to them
fantasai: also mentioned were iteration-count and play-state. flackr
probably has an idea of whether those make sense
fantasai: and direction
astearns: should we resolve on all four, or just the timing function?
flackr: maybe it makes sense to inherit all of them on VT, since
they're related
flackr: I'd support all four, if we find one doesn't make sense we
can revisit
PROPOSED: Make animation-timing-function, -iteration-count,
-direction, -play-state inherit in the VT tree
astearns: objections?
RESOLVED: Make animation-timing-function, -iteration-count,
-direction, -play-state inherit in the VT tree
Received on Friday, 27 June 2025 22:39:35 UTC