- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 18 Sep 2025 19:51:11 -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 Environment Variables
-------------------------
- RESOLVED: Drop the fullscreen-* vars (Issue #11899: Add environment
variables defined in WebKit)
- RESOLVED: Publish FPWD css-env-1
CSS UI
------
- RESOLVED: Add !important to UA stylesheet rule for the inert
attribute (Issue #12049: The interactivity property
should not be included in the all shorthand)
CSS Pseudo
----------
- RESOLVED: Add element.pseudoAll that returns a list of
CSSPseudoElement (Issue #12162: Add a property to
retrieve plural instances of pseudo elements with the
same selector)
CSS Forms
---------
- RESOLVED: Go with ::clear-icon and ::reveal-icon (Issue #11845:
Password visibility toggle)
CSS Backgrounds
---------------
- Several folks gave an overview of issue #12132 (Using logical
keywords in background-position shorthand with multiple
backgrounds) and, in discussing details, realized that creating a
through write up would help further discussions and focus around
the various considerations necessary.
CSS Flexbox
-----------
- RESOLVED: Add a flexbox level 2 with flex balance feature, syntax
TBD (Issue #3070: Add flex-wrap: balance;)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0008.html
Present:
Jake Archibald
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Andreu Botella
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
Chris Harrelson
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
David Leininger
Alison Maher
Romain Menke
Eric Meyer
Tim Nguyen
Florian Rivoal
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Luke Warlow
Sam Weinig
Sebastian Zartner
Regrets:
Emilio Cobos Álvarez
Josh Tumath
Lea Verou
Scribe: kbabbitt
CSS Environment Variables
=========================
Add environment variables defined in WebKit
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11899
SebastianZ: we wanted to publish fpwd of css-env-1
SebastianZ: we had 1 issue that is blocking publication which is
deciding whether to add the variables defined in webkkit
to the spec or not
bramus: on the thread we looked into these env vars
bramus: smfr mentioned that they were introduced back in the day but
they are not aware of any sites that have adopted
bramus: I ran a query on httparchive to be sure
bramus: checking for env(fullscreen-*) in width height etc.
bramus: result came back with 0 sites out of 16 million+ had it in CSS
bramus: which is quite reassuring
bramus: smfr also mentioned they are open to renaming or unshipping
these properties
bramus: given 0 sites matched, I think unshipping is the answer
bramus: so not add to css-env spec
Rossen: seems like a reasonable proposal
ntim: I think it's reasonable
ntim: even if there are some use cases for this env var we probably
want to rename anyway
ntim: for now removing it is the right call
<kbabbitt> +1
Rossen: let's try to resolve
Rossen: any objections to dropping this list of env vars that are
webkit specific from the spec?
<emeyer> +1
PROPOSED: drop the fullscreen-* vars
RESOLVED: drop the fullscreen-* vars
Rossen: SebastianZ do you have a resolution to republish?
SebastianZ: It would be republish or publish, don't remember if we
have one
Rossen: any objection to publishing?
SebastianZ: this would be level 1
Rossen: FPWD of css-env-1
Rossen: since this is first public I'd like to have attention and
make sure we're ready to publish
fantasai: as long as TabAtkins has reviewed and think it's complete,
it's fine
TabAtkins: yes I think we should go for it
Rossen: objections?
RESOLVED: publish FPWD css-env-1
<bramus> Yay!
CSS UI
======
The interactivity property should not be included in the all shorthand
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12049
masonf: just read it over and added a comment, question is about
whether `interactivity` should be included in `all`
masonf: there was breakage in chrome related to inert attribute being
reset by `all:initial`
masonf: best fix seems to be making that UA stylesheet rule !important
masonf: and putting interactivity back into all
masonf: should fix bug and keep important behaviors
flackr: we used to allow un-inerting subtrees that were interactivity
inert
flackr: which is I think why this was problematic
flackr: but now that we don't is the problem that it's on same
element?
masonf: yes that's the problem
masonf: afaict the only problematic case is when inert attribute is
on an element and on same element you do all:initial
masonf: you probably want inert attribute to win
masonf: I think adding !important does exactly that
<flackr> sounds reasonable
lwarlow: just to double check does this have any impact on modal
dialogs?
lwarlow: that was the other case where interactivity came up
lwarlow: wasn't clear to me what solution was
masonf: 2 ways it can impact modal dialogs
masonf: direct way should not be affected, modals should stay
uninerted with rest of page inerted regardless of all property
masonf: reason UA stylesheet has a modal rule that sets interactivity
auto, corner case
masonf: it will automatically have that behavior but if author wants
to make entire page inert, they have to contend with CSS
rules about setting [missed]
masonf: other than that corner case, modal dialog inertness should
just work
lwarlow: makes sense
masonf: and there's a way around it if they want to do that weird
thing
masonf: everything I've said is my speculation about behaviors, if we
go this route we will probably want to test it out
Rossen: have you?
masonf: no
Rossen: any other feedback or suggestions?
masonf: Proposal is to add !important to UA stylesheet rule for the
inert attribute
<lwarlow> +1
<flackr> +1
Rossen: objections?
<dbaron> +1
RESOLVED: add !important to UA stylesheet rule for the inert attribute
CSS Pseudo
==========
Add a property to retrieve plural instances of pseudo elements with
the same selector
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12162
flackr: proposal is to extend what we have in CSS pseudo to allow
retrieving the pseudo elements that have multiple instances
flackr: if a browser does implement CSS pseudos, this is probably a
good thing to do because we have many pseudos that can be
matched with generic selectors
flackr: I agree with the proposal that it should behave a lot like
querySelectorAll
TabAtkins: also agree with use case and proposed ordering behavior
flackr suggested in the issue
<kbabbitt> seems reasonable to me as well
fantasai: 3 different proposals, which one?
flackr: element.pseudo is already in the css-pseudo-4 spec
flackr: proposal would be to add a method that gets all pseudos
flackr: first one I believe, something qSA-like
flackr: that returns all matching pseudos
TabAtkins: yes, the one listed under the Recommendation heading
flackr: open to bikeshedding
fantasai: okay with this
fantasai: for element.pseudo would that return first?
flackr: yes
TabAtkins: yes, same as qS vs qSA
TabAtkins: for bikeshedding purposes we should make it pseudoAll? not
most grammatical but parallel naming is important
Rossen: actually it's not bad
<ydaniv> +1
flackr: seems reasonable
<JakeA> Also things like `matchAll` exist
<TabAtkins> true!
Rossen: any other suggestions?
Rossen: Proposal is to add element.pseudoAll that returns a list of
nodes
Rossen: objections?
<JakeA> List of `CSSPseudoElement`
flackr: yes, not list of nodes, list of CSSPseudoElement
RESOLVED: add element.pseudoAll that returns a list of
CSSPseudoElement
ntim: I think element.pseudo was resolved on different issue
Rossen: if you feel we need to discuss more, bring up that other
issue or open a new one
<flackr> +1 we'll keep the names in sync
CSS Forms
=========
scribe: TabAtkins
Password visibility toggle
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/11845
kbabbitt: in April we resolved to add a pseudo-element for password
visibility toggle on input type=password
kbabbitt: left name to be bikeshedded
kbabbitt: have been some discussion in the issue, especially about
naming form control pseudos in general
kbabbitt: as a general principle, use the word "icon" to indicate
graphical indicators, "button" to indicate clickable
kbabbitt: from that, suggests we call it ::reveal-button
kbabbitt: and as an additional proposal, should rename the other
Forms 1 pseudos to be consistent with this pattern
<lwarlow> +1
<TabAtkins> +1
fantasai: things get a little ambiguous with, sya, ::picker-icon,
which is both clickable and an icon
fantasai: do we really want to be so clear about which is a button
and which is an icon in our naming?
kbabbitt: I think there is some inconsistency in the naming, yes in
some cases the picker would be a button in others it's an
icon...
fantasai: I think that would be confusing for authors, yeah. should
be consistent
fantasai: but that brings up whether we want to be so explicit in the
names, or if we do want to lean into being ambiguous about
whether it's an indicator or button
kbabbitt: personally I'd lean toward consistency when possible
lwarlow: I've been thinking about this for a bit, think I mentioned
the step-up/down buttons
lwarlow: ideally something that's a button we'd call a button, I think
lwarlow: there are some weird cases tho
lwarlow: in a select element the picker icon is an icon, it's not
actually a button. it's not really clickable, the select
itself is what's clickable. so picker-icon makes sense there
lwarlow: but in a date input, the picker would be an actual button;
you can click on the element but only the button actually
summons the picker
lwarlow: file-selector is the other case - it looks like a button,
acts like one. but really the whole element is clickable. so
arguably that's not a "button" either....
lwarlow: agree that making authors write ::picker-icon sometimes and
::picker-button sometimes isn't ideal
lwarlow: but for new names, I do recommend having button in the name
if it's a button
fantasai: for date picker, it depends on the platform, some pop it
when you click anywhere
fantasai: so there's some ambiguity on whether it's an icon or button
<lwarlow> We'd probably want to specify that though ideally?
fantasai: we have things that act differently between controls, and
things that act differently on a single control depending
on time or platform
fantasai: so that raises the question - if these aren't really two
distinct categories, should we even lean into categorizing
everything, or lean away and not categorize them?
masonf: was gonna say a lot of that too
masonf: agree it's very ambiguous
masonf: picker-icon was chosen because it was indeed not a button
(the whole control is)
masonf: so I'd lean towards using -icon for everything because
whether it's a button or not is ambiguous, but it's always an
icon in some way
ntim: I lean toward simplicity, like ::step-up (no suffix)
ntim: but in this case I think simplicity would be using the -icon
suffix everywhere
ntim: making the distinction is really hard, yeah
ydaniv: from what I know in UIs, button is something you activate
with a click/keypress, and icon is activated by hover/focus,
so I lean towards button
lwarlow: wanted to push back on "it's always an icon", not sure
that's always true
lwarlow: file-selector-button is actually a button, not an icon.
step-up/down can be arguable, but they're rendered as a
button. does depend on stylesheet to some extent
lwarlow: I do agree ::reveal should have a suffix, ::reveal on its
own isn't clear enough
lwarlow: it even reads more as a pseudo-class on its own, not right
as a pseudo-element
lwarlow: so I'd be okay with ::reveal-icon if the group likes it. but
I'd be a bit more against ::step-up-icon
<JakeA> `revealer`?
<ntim> I like ::reveal-icon because it also opens the possibility for
other things than just an interactive button
kbabbitt: I just need a name so I can write down a spec, can explore
the more general case in another issue. fine with either
icon or button
<lwarlow> It's not an icon with words though... it's just some text
in all 3 engines.
fantasai: we should focus on the author experience and what they'll
have to memorize, and how we can reduce the memory load. so
staying away from categorizing too much is best
<ntim> +1 to fantasai
<lwarlow> +1 I'd be okay with that
fantasai: for this issue, seems like we might just say ::clear-icon
and ::reveal-icon (and leave the other pseudos alone for
now)
<TabAtkins> +1 for me too
<kbabbitt> +1 I'd be happy with that
<masonf> +1
RESOLVED: Go with ::clear-icon and ::reveal-icon
CSS Backgrounds
===============
Using logical keywords in background-position shorthand with multiple
backgrounds
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12132
weinig: basically this boils down to a discussion about how we should
expose these things
weinig: and whether we need a special wording or special value to
represent the fact that this is a logical property
weinig: in a way that's not usually done
weinig: not sure there's a resolution to be had yet, probably needs
specific spec text proposal
weinig: before there's motion forward
fantasai: I think we need to hash out some specifics
fantasai: would it be useful to introduce people?
TabAtkins: I would find it useful to have a quick summary
Rossen: yes especially if we want to resolve
weinig: problem statement is that we want to add the logical versions
of background-position
weinig: background-position-block, -inline
weinig: because these are list properties, you can wind up in a
position where it's not clear ...
fantasai: the issue is that, in background-position, we have some
logical, some physical, some both ways of specifying
position
fantasai: we also have longhands for background-position
fantasai: x and y, and probably want block and inline longhands
as well
fantasai: mapping these two together ends up requiring some kind of
way of tracking which was specified later in the cascade
fantasai: also requires a way to represent computed value of each of
these things
fantasai: for the first problem, proposal was to add a `defer` keyword
fantasai: the author would usually not use, but implementation would
use to track each individual longhand whether it's setting
something
fantasai: or the other property is setting something
fantasai: if both say defer, resolve to initial value
fantasai: in terms of representing computed value, there's been some
discussion, if you set background-position-inline to
start-edge, what is value of background-position-x and y
fantasai: latter half of discussion is about tracking that
information about which side you're setting from
fantasai: into computed value
fantasai: and then serializing out the appropriate depending on which
longhand it came from
weinig: that sounds right. it has to do with the fact that the
logical properties usually have e.g. margin: left maps very
clearly to inline start or end always
<Rossen> margin-left maps to start in lt-td only
weinig: but because background takes a 2-value thing there's no clear
mapping from e.g. background block to regular background
weinig: and so we need additional state
fantasai: for example background-position-x 0% has same meaning as
background-position-inline 100% in rtl
fantasai: with other shorthands we have all 4 sides and each one maps
exactly and computed value space is the same
fantasai: so you can have a single value
fantasai: whereas for these properties, in that example you can't
return 0% because that would give you the opposite
<dbaron> The main problems seems to be that there are *both* logical
keywords *and* logical sub-properties, and it's a list
valued property that allows mixing logical and physical
within the list.
SebastianZ: what fantasai said is what I posted in one of my later
comments
SebastianZ: there are some examples regarding physical and logical
properties and how to handle them
SebastianZ: idea would be to add a new defer keyword for that
SebastianZ: like fantasai said
SebastianZ: if you set background-position left bottom
SebastianZ: and later read background-position-inline
SebastianZ: question is what you get back
SebastianZ: idea was to add a defer keyword
SebastianZ: was wondering if we need that keyword or if we can
resolve that you use start or end in those cases
fantasai: I think weinig is right, we need to do a thorough writeup
of details
weinig: issue contains a lot of examples, work through a lot of edge
cases
weinig: sticking point was that the way logical properties are
currently defined has certain assumptions about being able to
map directly
weinig: either we need to change those base assumptions or add some
additional state here that works with that structure
weinig: ultimately we can work through all of the examples to see
they do make sense, and you can map them
weinig: we just need the foundational logic to be updated to allow
this more complicated mapping
weinig: we need to write something up, I can try to do that
Rossen: wondering if we should continue that discussion in the issue
fantasai: yes
fantasai: that's the next step
<dbaron> I think another question is whether the logical
subproperties are actually desirable, or whether we should
just add new logical keywords.
CSS Flexbox
===========
Add flex-wrap: balance;
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/3070
TabAtkins: we've been wanting some way of balancing flex lines forever
TabAtkins: Ian spent some time putting together an experimental
implementation
TabAtkins: available in chrome 138 with experimental web platform
features
TabAtkins: quick description of what we've proposed, details are
malleable:
TabAtkins: syntactically this is just an addition to flex-wrap
property
TabAtkins: balance keyword with optional integer with # of lines to
balance
TabAtkins: behavior is: figure out how many lines flexbox will have,
or estimate with basic layout
TabAtkins: and distribute in balanced fashion instead of greedy
fashion
TabAtkins: current behavior is to use same size as for line breaking
TabAtkins: potentially other ways to balance things nicely across
multiple rows
TabAtkins: minimum lines feature, integer, is required for cases
where it's a column flexbox where available space is
infinite and you would never wrap
TabAktins: in wikipedia bibliography, currently done using expensive
manual code
TabAktins: could instead be done with a flexbox with 2 columns
TabAktins: ends up being a simple feature overall
TabAktins: precise details we can continue to work out
TabAktins: we're asking to be able to add this to flexbox 2
fantasai: we have several things that should go into flex 2
TabAtkins: this is mature, we can open spec with it
<iank> Received very positive developer feedback -
https://bsky.app/profile/una.im/post/3lpcjcjn4w22r
fantasai: how gaps interact with flex algorithm
TabAtkins: request is open a new draft, flexbox 2, editor's draft,
include at least this flex-wrap balance feature
TabAtkins: and at editor's discretion whatever else we want to put in
fantasai: I think having a flex-wrap balance feature is a good idea
and we should do it
fantasai: some discussion about having balance stuff on item-pack
instead of flex-wrap
fantasai: in any case you probably want to split out whether you're
wrapping and what direction from the style
fantasai: just like we do for text balancing
fantasai: the kind of, how you prefer to place items is a separate
control
fantasai: so I think it should be a separate property
fantasai: last time we talked about it, we talked about item-pack:
balance
fantasai: happy with that or we can consider other things
TabAtkins: we need to resolve those remaining items questions sooner
rather than later but I don't want to take one right now
fantasai: in any case it should be a separate property
TabAtkins: happy to figure that out in the draft
TabAtkins: not looking to ship tomorrow, but ready to explore
Rossen: proposal is to open new ED for flex level 2
Rossen: and flex-wrap balance, and continue to work on it there
Rossen: objections?
fantasai: happy to take a resolution to add a flex balance feature as
long as it's a separate property
TabAtkins: happy to have flex balance feature, syntax TBD
<dholbert> I'm a little uneasy about the "leave how to balance up to
implementations" part; want to be sure the behavior is
reasonably specified
<dholbert> but not objecting to the feature in general
Rossen: any objections?
<fantasai> PROPOSED: Add a flex wrap balance feature, as a property
separate from flex-wrap
TabAtkins: syntax TBD as part of wrap up of item discussion
fantasai: but put something in spec right?
TabAtkins: yes, doesn't matter what yet, don't need to resolve on
syntax yet
TabAtkins: don't want to resolve on syntax until we have the wider
discussion
fantasai: draft something into ED but draft as separate property
TabAtkins: we don't need that as part of the resolution
Rossen: syntax TBD is good enough, we'll figure out what that
syntax is
fantasai: happy to leave syntax TBD, would like it to not be flex
[missed]
TabAtkins: will mark it off as flex bikeshed
RESOLVED: Add a flexbox level 2 with flex balance feature, syntax TBD
Received on Thursday, 18 September 2025 23:51:48 UTC