- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 9 Oct 2025 19:14:28 -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.
=========================================
Web Animations/CSS Animations
-----------------------------
- RESOLVED: Accept the keywords from
https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3377529486
(Issue #12611: Set of actions for animation triggers)
CSSOM View
----------
- RESOLVED: Make offsetParent spec match reality (Issue #12392:
offsetParent spec says that we return elements from open
shadow trees, no browser does)
CSS Pseudo
----------
- The discussion around issue #12436 (Combinator to get from
`interestfor` invoker to its target) pointed toward the issue
needing a general solution, not a specific one. Some of it would
be idref(), however there is also a need to spec the invoked
relations as well as the DOM relationship. Discussion will return
to the issue.
- Stopping events wasn't quite the right solution for issue #12437
(Add an `::interest-button` pseudo element to interest invokers)
so masonf will add a new summary to the github issue and
discussion will continue.
Anchor Positioning
------------------
- There was concern about limiting the solution for issue #10258
(Handling popover default styles) to only be when the alignment
is <dialog>. Time ran out on the call to discuss which option was
preferred.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Oct/0005.html
Present:
Rachel Andrew
David Awogbemila
Kevin Babbitt
Oriol Brufau
Kurt Catti-Schmidt
Emilio Cobos Álvarez
Yehonatan Daniv
Robert Flack
Mason Freed
Brian Kardell
Roman Komarov
David Leininger
Rune Lillesveen
Alison Maher
David Marland
Romain Menke
Eric Meyer
Alan Stearns
Bramus Van Damme
Lea Verou
Regrets:
Jonathan Kew
Miriam Suzanne
Josh Tumath
Sebastian Zartner
Scribe: emilio
Scribe's scribe: fantasai
Scheduling
==========
fantasai: I have a request for next week's agenda
fantasai: can we go through anchor pos issues?
astearns: should we have a breakout next week?
fantasai: yeah but we might want to overflow into the meeting
astearns: I'll move the masonry one
fantasai: Tab and I both agree that anchor is more critical right now
astearns: re. winter meeting times, seems like last week of January
is the winning one
astearns: should we decide that?
fantasai: I think it should work out but what would be the second
option
astearns: second of January and [missed]?
fantasai: second week of January is MLK
fantasai: probably will need to skip that
fantasai: probably last of January, will come back
<dbaron> fantasai, I think the second-place week in January is the
week *before* MLK day
Web Animations/CSS Animations
=============================
Set of actions for animation triggers
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3292998336
DavidA: We started talking about this last week
DavidA: about keywords for animation-trigger
DavidA: and what actions the trigger takes on animation
DavidA: there's a list of keywords in the issue, I think we have
agreement on the slightly reduced scope of the set of keywords
DavidA: we want to resolve on the table in the issue
<astearns> this table?
https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3377529486
<fantasai> or this one?
https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3379721618
astearns: there's several
<bramus> The link from astearns is the correct one
DavidA: yeah the last on my comment
fantasai: Is it the same as crissov's comment?
DavidA: yeah no different in semantics
PROPOSAL: Accept the definition in the table
<flackr> +1
<bramus> +1
<kbabbitt> Seems reasonable to me
<ydaniv> +1
astearns: objections?
RESOLVED: Accept the keywords from
https://github.com/w3c/csswg-drafts/issues/12611#issuecomment-3377529486
flackr: I believe both tables are functionally the same
CSSOM View
==========
offsetParent spec says that we return elements from open shadow trees,
no browser does
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12392
flackr: As I was implementing scrollParent I discovered that the spec
for offsetParent claims we should expose elements within open
shadow trees yet no impl does that
flackr: I'd like to resolve to change it to match implementations and
do the same for scrollParent
lea: is there a reason for what browsers do?
emilio: implementation-wise it's the same, but I don't think any DOM
API distinguishes between both
emilio: DOM event targeting etc. works the same in open vs closed
shadow root
<masonf> +1
emilio: So I think it's best to not differentiate here either
emilio: for APIs where you might want to get things from shadow
roots, we've added option to pass shadow roots to have
access to
emilio: that way you can access both closed and open shadow roots
depending on what you have access to
lea: what do they actually return?
lea: do they return the host or do they skip that element?
flackr: they skip to the shadow host but it might traverse further up
if the shadow host doesn't meet the requirements
lea: the current behavior seems more useful, but I also understand
the web compat argument of speccing what browsers already do
lea: wondering if we could also add a corresponding property that
does the right thing
emilio: Could add an argument to do it consistently in the DOM, but I
don't think it should be specific to offsetParent APIs
<flackr> +1
oriol: I think scrollParent should be a function to allow eventual
extensions?
<lea> +1 oriol
dbaron: I think we should be looking at offset* as a legacy API
dbaron: I think the implementation of these existed well before the
spec did
dbaron: in general we want to bias towards specifying what's
implemented
dbaron: to some degree we have various APIs that are trying to
replace them
dbaron: some of that is implemented like getBoundingClientRect and
other pieces in the geometry spec?
dbaron: not sure what the state of all of them are?
<masonf> examples: innerHTML --> getHTML(), getRangeAt() -->
getComposedRanges(), etc.
dbaron: I would not try and improve offset*
dbaron: I'd try and build the API we want more generally
lea: I agree these are weird and fine to treat them as legacy
lea: but not sure what'd be the replacement
lea: is there an API that could replace them today?
<lea> many scripts were written before shadows were a thing and use
these properties for positioning and ideally should not break
too badly when dropped into a page that has shadow roots
emilio: Yes these things were implemented before being specced, but
shadow root came after the spec
emilio: The consistent thing to do is to not distinguish between open
and closed shadow roots
emilio: We can decide to use a function for scoped parent or add a
new function for passing list of shadow roots or whatever
emilio: but big +1 to spec what's implemented for offsetParent
because it's the right thing to do
emilio: consistent with the way it works elsewhere in DOM
<Kurt> +1 emilio
masonf: I commented with some precedent on the DOM side (innerHTML /
getHTML() / etc)
masonf: not a technical issue, just a consistency argument
lea: Fine to spec what's implemented, but we should work to close the
gap because there's no way of doing what the spec says
dbaron: yeah it'd be good to have some element-to-element coord space
conversion
PROPOSED: Fix offsetParent by spec-ing reality, but work into a way
to opt into looking into shadow roots
<kbabbitt> +1
<lea> (though hopefully anchor positioning renders many of the use
cases for these properties obsolete)
<masonf> +1
<lea> +1
emilio: We should definitely update offsetParent.
emilio: scrollParent is not implemented anywhere, so maybe we can
make it functional already
<oriol> It's implemented in Blink and Servo
flackr: We have an implementation, but not shipped yet
emilio: fair
RESOLVED: Make offsetParent spec match reality
<dbaron> I think some of what I'm thinking of was for a time in a
GeometryUtils interface in
https://drafts.fxtf.org/geometry/#geometryutils
astearns: if we make scrollParent a function we can allow passing a
list of shadow roots
flackr: I see
astearns: we should file an issue for that
astearns: we should look into whether appropriate replacements for
offsetParent exist
ACTION: flackr to open issue on making scrollParent a function
<RRSAgent> records action 1
ACTION: dbaron to open an issue on replacements for offsetParent
<RRSAgent> records action 2
CSS Pseudo
==========
Combinator to get from `interestfor` invoker to its target
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12436
lea: This is about introducing a combinator with slash syntax like
`/interestfor/` to go from invoker to its target
lea: a combinator allows `:has()` to do the opposite
masonf: there's another issue that you linked to that is more
general (#10970)
masonf: about a combinator that represents an idref
lea: ah yeah it could be argued that this is an special case of a
general idref
<lea> https://github.com/w3c/csswg-drafts/issues/10970
lea: there's a discussion about `<label for>` etc
lea: then it could be argue that this could be generalized even more
lea: but idref seems reasonable
lea: we have so many of them
<lea> and this is the even more general issue (which I think might be
_too_ general): https://github.com/w3c/csswg-drafts/issues/12446
<lea> to emilio: As mentioned in the issue, it would be functional,
e.g. `label /idref(for)/ input`
emilio: does idref() take a list of hardcoded attributes or so?
emilio: anyways wanted to say that this is more complicated than it
looks like because invalidation becomes quite hard
emilio: also there's another layer of complexity due to shadow DOM
and all the things people are actively trying to do to fix
idrefs and shadow trees
emilio: so I wanted to be a bit cautions about this
emilio: not sure we need the whole generality of combinators
masonf: few things... first there's an spectrum of generality, I
think probably it makes sense to generalize a bit and not
making it specific
masonf: the concrete usecase we've come across is menus
masonf: popover have a single invoker
masonf: so you'd like to style a menulist differently based on what
invoked it
masonf: so it's not about what points to it but about the thing that
actually invoked it
fantasai: +1 to emilio and masonf
fantasai: for this specific issue WebKit objects to interestfor so we
don't want to see features added for this
lea: Multiple things
lea: to emilio, combinators are the CSS mechanism from going from one
element to another
lea: masonf made a good point: which element invoked which is not a
relationship that can be determined by looking at the DOM, and
could warrant a specific combinator (though possibly the same
for all three)
lea: A combinator is the CSS way of going from one element to another
element. We use pseudo-elements only for parts of elements, or
encapsulated elements, neither of which are the case here.
lea: The question, as I understand it, isn't whether it should be a
combinator, but whether it should be a more general combinator
or hardcoded to interestfor
lea: A generic combinator also supports custom element attributes,
whereas a hardcoded one does not.
<fantasai> +1 to the point about the purpose of combinators vs
pseudo-elements
lea: And how does a hardcoded one work? Is it keyed on specific
elements or attr name? idref() sidesteps all that
lea: Re: complexity, I wonder if we could ship it with a whitelist of
attributes at first and expand later, rather than adding ad hoc
combinators
futhark: Agree with emilio, a bit surprised that it was a combinator,
this is quite similar to `:has()`
futhark: you could argue that `:has` could've been a combinator
futhark: is it expected that you want to then continue to other
combinators for that element?
masonf: don't know
masonf: only recently came up with the menu use case
futhark: I think of combinators as walking the tree and if you can
walk arbitrary elements in the tree and then continue
selector matching it gets complicated
fantasai: for some of these things it's not that there's an
attribute, there's other way of creating the association
fantasai: e.g. passing an option to showDialog, so it's not just
about the attribute
fantasai: so I think we do need something custom so that we create
the association
fantasai: so it works regardless of how you create the association
(nesting inside <label>, imperative API...)
fantasai: so I don't think idref() is what we want here
fantasai: we need to look at the different associations
<masonf> perhaps ::invokedby(selector)
<fantasai> masonf, that would be a pseudo-class but yeah that could
work
<lea> +1 fantasai, this does seem to go beyond idref. Though idref
could still be useful for "can invoke", which is a distinct
relationship to "has invoked"
astearns: so wanted to close the issue and discuss in idref() but we
don't have an issue for the non-idref-based bits
masonf: maybe we can repurpose this issue
lea: this does seem to go beyond idref. Though idref could still be
useful for "can invoke", which is a distinct relationship to
"has invoked"
lea: I think there's value in spec-ing the DOM relationship and the
invoked relationship. The former could be idref()
<masonf> +1
astearns: I think we have useful input, so we should take it back to
the issues
Add an `::interest-button` pseudo element to interest invokers
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12437
masonf: this is about a pseudo named TBD that can be used to show
interest by tapping on it
masonf: typical use case would be to show this on touchscreens
masonf: we've talked about other things but the open question is
about what to do about pointer events and other events
masonf: there's a footgun if the click event bubbles to the main
element
masonf: there is some precedent about events not bubbling in some
sub-elements / pseudos
masonf: question is is this fine to do, does it also work for
mousemove etc and also whether this is a more general
feature
masonf: personally the last one scares me a bit
masonf: seems very footgunny
masonf: personal preference would be do the right thing, don't
propagate any discrete mouse events, and propagate move
masonf: if there's a need to do that you can use the interest events
flackr: why is that the right thing?
flackr: usually if you made your own dialog events would still bubble
masonf: it's true
masonf: right now it's hard to disambiguate what the click hit
masonf: maybe there's an API expansion for that
flackr: more worried about events going into a black hole over
particular content
flackr: specially given lots of people do event delegation
masonf: part of the problem is that you forget this is on touchscreens
flackr: I could see an argument to prevent the default behavior
perhaps?
emilio: First, I agree that it's not the right thing to do
emilio: as Olli commented in the issue
emilio: wrt [missed] can you programmatically build this?
emilio: can we expose a way to programmatically show interest?
emilio: It's a bit of letting authors experiment with this pattern
before committing to this pseudo-element
emilio: There's lots of UI that you could use for this, and I'm not
sure that a pseudo-element is covering them all
<fantasai> +1
emilio: regarding events, I agree wouldn't want to special-case them
emilio: maybe preventDefault, like an author would do
masonf: there's current no imperative API like showInterest() but
it's a good idea
lea: We are discussing event propagation and other specifics for this
new pseudo-element, does that mean we have a resolution to add
the pseudo-element and what remains is the details? Apologies if
I missed it, but I didn’t see it in the issue?
lea: in ::picker-icon, the icon is there anyway, so the
pseudo-element lets us target that. However, this is about
*generating* the icon, if I understand it correctly.
<astearns> generating the button
lea: Looking at the code snippets, this looks very similar to how
::before/::after are used. What does this provide that is
different?
masonf: the special thing is the connection with interest invokers
masonf: so that it shows interest on the originating element
lea: doesn't that do the same on ::before and ::after?
masonf: right, if a link has ::before and you click then you navigate
rather than show interest
lea: I see so this is something you can tap and you get the interest
lea: like the parent could do something else like a command
dbaron: or put it in another way it's kind of like a button for
hovering the element
lea: does it actually trigger hover?
masonf: no
masonf: I think that's a separate thing
astearns: we should likely determine what we're going to do with
events and pseudos generally before adding a version of it
<lea> +1 astearns
flackr: sounds analogous like if you had a button-within-a-button
flackr: you wouldn't want the outer button to trigger
flackr: maybe we can do that in a way that isn't preventing the
propagation
flackr: maybe there's precedent somewhere?
<emilio> +1
<lea> Indeed, that seems to be a broader issue, use cases abound for
buttons within interactive controls (summaries, radio labels
etc)
masonf: I haven't investigated that, good question
astearns: so back to the issue?
masonf: I think I heard general feedback that stopping events isn't
quite the right thing, let me summarize it and go back to the
issue
Anchor Position
===============
Handling popover default styles
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10258#issuecomment-3374397145
fantasai: issue is that popover UA default has `margin: auto` in it
fantasai: margins win over alignment
fantasai: so when you have a popover and you set position-area on it
you put it in the right area but then it gets centered in
that
fantasai: which is not likely what you want
fantasai: this has tripped up a number of people
fantasai: our original idea was to introduce a special alignment value
fantasai: that would center except if you have position-area
fantasai: when I implemented it I noticed that we had a bunch of
tests that would set margin: 0
fantasai: which is likely to come up
fantasai: which means we need another way of doing this
fantasai: I came up with several ideas
fantasai: we could condition them on having the special keyword for
alignment vs. not
fantasai: or if position-area is not none you can't use auto margins
fantasai: I don't particularly want to do this because I think
position-area into the center of an anchor might be
reasonable
fantasai: so it'd be surprising if they don't work
fantasai: so we could say if position-area is not none or center then
disable auto margins, then disable then
fantasai: or span-all too perhaps
fantasai: but the ones on an asymmetric position with the anchor
wouldn't
fantasai: the other thing is that we could do this always or only if
we do the self-alignment legacy value thing
fantasai: in which case it'd be mostly popovers
astearns: Ian likes your first option best
astearns: I'm a bit concerned about the possibility of going this
route only if the alignment is `dialog`
astearns: makes copying styles to something else not work
emilio: similar concern, be weird to have a random abspos that works
and when you put it on popover it doesn't work or vice versa
emilio: so, if we don't want this difference, we don't need this
special keyword, right?
fantasai: yeah, it's only here to solve this problem
emilio: then if we need to special case it for compat, we may as well
not have the special keyword
fantasai: if we're not going to condition it on `dialog` I'd lean
towards #3
fantasai: I think they won't try to use them in the side tracks
fantasai: but span-all and co seems reasonable
<fantasai> ... and would be surprising if it doesn't work
Received on Thursday, 9 October 2025 23:15:00 UTC