=========================================
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 Sizing
----------
- RESOLVED: In a flex container's cross axis, stretch sizing keyword
resolves initially against the container, then
re-resolves against the line once the line's size is
determined (Issue #11784: It's false that `stretch` size
behaves as `stretch` alignment)
- RESOLVED: Accept oriol's proposal in
https://github.com/w3c/csswg-drafts/issues/11805#issue-2889260003
(Issue #11805: Intrinsic contribution of `fit-content()`
with cyclic percentages)
- RESOLVED: No change (Issue #12053: Where does the default
aspect-ratio of a <video> come from?)
CSS Values
----------
- RESOLVED: Progress clamps by default between 0 and 1; we'll add
unclamped keyword, or other keyword if folks have
suggestions (Issue #11825: Should progress() functions
clamp to 0-100%?)
CSS Overflow
------------
- RESOLVED: Rename scroll-marker-contain to scroll-target-group
(Issue #12191: Bikeshed scroll-marker-contain property
name)
- RESOLVED: Add second value to scroll-marker-group as [ tabs |
links ] (Issue #12122: Discrete versus navigation scroll
marker mode)
CSS Animations
--------------
- RESOLVED: Triggers are an external controller of the animation
(Issue #12119: How should AnimationTrigger work?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jun/0008.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Awogbemila
David Baron
Justin Breiland
Oriol Brufau
Stephen Chenney
Keith Cirkel
Emilio Cobos Ãlvarez
Elika Etemad
Robert Flack
Simran Gill
Paul Grenier
Jonathan Kew
Roman Komarov
David Leininger
Vladimir Levin
Alison Maher
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Samuel Weinig
Regrets:
Daniel Holbert
Chris Lilley
Florian Rivoal
Lea Verou
Scribe: kbabbitt
Scribe's scribe: TabAtkins
CSS Sizing
==========
It's false that `stretch` size behaves as `stretch` alignment
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11784
oriol: problem here is that the stretch keyword says that it should
have the same effect as stretch alignment
oriol: but this is not the case in any browser
oriol: behavior all browsers were having is that: while computing
cross values of flex lines
oriol: stretch size would stretch against CB
oriol: but once you know line size, stretch size would keep
stretching against CB, stretch align would stretch against
align
oriol: there was some discussion of stretch align, proposal from ??
was: while computing cross align of flex size, stretch align
stretches against size of container
oriol: once it's known, stretches to size of line
oriol: another constraint, while you are computing size of flex
lines, ?? would behave as stretch content
oriol: once it's known, stretch to size of line
oriol: blink has already implemented
oriol: I think it will be shipping next week
oriol: behavior you get is reasonable, maybe a bit more complex to
implement
oriol: but seems fine
oriol: servo is not there yet but close
oriol: main concern is that this is not just affecting new keyword,
also affecting fit-content keyword
oriol: if you use fit-content explicitly or also if align-self
property is not stretch, auto size will be fit-content
oriol: behavior change there
oriol: may be a compat risk
oriol: but I guess Blink will find out soon
fantasai: question I have is: what is the impact from user perspective
fantasai: what are the use case we're trying to enable or not enable?
fantasai: sounds great from a theoretical perspective but is the
behavior we're specing the one that will be most useful?
oriol: not sure about useful or not
fantasai: we can write testcase for any behavior, why is this one
better?
iank: it minimizes compat risk with shipping stretch keyword in all
browsers
iank: old behavior was clearly bad in my opinion
iank: stretching initially should contain it
iank: minimizes compat risk, we'll find out what happens next week
when we try and ship
iank: I can go into concrete constraints here
iank: what this comes down to is, when you lay out a child, you need
to give an available size
iank: e.g. in grid we set an indefinite size for the axis
iank: even if you have align stretch it's going to behave like fit
content
iank: not the same as in flex, we give a definite size and treat auto
as fit-content in that case
iank: constraint is we need one available size that fit-content and
stretch both use consistently
iank: you need one available size because you might have min-width
stretch and ?? fit-content and they can't use different sizes
fantasai: makes sense that those two need to match
iank: given that, we have constraint that when you measure in column
direction...
iank: you pass in the container's inline size
iank: and then you work out size of line
iank: pass in flex line's available size
iank: that and container available size are the sizes we're working
with
iank: so if you stretch to those available sizes you get the behavior
we've currently implemented
iank: we do have the option of coercing stretch to be fit-content
iank: but in my opinion that carries more compat risk
Rossen: fantasai does that answer your question?
fantasai: I think so
fantasai: so the proposal is we compute align stretch against CB
initially
fantasai: and once we have height align we compute against line?
iank: stretch keyword stretches to available space
iank: and then stretches to the line
fantasai: in a multiline container will always be at least as big as
initial computation
iank: yes, common case is they will all be the same
Rossen: anything else?
<fantasai> PROPOSED: In a flex container's cross axis, stretch sizing
keyword resolves initially against the container, then
re-resolves against the line once the line's size is
determined.
iank: looks right to me
Rossen: objections?
fantasai: I think this is more correct than using fit-content,
because stretch is not supposed to be an intrinsic size
RESOLVED: In a flex container's cross axis, stretch sizing keyword
resolves initially against the container, then re-resolves
against the line once the line's size is determined.
Intrinsic contribution of `fit-content()` with cyclic percentages
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11805
oriol: fit-content() function isn't super clear what effect should be
for intrinsic contributions
oriol: for example if you have width property set to a ? amount
oriol: but then max-width is set to fit-content() with percentage
oriol: when you are computing intrinsics, max property contains
percentage, treat entire expression as initial value
oriol: seems strange because you know fit-content will be ? minimum
and maximum
oriol: fit-content will clamp provided value between min and maximum
oriol: when you use this function as a max size, it's strange to me
that we will treat the entire thing as none
oriol: because of percentage
oriol: because this can allow much greater sizes even though we clamp
to something smaller
oriol: my proposal can be summarized as: what we do for length
percentage, then we do the same for just min-content arguments
oriol: but then clamp between min-content and max-content
<iank> +1 this makes sense to me.
oriol: if entire length-percentage ?? to zero, then will be treated
as fit-content of 0
oriol: [reads remainder of proposal in
https://github.com/w3c/csswg-drafts/issues/11805#issue-2889260003]
<dbaron> Yeah, I think this makes sense to me too.
<fantasai> Finished reading the proposal, +1 from me.
oriol: maybe one tricky case
oriol: for example if length-percentage with cyclic percentages could
be treated as automatic minimum size...
oriol: then you cannot express auto min size with a keyword
oriol: or l-p in fit-content function
oriol: so treat entire thing as min-content
oriol: basically list of cases in the issue
oriol: not sure if people have other opinions
oriol: instead prefer affecting entire expression
oriol: e.g. treat entire function as initial value instead
iank: I think we have enough people in IRC agreeing
Rossen: any feedback?
<dbaron> One tiny detail: is it ever possible for min-content >
max-content. If it is (although I hope it isn't), then
fit-content(infinity) isn't necessarily equal to max-content.
dbaron: don't think we need to discuss that here, whoever edits can
think about it
Rossen: only seeing agreement, any objections?
RESOLVED: accept oriol's proposal
Where does the default aspect-ratio of a <video> come from?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12053
iank: a few years ago when we worked on aspect-ratio
iank: we had an issue in 7524
iank: resolved for video element aspect ratio auto
iank: to not pull from default object size
iank: Blink didn't implement initially but other 2 browsers did
iank: as far as I can tell, other browsers did something different to
resolution
iank: all browsers at the moment, if you set explicit width and
nothing else, explicit aspect ratio of 2:1
iank: this issue is: is my interpretation that all browsers are
rendering incorrectly, correct?
iank: 2 possibilities
iank: either should not have aspect ratio by default
iank: interested to hear if other browsers ran into that
iank: currently Chrome Canary has behavior from previous issue
iank: other possibility is option 3 in the issue
iank: the magic 2:1 aspect ratio out of somewhere
iank: curious to hear from webkit or gecko folks
iank: what they ran into when trying to implement previous resolution
Rossen: feedback?
sgill: I worked on that issue from a few years ago
sgill: don't quite remember all details, but issue you created and
details in there I agree with
sgill: what you said in the issue is right, that rendering should be
as you described
iank: so do you think that we should do webkit's behavior or chrome
canary's behavior
sgill: chrome canary's behavior
iank: happy with that, we can close the issue as no change and I'll
report back if Chrome has any issue rolling this out
iank: will let this roll out and then update 6-8 wpts relying on it
Rossen: anyone else?
iank: Proposed resolution is no change
RESOLVED: No change
CSS Values
==========
Should progress() functions clamp to 0-100%?
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11825
bramus: this is about the clamping in the progress function
bramus: which is about to ship in Chrome
bramus: and Safari
bramus: currently progress() does not clamp to 0..100%
bramus: but reading comments there is a request to have it clamp in
some way
bramus: options are: have it clamp by default, add an extra keyword
bramus: as part of first argument
bramus: alternative is inverse of clamp by default
bramus: would like a resolution before this hits
kizu: my opinion is we should clamp by default and have unclamp
keyword
kizu: most cases I've tested want this
kizu: kind of already a shortcut around some math
kizu: possible to do the same with math already but this makes it
more convenient
kizu: for most cases clamping will add more convenience
kizu: for cases where you need unclamped we can still have a keyword
<ydaniv> +1
<fantasai> +1 to kizu
kbabbitt: I was curious - I can imagine the use-case for clamped, can
someone give a use-case for unclamped progress?
weinig: I think any use-case mimicking an animation, since they can
go beyond the 0-100% bounds
weinig: so if you're doing an overshoot, that can be useful
<flackr> +1
kbabbitt: for css animation, we don't have that behavior, we have
basically clamping with fill-mode
flackr: if you have an easing curve, you can easily go beyond the
endpoint with animations
kbabbitt: true
kbabbitt: in progress(), couldn't you achieve that by encoding your
stops to form that same curve?
kbabbitt: I'm mixing this up with interpolate(), nevermind
fantasai: I think kizu and kbabbitt covered the things I was going
to say
fantasai: it is a convenience notation
fantasai: clamping would cover most use cases
fantasai: so that should be default behavior
TabAtkins: don't have a strong opinion on clamped or unclamped
TabAtkins: weak preference for unclamped by default and keyword being
clamped
TabAtkins: based on usability of syntax
TabAtkins: clamped is a shorter word, not conjugated
TabAtkins: matches what function is doing in the first place
TabAtkins: ignoring use cases, would go unclamped by default with
clamp keyword
TabAtkins: but if others feel there are strong use cases to go one
way or other, happy to defer
<kbabbitt> +1 to TabAtkins
<kbabbitt> to clarify, my +1 is to "base it on strength of use cases"
<TabAtkins> `progress(var(--val) clamp, 1, 10)` simpler than `progress
(var(--val) unclamped, 1, 10)`
<fantasai> TabAtkins, that assumes you want them both equally. I
think we're saying that's not true.
<TabAtkins> Yes, I was just providing the syntax example directly,
since kbabbitt minuted me as saying "clamped". ^_^
miriam: agree that clamped is the only use case I've run into
miriam: there are use cases for unclamped but clamped seems default
use case
miriam: ok as long as switching is simple
bramus: if others are saying clamp by default I think that's the way
we should go
fantasai: Proposal is that progress clamps by default between 0 and 1
fantasai: and we'll add unclamped keyword, or other keyword if folks
have suggestions
RESOLVED: progress clamps by default between 0 and 1; we'll add
unclamped keyword, or other keyword if folks have
suggestions
CSS Overflow
============
Bikeshed scroll-marker-contain property name
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12191
flackr: we previously resolved to use the property
scroll-marker-contain to create container for anchor links
flackr: to make those anchors become scroll markers
flackr: but when we started experimenting with this, I found
ergonomically it was confusing that it had scroll marker that
had nothing to do with CSS scroll marker
flackr: propose that we rename to scroll-target-group
<bramus> +1, this tripped me up when I first saw it.
flackr: we will apply target pseudo class to one element within group
<TabAtkins> +1
flackr: I also suggested anchor-target-group but prefer
scroll-target-group
<kizu> +1
Rossen: objections?
RESOLVED: Rename scroll-marker-contain to scroll-target-group
Discrete versus navigation scroll marker mode
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12122
flackr: one of the biggest points of feedback we got on scroll marker
pseudo
flackr: is that these are used for many different use cases
flackr: not all of which are tabs
flackr: and our use of the tab rules on scroll marker pseudos is not
always appropriate
flackr: I'm proposing that we have a mode switch property
flackr: in particular add something to scroll marker ? property that
will choose between navigation mode and I call it "discrete"
but we could call it "tabbed" or some other experience
flackr: switch between whether we get tabbed or some other behavior
flackr: as well as role changes and focus order changes
flackr: to obviate the need to use interactivity to remove items from
tab order
flackr: not proposing we resolve on exact behavior right now
flackr: just want a resolution for initial keyword on
scroll-marker-group to switch between modes
flackr: can have a more detailed proposal at a future meeting
flackr: with goal being we can automatically get correct roles and
behaviors in a way less likely for developers to misuse
Rossen: any feedback?
<fantasai> tabs | links
<fantasai> ?
flackr: I think fantasai is saying those are possible modes we can use
flackr: seems reasonable, I chose ? because of aria roles
<TabAtkins> I do like "links" as a much shorter and more direct word
to use
fantasai: you're talking about behavior of whole group
flackr: I like it, sounds good
flackr: this is just working name, we'll have to come back and
resolve on behaviors
Rossen: PaulG, any opinions from a11y view?
PaulG: still need to review
Rossen: no alarms?
PaulG: we were asked to come up with, for scroll-marker, ... scroll
in general has a lot of issues, differences across OSes
PaulG: either UA deals with it or it's your problem
PaulG: developers have some good tools
PaulG: not sure how we can go further, it's an interactive element
of page
PaulG: until now ? had been kind of omitted, we need to circle up
with some folks
flackr: more about guidance we should give developers
PaulG: not for this discussion, a later thing
flackr: this is giving devs opportunity to establish correct roles &
behavior semantics
schenney: in general anything that makes it easier for devs to get
a11y right without explicit action is something we should
be working towards
schenney +1 to having this mode
flackr: what I'm proposing is we start to prototype this with
specific mode switch as suggested
Rossen: which names are we using?
flackr: tabs | links is fine
Rossen: any other feedback or questions or objections?
RESOLVED: Add second value to scroll-marker-group as [ tabs | links ]
flackr: probably unordered list of properties
CSS Animations
==============
How should AnimationTrigger work?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12119
DavidA: we're trying to add for scroll triggered animations to the
spec
DavidA: adding concept of animation trigger
DavidA: idea is basically for scroll triggered animations you specify
parameters related to scrolling
DavidA: that will kick off the animation at a certain scroll point
DavidA: there's an underlying animation trigger object
DavidA: that we're trying to figure out how that object should
behavior
DavidA: in relation to the animation
DavidA: 2 models we're thinking about
DavidA: trigger as inline mechanism
DavidA: redefine ? animation as basically arming that trigger
DavidA: so that when specified conditions are met it starts
DavidA: other model is this external model where animation trigger is
separate thing
DavidA: based on conditions that have been specified, it calls play
on the animation etc
DavidA: having discussion about that
DavidA: would like to get a resolution
DavidA: what we agreed on is to take the external model path
DavidA: where an animation trigger calls play based on conditions
that have been set on trigger
DavidA: would like to get a resolution on that particular path
DavidA: also posted in issue with proposal, other details
DavidA: would like resolution on path to choose for animation trigger
object
DavidA: would also like resolution on the APIs we created to
explicitly attach animations to triggers
DavidA: with external model we need an explicit way to say trigger ??
animation
DavidA: other way we need to define ... animations get triggers by
default
DavidA: with external model we're pursuing, we thing
animationtrigger.addanimation / removeanimation would be the
way to go
flackr: Brian Birtles is happy with external trigger approach
flackr: among spec authors we're happy with this design
Rossen: others?
<TabAtkins> Sounds reasonable to me.
ydaniv: also in favor of this model
ydaniv: some reservation regarding other things
ydaniv: from brian's suggestions, comments in issue, but better to
discuss separately
Rossen: objections?
<flackr> Proposed resolution: Triggers are an external controller of
the animation
RESOLVED: Triggers are an external controller of the animation
<flackr> Proposed resolution: AnimationTrigger.add/removeAnimation
adds and removes animations from the trigger
Rossen: objections?
ydaniv: had some reservation regarding multiple triggers for single
animation
ydaniv: I think we need to see whether this works or makes things
complicated
ydaniv: the way I see, we need something that says, how is this
triggered
ydaniv: how is state evaluated together
ydaniv: is it AND or OR
ydaniv: and simply allowing multiple triggers per animation is maybe
less useful or less ergonomic in many cases
ydaniv: so I would rather we also consider having a single trigger
for animation
ydaniv: same trigger for many animations is already fine
Rossen: suggest for second resolution, let's work it out in GitHub
issue and we'll take it back up later
Received on Wednesday, 18 June 2025 23:30:00 UTC
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4