- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Aug 2025 19:04: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.
=========================================
Suggest a better name for the `:interest-target` pseudo class
-------------------------------------------------------------
- RESOLVED: Use :interest-source and :interest-target (Issue #12515)
CSSOM View
----------
- There were concerns about the proposal for issue #12040
(`getClientRects()` should return a flattened list of child rects
for `display: contents`) limiting anchor positioning or parts
users so discussion will return to github.
CSS Grid
--------
- RESOLVED: Define that subgrid repeat works exactly the same as grid
repeat (Issue #8493: Subgrid auto repeat calculation when
<line-name-list> size isn't a multiple of remaining
subgrid tracks)
CSS Anchor Positioning
----------------------
- RESOLVED: Create level 2 diff spec for anchor pos and define an
anchored keyword for container-type there (Issue #12390:
Add a new container-type `anchored` for querying anchored
elements)
- RESOLVED: Define a fallback container feature used in the anchored
query function (Issue #12391: Add a `fallback` feature
for querying applied fallback for anchored elements)
CSS Animations
--------------
- RESOLVED: Add three methods to AnimationTrigger interface:
addAnimation, removeAnimation and getAnimations (Issue
#12397: How do AnimationTriggers attach to animations?)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Aug/0004.html
Present:
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
Kurt Catti-Schmidt
Elika Etemad
Mason Freed
Paul Grenier
Hoch Hochkeppel
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
Rune Lillesveen
Eric Meyer
Alan Stearns
Miriam Suzanne
Josh Tumath
Bramus Van Damme
Lea Verou
Regrets:
Rachel Andrew
Yehonatan Daniv
Chris Lilley
Scribe: JoshT
Suggest a better name for the `:interest-target` pseudo class
=============================================================
github: https://github.com/w3c/csswg-drafts/issues/12515
masonf: We resolved to add these pseudo elements a month ago
masonf: poll on the naming. two pseudos
masonf: put the results into a final survey
masonf: results are: :interest-source and :interest-target. the
nearest runner up is :interest-invoker and :interest-invoked
masonf: so propose :interest-source and :interest-target
<TabAtkins> +1
<kbabbitt> +1
fantasai: :interest-source is a cool direction to go in
fantasai: I wish we could come up with a better name for
:interest-target but hard!
astearns: thanks masonf for running polls
masonf: polling feature on GitHub is useful
RESOLVED: use :interest-source and :interest-target
astearns: if someone comes up with a better name for
:interest-target, please open a new issue
CSSOM View
==========
`getClientRects()` should return a flattened list of child rects for
`display: contents`
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12040
florian: if you ask getClientRect on display: content, it returns
nothing
florian: if you return the pieces of it, that would be more useful
florian: this is likely to be a breaking change. are we OK with
breaking compat?
<bkardell> it would be good to answer Oriol's questions in the issue
oriol: I'm not opposing. but was explaining in last comment, not sure
if we should wait for Lea to defend proposal, but I can
explain my reasoning
astearns: is your concern about the way it is to be resolved or the
use case in general?
oriol: there are specific values where they can all be valid and it's
not clear how we would do it regardless of the method. some
authors would want a different behaviour
oriol: like should we include abspos children that are out of flow
oriol: should we include text children. they don't have clientRects
<emilio> +1 oriol
oriol: there is a proposal to support it for pseudo elements. would
they be included?
oriol: in general, I think it seems useful, but a can of worms!
oriol: I think it's better if authors implement exactly what they
want in JS
oriol: if the element has display contents, then I think producing an
empty value is reasonable because it has no box of its own
emilio: +1 to oriol. we already have some APIs for selection that
behave like this
emilio: range.getClientRect is a thing
emilio: that pretty much does what Lea wants I think
emilio: for display: contents, it doesn't produce a box so it should
return empty
emilio: I don't think this would be web compat
lea: what's the alternative proposal, I've just joined
astearns: for authors using JS to work out which children they want
to get the rect for
lea: anchor positioning?
lea: it's been a while, but this came up with certain components that
need to capture native elements
lea: a solution for some things is to wrap a native element
lea: there are two ways to style. either not style the button in the
shadow dom and consumers use custom properties for basic styling
lea: Or to display: contents on the host and then authors can style
the button, for example
lea: authors can apply bg and borders and whatever
<emilio> The alternative is implement what you want. which might be
`let r = new Range(); r.selectNodeContents(thing);
r.getClientRects();`
lea: but makes it difficult to get getClientRect to work to return a
union of the children
lea: that might be more what authors expect
lea: but what happens today if you use anchor pos and you have
getClientRect
emilio: it doesn't work
lea: and it's also defined in terms of client rect. so I'm not
married to fixing getClientRect
lea: but if anchor positioning doesn't work here, that's a broader
problem
TabAtkins: the element wouldn't exist here as far as the layout tree
is concerned
lea: if there was a declarative way to declare which elements make
the box might work. that would help with this use case
emilio: I understand the use case of wrapping a single element and
wanting it to behave as the element
emilio: for that, all these questions have answers
emilio: I don't think we can make this generally work without
answering a lot of really hard questions around chaining
behaviour of these APIs
emilio: maybe the answer is you don't style the component itself and
you style the parts
lea: yeah that's the other alternative
emilio: that's what works now then. but I agree it would be useful
for the specific use case you outlined
lea: this makes it confusing for users using parts. there's certain
things you can't do. now you have to learn a new thing: the
obvious thing doesn't work
lea: this feels like a theoretical purity argument
lea: it doesn't generate a box on its own but the descendants do
lea: but I'm not sure there are any use cases where you would want an
empty rect
emilio: could be places where intersection observers accidentally
fire if we change this
emilio: I understand it would be nice if things were magic and
transparent. but if you have to reach into the shadow dom and
style that then ???
lea: I agree it's weird but the web platform doesn't supply another
way to do this
emilio: maybe we should extend built ins. but that's not related to
display: contents
<bkardell> there is a separate issue on what Emilio just mentioned
astearns: we should take this back to the issue, but should have a
new issue for display: contents on anchor positioning
TabAtkins: maybe we could but I'd like it to be consistent with
something else on the web platform
lea: we could add a dom method that gets you the union of all these
emilio: the range API already exposes this. I don't think it's great,
but it's already exposed
lea: are you suggested this is precedent we could look at or we could
already use range?
emilio: I don't think it would be what you want generally because it
only works on a flat tree, but for most use cases it should
work
emilio: as oriol said, there are many bounding boxes that could work
here
emilio: so I don't see this working in a general way that is useful
enough but maybe that's me
lea: I agree but think anything we do is more useful than the current
situation
astearns: let's take it back to the issue
CSS Grid
========
Subgrid auto repeat calculation when <line-name-list> size isn't a
multiple of remaining subgrid tracks
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8493
fantasai: there was a question of what to do if the subgrid has a
repeat() with multiple line names
fantasai: let's say two line names but the number of lines in subgrid
is odd. do you just cut the last repetition or just the
names don't get assigned for the last section
fantasai: my intent when I wrote the spec was that we only do whole
numbers in repetitions in the repeat functions
fantasai: here the number of lines is set and we just have to give
names
fantasai: if we cut off at the last rep, there are some lines that
don't get names
fantasai: but if we clamp, they all get names
fantasai: that seems more reasonable than cutting up the last
repetition
Kurt: was going to distinguish between whether subgrid span size is
large enough for a single repeat
Kurt: but I see that's generalized to fantasai's case for splitting
the remainder
Kurt: that was my question. i think it's the same problem
Kurt: but my concern with changing this is: is it safe to change at
this point?
Kurt: subgrid is shipped. are we OK changing how auto-repeat changes
in these scenarios?
TabAtkins: I do not think we should change behaviour
TabAtkins: if you have several repeated lines, you are probably
depending on them as a block
TabAtkins: and putting things next to those lines. so if you have
partial repetition, your layout will be broken
TabAtkins: they'll be too short or ???, etc
TabAtkins: in normal grid, we don't allow partial repetitions to
prevent accidentally getting a partial bit of something
the author intended to be a unit
TabAtkins: so like here if you're just defining line names
TabAtkins: if there was a great reason to diverge, we should be
self-consistent when we can. so I think the argument here
is to be consistent anyway
oriol: I agree with TabAtkins about consistency argument
oriol: I had idea in issue. maybe partial keyword to provide to
repeat function to opt into this behaviour
<kizu> +1 to `partial` keyword, including in regular grids as well
fantasai: I'm OK with it!
astearns: resolution for this issue is to keep the subgrid autorepeat
consistent with the grid autorepeat, but make a new issue
for the partial keyword in the repeat function if we find a
use case for it
astearns: is there any spec change for this issue needed?
fantasai: seems like there should be some clarification
TabAtkins: this was raised on the assumption that something is
missing in the spec
RESOLVED: define that subgrid repeat works exactly the same as grid
repeat
Kurt: that resolves things
CSS Anchor Positioning
======================
Add a new container-type `anchored` for querying anchored elements
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12390
futhark: before the summer, I presented what fallback is chosen for
anchor pos
futhark: there are two issues connected:
futhark: to propose to add a new container type anchored to the
container type property
futhark: that can be used in combination with other container types
futhark: have discussed in the issue which containments are necessary
and size containment isn't
futhark: can affect characters in flow in ??? and you could get a
cycle
futhark: I proposed that we add an anchored container type that
implies styled containment
fantasai: is there a reason not to make this compat with style
containment
fantasai: either reusing it or having it compute to style containment
futhark: this is the same as what we do with inline-size etc.
fantasai: from what I can see, this is the same as style containment
futhark: you could combine with contain property
futhark: so this is already how other container types work
futhark: the contain property and the ??? container type is combined
fantasai: I don't understand what is the difference between
container-type and contain again
futhark: it tests which type is a candidate for containment. you
can't do that with the contain property
fantasai: is there a reason to limit this?
TabAtkins: container-type is in the container queries spec. and the
other is in the containment spec
TabAtkins: container-type is for container queries. and certain
values imply certain contain values
miriam: IIUC, this doesn't affect anchor pos and try blocks and
anything else. this would only apply if you want to query the
container and change some aspect of it
futhark: Correct
astearns: what would the proposed resolution be?
futhark: last time, suggested that this should be added to lvl 2 of
anchor pos spec
futhark: so create the spec and add it to the container-type property
futhark: with style containment
PROPOSED: create level 2 diff spec for anchor pos and define an
anchor keyword for container-type there
astearns: should the keyword be anchor, not anchored?
TabAtkins: need to distinguish the two states
RESOLVED: create level 2 diff spec for anchor pos and define an
anchored keyword for container-type there
Add a `fallback` feature for querying applied fallback for
anchored elements
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12391
futhark: the next thing is to add something to query about these
anchored elements
futhark: query the fallback position of the anchored element
futhark: to add a new anchored() function to the container root
futhark: a single feature for now to query the fallback position used
by the anchored element
futhark: this fallback position is matching either the name from the
fallback being applied or the position area
futhark: set by the position try fallback
futhark: the position area will match not the keyword but on the
physical position, so you can use logical values to match
fantasai: overall seems reasonable. sad it has to be a container
query rather than query on the item itself
futhark: the thing on the element itself is already limited to
certain properties for anchored elements already, for the
fallback styling
kizu: only question about position area
kizu: should it match exactly or match partially
kizu: say you position stuff to the bottom, but it could be
bottom-right, bottom-center
kizu: could you query this 'somewhere on the bottom' without the
exact area
futhark: my proposal was to match exactly but that could make sense
to have a syntax for matching some area
futhark: I'm not sure what the syntax would look like
fantasai: we discussed this when designing the matching syntax as a
thought experiment at apple
fantasai: I remember a matching syntax to query ???. I'll see if I
can find anything
fantasai: yeah we allow the keyword 'any' in some places
futhark: so you could say span left or something?
<kizu> I like `any`
fantasai: span-left any. and it would be either left-top,
left-bottom, etc.
astearns: should we decide on that today or give more time for
thought?
futhark: we could resolve on what I've proposed today and create an
issue to add 'any'
miriam: this might also belong in a separate issue, but wondering if
there's other cases where we have container query syntax in a
if function
miriam: does this have if function uses?
TabAtkins: no because this has to be on the container. can't query on
the element itself for bad cyclic reasons
miriam: OK
PROPOSED: add anchor query function that can take fallbacks as params
futhark: it includes having a fallback container feature, not a
fallback value directly
PROPOSED: define a fallback container feature used in the anchor
query function
PROPOSED: define a fallback container feature used in the anchored
query function
RESOLVED: define a fallback container feature used in the anchored
query function
astearns: who will open issue about any keyword?
futhark: can unless fantasai wants to
astearns: please do!
CSS Animations
==============
How do AnimationTriggers attach to animations?
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12397
DavidA: this is related to animation triggers
DavidA: simple naming issue. we just want to define a few functions
on animation trigger object
DavidA: functions defined in web animations spec
DavidA: addAnimation which attaches the animation to the trigger
DavidA: removeAnimation to remove
DavidA: and getAnimations
astearns: suggestions for just add and remove instead of
addAnimation, etc. but Rob is not happy with that but he's
not on the call
fantasai: seems reasonable to me. question about do you want to add
the animations to the trigger or trigger to the animations?
DavidA: we started the other way around, when still thinking of
triggers as an internal part of an animation
DavidA: but we think it should be outside.
DavidA: as a function to add the animation to the trigger
DavidA: I don't think there's much of a conceptual difference
DavidA: we could add an animation triggers interface
DavidA: but for now, it's useful to expand the animation trigger
interface as an independent thing that can attach animations
fantasai: I have no opinion. just checking.
DavidA: in Rob's comment before, he suggested
AnimationTrigger.animations.add interface
DavidA: it does have some logic that goes with it where you attach
the animation to a trigger
DavidA: but you can pause the animation trigger to be in affect
before the animation starts to play
DavidA: if we just have AnimationTrigger.animations.set interface,
that's just a generic set interface
DavidA: we don't have a way to implement the logic for all the
animations it should have if we just have an add method
<bramus> +1 to adding the two methods
astearns: the smallest first step would be to add the new methods
addAnimation and removeAnimation for now
DavidA: bramus thought about having getAnimations as well
<bramus> and +1 to the extra getAnimations as well :)
PROPOSED: add three methods to AnimationTrigger interface:
addAnimation, removeAnimation and getAnimations
RESOLVED: add three methods to AnimationTrigger interface:
addAnimation, removeAnimation and getAnimations
Received on Wednesday, 13 August 2025 23:04:46 UTC