- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Jul 2025 19:45:16 -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 Cascade
-----------
- There were no concerns about the resolution on issue #9740 (`&`
matching inside the `@scope`, and its interaction with `:scope`)
from the breakout.
CSS Forms
---------
- RESOLVED: appearance: base-select can be used to opt listbox
selects into base appearance. control of listbox and
multiple rendering will be improved in html (Issue
#12468: Should `appearance: base-select` work on listbox
selects? (`<select size>`/`<select multiple>`))
CSS Color
---------
- Next steps for issue #10372 (Mitigating fingerprinting for
AccentColor/AccentColorText) is to discuss the magnitude of the
fingerprinting concern with security and privacy teams and then
move on to creating draft text.
CSS UI
------
- RESOLVED: when caret is past the end of the line, attempt to show
it even if it overflows. Browser may clip it or
reposition it (Issue #10289: caret-shape: block/
underscore and overflow)
CSS View Transitions
--------------------
- RESOLVED: compute missing content-visibility information as we
iterate the tree while capturing (Issue #10773: Elements
with content-visibility in new Document)
CSS Animations
--------------
- RESOLVED: Add / delimiter to syntax for animation-trigger (Issue
#11948: Add / separator before animation-trigger exit
range)
- There were several concerns raised about the design of the solution
for issue #12336 (Move scroll and event animation triggers to
independent namespace) and so discussion will return to github.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jul/0007.html
Present:
Rachel Andrew
Joey Arhar
Rossen Atanassov
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Brian Kardell
Alexander Kyereboah
Roman Komarov
David Leininger
Alison Maher
Romain Menke
Florian Rivoal
Noam Rosenthal
Miriam Suzanne
Josh Tumath
Lea Verou
Regrets:
Daniel Holbert
Jonathan Kew
Bramus Van Damme
Scribe: kbabbitt
CSS Cascade
===========
`&` matching inside the `@scope`, and its interaction with `:scope`
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9740
miriam: we discussed this in the scope breakout session
miriam: idea is changing exactly what & refers to when directly
inside a scope rule
<TabAtkins> +1 to this resolution, based on reading Miriam's post
summarizing the decision
miriam: goal is to match how & works elsewhere
miriam: thinking about it slightly differently than before
miriam: existing spec says & directly inside scope refers to selector
in scope prelude
miriam: would get its specificity and match any elements that target
that selector
miriam: but that feels different from how & works in other context
miriam: it would match exactly the same things it would match with
bare declarations in that same place
miriam: so adding & doesn't change what's matched and doesn't change
specificity
miriam: proposal here is to say, in order to get that same behavior
in a scope rule, bare declarations match :where scope which
has 0 specificity and only matches single scope root element
miriam: & should do the same thing in that context
miriam: match where scope, maintain 0 specificity, match only scope
root
astearns: you wrote an excellent blog post going through this which
definitely helped me
astearns: questions? concerns?
<bkardell> link?
<TabAtkins> https://css.oddbird.net/scope/parent-selector/
astearns: purpose of bringing this back to agenda is to validate what
we resolved on breakout
astearns: if there are no concerns we'll have resolution stand
<JoshT> +1
<lea> +1 to this
[no concerns raised]
<ydaniv> +1
CSS Forms
=========
Should `appearance: base-select` work on listbox selects? (`<select
size>`/`<select multiple>`)
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12468
lea: recently appearance base-select shipped in chrome for
customizable select
lea: however current impl doesn't do anything for listbox selects
lea: and there's nothing in the spec around this
lea: there's a picker-icon pseudo which theoretically doesn't apply
lea: only mention of listboxes is an unrelated mention around ?
pseudo classes
lea: question is, should appearance: base-select apply to listbox
select
lea: one idea I had is that, even though we have consensus that it
should, I wonder if we introduce a different value for this
lea: we could use the css property to switch between the two modes
lea: right now there's no css way to switch
lea: internal parts and dom are so different between the two modes,
I'm not sure how it would work without such a toggle
lea: pseudo elements are different
lea: from an architectural point of view it was a mistake that the
same element does both
lea: and things that have nothing to do with it are used to switch
between them
lea: most modern UIs implement dropdowns from scratch so they can do
multi select dropdowns
lea: perhaps if we had a separate value it could fix all these
problems at once
lea: so I'm not convinced we should have appearance: base-select
apply to listbox mode
lea: wonder if we should have a separate value
lea: very clear we need a way to style listboxes, not sure if it
should be base-select or a different value
keithamus: my understanding is that popover element that would
provide list of options
keithamus: that can be styled as display:block which would make it
part of page flow
keithamus: then you'd have a listbox style control
keithamus: overlay property would be the one
keithamus: so you can put it as part of page flow rather than as
popover
keithamus: does that satisfy the query?
lea: not sure I understand the proposal
keithamus: your query is between the two modes, and I don't think
they're modes, I think the pseudo elements are the same
but you'd effectively style the dropdown so it would be
part of the page
lea: you'll still have the selected content element
keithamus: you can omit that or display: none it
lea: or we go the opposite way from listbox from dropdown which is
more commonly needed
keithamus: two modes are, picker element is either popover or now
keithamus: and selected content is either displayed or not
lea: downside of that is you need to implement yourselves how
dropdown would look for listbox appearance
lea: you have a listbox and you have to write several css rules to
make it look like a dropdown
keithamus: one point of base-select is ... [missed] ... you'd have
some default styling
keithamus: it should be consistent, whether it would be a matter
of ... I'm curious why we would need to put effort
into .... why an author would need to put effort into
making it look native
<miriam> are we talking about the same thing as 'listbox'? It seems
to me Lea is talking about select multiple, and Keith is
talking about select with datalist?
lea: not saying they want to make it look like listbox widget, saying
they want to make it look like a listbox ... not just a matter
of a single css rule, would take several
lea: when you start form a dropdown, all of the css you have to write
is to style it
lea: when you start from a listbox and want to make it look like a
dropdown, now you have to write a bunch more rules
keithamus: only difference is form control that opens the picker is
the thing that is rendered on the page in a picker mode
keithamus: in a listbox mode, the picker is rendered on the page and
the button thing is not
keithamus: so you're just display:none'ing on the button
keithamus: and setting overlay none on picker
keithamus: overlay auto on picker and display block on button
keithamus: then you can have all your styles separate and they can be
consistent
keithamus: but maybe joey has some better answers here
jarhar: I've been working on an impl of this in Chromium
jarhar: I believe that the different modes about listbox and popup
and single and multiple select should be controlled with
existing html attributes
jarhar: size=1 makes popup, size>1 makes it listbox
jarhar: different modes should be controllable with
appearance:base-select
jarhar: I don't think we need other values for appearance
jarhar: I don't think we need to control multi select or popup
with css
jarhar: it can be done with HTML
jarhar: right now there are some issues like you can't have select
multiple with popup on desktop
jarhar: on mobile you can't get a listbox
jarhar: these are things I'm working on
astearns: jarhar you're saying the answer to the original question in
the issue is, yes it should
astearns: answer to lea's new question is "no"
jarhar: correct
lea: the issue is not whether multipleness should be controlled by css
lea: of course it should be controlled by html
lea: problem is today when you specify multiple in select you always
get a listbox, can't get a dropdown
lea: presumably base-select would get you a styleable dropdown
jarhar: planning on separate change so that size=1 on select ? will
give a popup
lea: regardless of whether you specify base-select? don't know if
that's web compatible
jarhar: correct, will find out if it's web compatible
<fantasai> jarhar++
lea: some data points we're missing for a decision here is how much
code would be needed to make a decision here
lea: would be helpful if keithamus could write snippets in issue to
show what switching would look like
lea: maybe I'm wrong and it's just a couple css rules and it'll be
fine
<JoshT> yes, some example code would be really helpful!
astearns: I think that makes sense, we should take it back to the
issue and go through some example code
astearns: thank you jarhar
lea: could we have a resolution that we want listboxes to be
stylable, with the exact syntax TBD
astearns: [discussing what resolution we could take]
<chrishtr> +1 to going with joey's approach and then reconsidering if
it is found web-incompatible
lea: I'm fine with that
astearns: we often take resolutions hoping something will be web
compatible
astearns: jarhar could you summarize resolution for this issue that
you plan to implement?
<jarhar> proposed resolution: appearance: base-select can be used to
opt listbox selects into base appearance. control of listbox
and multiple rendering will be improved in html
astearns: does that look okay to you lea?
lea: I think so, also concept that size is distinct from whether you
want a listbox or dropdown
lea: how long the dropdown is is a CSS thing but that's secondary
astearns: let's go with proposed resolution for now
astearns: any objections?
<keithamus> +1
fantasai: reason we use base-select here was to allow for progressive
opting in more controls
fantasai: and avoiding compat issues
fantasai: are concerned about that, or are other controls shipping ?
jarhar: I'm personally not concerned about using same keyword
jarhar: but I'm open to suggestions
fantasai: ok we can go with this
<chrishtr> I think it's fine for both to use base-select. We can
reconsider if it is found to be web-incompatible.
RESOLVED: appearance: base-select can be used to opt listbox selects
into base appearance. control of listbox and multiple
rendering will be improved in html
CSS Color
=========
Mitigating fingerprinting for AccentColor/AccentColorText
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10372
kyerebo: I'm Alex, recently taken over implementation of accent-color
in Chromium
kyerebo: summary of issue is: we resolved to add support for accent
color keyword using actual system's accent color
kyerebo: have a blocking privacy concern regarding user's accent color
kyerebo: and what we currently have in spec is that we're leaving up
to UA to mitigate privacy risks by returning fixed values
kyerebo: which don't reflect actual customization or choices made by
user
kyerebo: in Chromium we're considering exposing accent color only in
installed applications
kyerebo: discussion that fingerprinting surface was not significant
enough to warrant complexity
kyerebo: some concern about using in form controls or native keywords
kyerebo: wanted to get some thoughts around whether language in spec
is sufficient
kyerebo: and whether fingerprinting surface is a real concern
jarhar: don't have anything to say about spec text. in terms of
whether this is a real privacy issue, I'd be happy to ask
that question again and bring in chrome security and privacy
people
jarhar: not an expert but that seemed like a concern to me
jarhar: if you have evidence that it's not a big issue please let me
know I'd be happy to help
astearns: other comments or questions?
alisonmaher: how these compare to other system colors - on Windows,
accent color can be customized
alisonmaher: which increases fingerprinting risk
alisonmaher: but other system colors are also customizable
alisonmaher: raises question, do users customize this more than other
system colors?
alisonmaher: but at least on windows, all system colors are
customizable
lea: on OSX, the highlight color is customizable but accent color
isn't
lea: it seems we currently do expose highlight color
lea: so that's introducing more entropy
lea: since it can be customized, so it doesn't seem any worse than
what we have right now
lea: once we implement the resolution that accent color resolves to
value of accent-color property, this becomes less of an issue
lea: because most pages will set accent-color anyway
astearns: whether or not authors set the accent-color, doesn't really
affect the fingerprinting risk
astearns: because someone who is interested in getting more
fingerprint surface won't set accent-color
lea: I was thinking that you would need control over whole page for
that kind of fingerprinting
astearns: maybe we need more info from privacy folks
<lea> (and also once it reflects the value of `accent-color` in
theory extensions or user CSS can override and the page
wouldn't know)
alisonmaher: does the current spec text suffice? leaves it up to UA
to mitigate these risks
alisonmaher: or do we need more specific text here for accent color
and accent color text in general?
astearns: don't know but it seems an interoperable mitigation would
be better
alisonmaher: definitely want interoperable, maybe we need spec text
for that
jarhar: I guess we can follow up with some more security and privacy
discussions outside WG
kyerebo: alisonmaher and I put this on agenda, jarhar is the
resolution here to have further talks on security and
privacy to see if fingerprinting is significant
kyerebo: and get text for interoperable resolution?
jarhar: sure
jarhar: if things are already exposed as mentioned earlier, that can
be used to reexamine how bad fingerprinting is
jarhar: I think that makes sense
astearns: I think that makes sense as well
astearns: get expert opinions, and based on those, are there changes
to spec to say you can return real color
astearns: or here's what you need to do to hide real color,
interoperable either way
astearns: who can take this to privacy people?
alisonmaher: kyerebo and I can figure that out
astearns: anything more?
CSS UI
======
caret-shape: block/underscore and overflow
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10289
florian: the resolution might be just fine but I think we considered
a too narrow question
florian: would like to make sure we still agree when we consider
whole question
florian: this was raised in the context of block and underscore caret
florian: but we need to consider spec for any caret
florian: question was what to do when the caret overflows but we're
assuming in our discussion that the text doesn't
florian: so we wondered what happens if only caret overflows
florian: but this is not necessarily true, text itself might overflow
as well
florian: so we said that when the caret is past the end of the line
we should show it anyway even if it overflows
florian: and there may be some intermediate
florian: but if you think of text which overflows line and caret at
end of text
florian: and whole thing is happening in box with scroll or hidden
overflow
florian: position of caret is outside the box somewhere after the
text you can't see
florian: not just about clipping at this point, may also be about
positioning
florian: for example in firefox, if you have text that's longer than
line, overflowing and hidden
florian: and caret at end of that
florian: caret is shown at visible end of line, not where text ends
florian: and other browsers, in that situation, caret isn't shown
at all
florian: not showing it at all is a kind of clipping, and we might
say we want to clip
florian: but firefox does more than clipping, it repositions caret to
where you can see it
florian: I think the general idea is you should show caret, you might
need to clip, is reasonable, but you might need to do more
than clip and reposition to make it visible
florian: I suspect we want to keep this ? for now at least, though if
we want to insist you have to show it, I don't mind
florian: I think we should not ban firefox behavior at least
schenney: support the view of not banning it
schenney: from my perspective firefox's ui gives some sign that
editing is happening
schenney: that's a choice, chrome chooses not to, that's a choice
schenney: agree this should be open to browser interpretation
Rossen: I like the approach of starting with a "may" and requiring
more strictly later
Rossen: for interop
florian: Proposal: when caret is past the end of the line, attempt to
show it even if it overflows. Browser may clip it or
reposition it
Rossen: additional feedback or objections?
RESOLVED: when caret is past the end of the line, attempt to show it
even if it overflows. Browser may clip it or reposition it
CSS View Transitions
====================
Elements with content-visibility in new Document
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10773
noamr: this is a lifecycle issue with view transitions
noamr: don't capture view-transition if it's not relevant to user
noamr: away from viewport, content-visibility auto
noamr: issue with cross document view-transition
noamr: might not know yet if an element is close to viewport or not
noamr: also if element were added between starting view-transition
and activating it
noamr: original idea was to play around with order in rendering
lifecycle but that caused issues
noamr: proposal on issue now is that when we go through the tree of
elements to see what needs to be captured
noamr: if we didn't compute content-visibility for an element, then
we do
noamr: view-transition algorithm iterates over all elements anyway
noamr: to find capture
noamr: so if it finds an element that's new and we don't know if it's
captured
noamr: compute what we need for it at that point
noamr: wouldn't change behavior in chromium, would probably fix a bug
in firefox
Rossen: any feedback?
Rossen: all for fixing bugs, not hearing anyone from gecko side
express concerns
noamr: Proposed: compute missing content-visibility information as we
iterate the tree while capturing
Rossen: objections?
RESOLVED: compute missing content-visibility information as we
iterate the tree while capturing
CSS Animations
==============
Add / separator before animation-trigger exit range
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11948
ydaniv: context: talking about animation behaviors
ydaniv: more specifically scroll triggered animations
ydaniv: what we have is animation that triggered when an element
enters view and it has a view timeline
ydaniv: and specified range
ydaniv: set the actual active range, when that range is entered,
animation is triggered based on behavior of trigger
ydaniv: if that behavior is set to repeat, then when the active range
is exited, the behavior is to reset the animation
ydaniv: that can create visual jank
ydaniv: as we exit range, after user entered default range, then
range can be expanded to exit range
ydaniv: can be specified by developer
ydaniv: in order to increase range where element needs to exit
ydaniv: then the author can avoid this visual jank
ydaniv: this is why you have a default and an exit range
ydaniv: because these are two values that are the same syntax
ydaniv: and you have several ways of specifying them
ydaniv: for example one value, two values, three values, four values
ydaniv: it can be ambiguous whether you wanted to specify exit range,
or use one value for entry and one for exit
ydaniv: proposal is to add / delimiter
Rossen: any feedback?
<TabAtkins> +1 to the /, I think
<fantasai> +1
<flackr> +1
flackr: seems reasonable
Proposal: Add / delimiter to syntax for animation-trigger
Rossen: objections?
RESOLVED: Add / delimiter to syntax for animation-trigger
Move scroll and event animation triggers to independent namespace
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12336
DavidA: on the topic of animation triggers
DavidA: as mentioned for scroll based triggers we have a list of
properties that authors can use to specify conditions
DavidA: under which triggering happens
DavidA: some work is also being done on different kind of triggers
DavidA: based on events
DavidA: we're considering that not all properties that apply to
scroll based triggers apply to event based triggers and
vice-versa
DavidA: we're considering change to format of properties we have in
spec currently
DavidA: currently we have one animation-trigger shorthand
DavidA: that specifies set of additional longhands
DavidA: they're all done targeting scroll based triggers
DavidA: now that we're considering different type of triggers, we
should have a different format where animation trigger
property specifies name of trigger
DavidA: then different property, in case of scroll based trigger, or
timeline trigger
DavidA: add name for that trigger and animation-trigger property can
refer to that dashed ident
DavidA: similar construction for event based triggers
DavidA: where event property could be event-trigger or something
DavidA: specify event that should trigger the animation
DavidA: and a name
DavidA: then animation-trigger property can refer to that
dashed-ident name
DavidA: proposal is to have different namespaces for different types
of triggers
flackr: this follows the pattern we have for scroll timeline and view
timeline where options for those timelines are not
animation-* properties
flackr: you set up timeline separately and attach to animation
flackr: this nicely lets us have different sets of properties for
different types of triggers
ydaniv: have a strong concern here
ydaniv: main one is that triggers are not directly associated with
elements
ydaniv: triggers are just objects that contain state
ydaniv: information about behavior
ydaniv: then they form a link between animation and another timeline
ydaniv: link to an element or an event
ydaniv: themselves they're not directly related to an element
ydaniv: I think this design is problematic and adds another namespace
ydaniv: for example if you have one element specify animation,
another specify timeline
ydaniv: another specify trigger
ydaniv: but it's not necessarily the ? element
flackr: like scroll and view timelines
flackr: we can add an element ? trigger construction
flackr: where we use a simple set of parameters
flackr: I think that scoping some named things commonly done in a lot
of locations
flackr: even if it's not strictly associated with element
flackr: but also by having the trigger be able to be defined on a
different element
flackr: there's more situations where you wouldn't ? timeline for
that trigger
flackr: [missed]
flackr: have strong concerns about not doing this
flackr: more situation where you wouldn't need a named scroll
timeline or view timeline
flackr: because you could set up trigger on the element
flackr: that you would normally have put the timeline on
flackr: we would be introducing a bunch of animation associated
properties
flackr: for things which most of the time would have no meaning
flackr: for that animation unless you happen to have specific type of
trigger to which those properties apply
fantasai: having a hard time following this conversation because I'm
missing context of overall proposal
<TabAtkins> same as fantasai
fantasai: not here or in spec
fantasai: can we link to spec and get it properly published?
fantasai: don't know where change is happening
fantasai: because it's not in ED
fantasai: is there no draft spec?
flackr: this is animations 2
flackr: ED of animations-2
fantasai: ok
<flackr> https://drafts.csswg.org/css-animations-2/#animation-triggers
ydaniv: re: flackr - regarding concerns, we already have all these
properties
ydaniv: even if we do this, animation-trigger still remains
ydaniv: will also contain list of properties
ydaniv: thing also that flackr said, people can use anonymous timeline
ydaniv: that's true, could simplify most cases
ydaniv: but still there's an option we want to have timeline used on
specific elements, give it a name, you still have to use yet
another element
ydaniv: which is I think, creates more complex API
ydaniv: for the author
<flackr> animation-trigger: timeline-trigger(view()) could work for
example
DavidA: don't have to use another element
ydaniv: second point was that, if we do want to put view-timeline
property and give it a name on an element
ydaniv: still need another element in between for another property to
reference that name
ydaniv: and make it a reference to declaration of trigger
ydaniv: still need this extra property
ydaniv: this makes the API a bit cumbersome
ydaniv: that's my concern
Rossen: with the number of concerns you're raising here, clarity
needed for others, to move this forward I think we need to
move this back to github issue
ydaniv: I think if more people could chime in and give opinions ...
could be just design issue
Rossen: design of feature is most important part
Rossen: let's move topic and discussion back to github
Rossen: when you're ready for resolution, put it back on agenda
Received on Wednesday, 16 July 2025 23:45:50 UTC