- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 9 Jul 2025 19:13: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.
=========================================
CSS Color HDR
-------------
- RESOLVED: Close, no change (Issue #11711: Alternative proposal for
`dynamic-range-limit` defaults)
CSS UI
------
- RESOLVED: Move the rendering details of legend, fieldset, button
and appearance from HTML spec to CSS Forms (Issue #10039:
Styling of native appearance)
CSS Fonts & Environment Variables
---------------------------------
- RESOLVED: No longer pursue pem units. Adopt proposed <meta> for
opting into adjustable text scale. (Issue #12380: New
`<meta text-scale>` tag to make UA initial font size
respond to OS text scale setting)
CSS Conditional & Environment Variables
---------------------------------------
- RESOLVED: Add env() function to @supports (Issue #3576: Need an
approach to check whether an environment variable is
supported)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Jul/0005.html
Present:
Tab Atkins-Bittner
David Awogbemila
Kevin Babbitt
Justin Breiland
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
Paul Grenier
David Grogan
Brian Kardell
Brad Kemper
Jonathan Kew
Roman Komarov
Chris Lilley
Alison Maher
Penelope McLachlan
Eric Meyer
Cassondra Roberts
Alan Stearns
Josh Tumath
Bramus Van Damme
Lea Verou
Sam Weinig
Regrets:
Rachel Andrew
Daniel Holbert
Florian Rivoal
Noam Rosenthal
Miriam Suzanne
Scribe: JoshT
CSS Color HDR
=============
Alternative proposal for `dynamic-range-limit` defaults
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11711
weinig: Underlying problem is there isn't an agreed upon default
value for the dynamic-range-limit property.
weinig: in this issue, proposing a slightly different one, but
vendors are in control
weinig: opinions about what default should be. no consensus yet
weinig: nothing to resolve yet
weinig: my opinion has shifted. direction chrome went originally
probably most reasonable
weinig: no limits by default across the board. mozilla and webkit
folks not in agreement
weinig: would be good to have some rules or ideals for this
weinig: one I was pushing for was an equivalency principle
weinig: something the vendors are still undecided on, so not sure
what to do
smfr: In the currently released betas for iOS and macOS, shipping no
limit by default
smfr: with the caveat that if we see abuses, we'll change the
behaviour
astearns: given that, could we resolve to go with no-limit as the
default?
weinig: I think that makes sense. we always say if problems arrive,
change things
weinig: I do think there is another thing we can do if abuses come
up, such as having ways for people to turn off HDR for iframes
smfr: I don't believe there's progress on that
weinig: I'll take as an action item to follow up on that
smfr: Another thing raised was what happens with CSS colors? are they
HDR by default, or should be opt in?
ChrisL: I would like to change the thread to say if you don't have
color-hdr() you go back to SDR
weinig: I would like to debate that and will file a new issue
emilio: I think we're fine with what Chrome and WebKit are going to
ship. Can always change things
astearns: ok we'll open up a new issue about what color functions
give us with HDR
PROPOSED: close, no change
RESOLVED: close, no change
CSS UI
======
Styling of native appearance
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/10039
emilio: The PR has already landed. Is there anything else to discuss?
I think we're in agreement a lot of the stuff from the WHATWG
spec should be in CSS Forms and someone needs to do the work
astearns: are we set up to just get the work done? Or any decisions
needed?
emilio: could resolve to make the things in the HTML spec move to CSS
PROPOSED: move the rendering details of legend, fieldset, button and
appearance from HTML spec to CSS Forms
RESOLVED: move the rendering details of legend, fieldset, button and
appearance from HTML spec to CSS Forms
CSS Fonts & Environment Variables
=================================
scribe: kbabbitt
New `<meta text-scale>` tag to make UA initial font size respond to
OS text scale setting
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12380
JoshT: we discussed & resolved to accept a new environment var called
preferred-text-scale
JoshT: and to add a new CSS unit pem
JoshT: so me and davidgrogan and pdr have been working on new
explainer
JoshT: for new meta tag as well
JoshT: not looking for a resolution on that, just introducing to group
<JoshT> https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/meta-text-scale.md
JoshT: ^ link to explainer
JoshT: in summary, after talking to authors about this, we had some
feedback that they don't think pem units would be very useful
JoshT: problem we're trying to solve is, when the user sets font
scale in OS a11y settings
JoshT: that doesn't get reflected on webpages they use
JoshT: over 1/3 of users on mobile devices set default font sizes
JoshT: feedback we had was, authors just want rem units to work
JoshT: they've been told if they use font-relative units everywhere,
websites will just have the correct scale
JoshT: but that's not happening
JoshT: after going through options, we've come back to original idea
from 2019
JoshT: which is to have a new meta tag
JoshT: proposal section in explainer: rather than incorporating into
viewport meta tag, this would be a new one
JoshT: it's proposed to have 2 options, names to be bikeshedded
JoshT: `legacy` which is current behavior for text scaling
JoshT: `scale` taking into account OS setting and UA setting for
default font size
JoshT: explainer has a comparison table
JoshT: showing what's affected by these 2 options
<fantasai> ->
https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/meta-text-scale.md#comparison-of-legacy-and-scale
JoshT: `legacy` has lots of different behaviors depending on mobile
or desktop
JoshT: `scale` will unify these across mobile & desktop
fantasai: we're expecting this to affect initial value of font-size
property?
fantasai: keywords?
fantasai: interpretation of that and rem units
fantasai: that put together means that authors could design with idea
that initial font-size is user's preferred font size and
their page will just work
fantasai: leaves us room to contemplate whether we want to adjust the
absolute keywords for OS scale
fantasai: right now they're fixed multipliers
fantasai: we could consider making them adjust based on what medium
font-size actually is
JoshT: we found in our research that, desktop browsers increase
default font size, those keywords should also proportionally
increase
<fantasai> Some OSes don't have a linear scaling of their larger
sizes with increases in the base font size
<fantasai> So we could consider making the font-size keywords adjust
in the same way
<fantasai> as the OS, rather than being fixed multipliers
emilio: to be clear, 2 big differences
emilio: font-size 16px * preferred scale factor
emilio: affects media queries and keywords
emilio: feels a bit odd to make the initial value of a property
depend on ...
emilio: if you're not changing initial value, just what it computes
to, should be fine
emilio: mqs are a big one where ... the one you cannot easily do
otherwise, right?
emilio: mqs seems like actual useful thing that this would introduce
emilio: making ems and rems work properly with mqs based on user font
scale
emilio: haven't seen keywords used all that much, could get around
them if needed
emilio: rem units can be set with font-size
JoshT: agree, not aware of authors using keywords much these days
JoshT: important to call out medium since that's how UA initial font
size is derived
JoshT: key feature is that rem units will now work
JoshT: in mq scale based on os font size as well
emilio: ideally it is much more convenient to be able to do this
emilio: also text-size-adjust would basically be none?
emilio: UAs / authors aren't expected to do adjustments?
JoshT: yes, text size auto is effectively disabled
emilio: seems unfortunate to me that it can't be the default behavior
emilio: but a meta tag seems reasonable
emilio: especially since it needs to affect mqs
TabAtkins: really like this approach, like emilio I wish we could do
this by default but compat is out of whack
TabAtkins: meta tag that makes this not overly complicated sounds
great
<romain> +1
astearns: JoshT you opened this to introduce, but no objections yet
JoshT: 2 resolutions: 1. no longer have pem units
JoshT: 2. adopt the proposal in the explainer for meta text-scale
<fantasai> PROPOSED: No longer pursue pem units. Adopt proposed
<meta> for text scale.
<fantasai> PROPOSED: No longer pursue pem units. Adopt proposed
<meta> for opting into adjustable text scale.
astearns: don't want to rush, if anyone would like time to look at
the explainer, happy to take this up in another meeting
astearns: hearing no requests to go slower, any objections to
proposed resolution?
RESOLVED: No longer pursue pem units. Adopt proposed <meta> for
opting into adjustable text scale.
fantasai: the two open questions are 1. naming; 2. whether we allow
font-size keywords relationships to each other to be
affected
astearns: suggest opening a new issue about keyword thing
astearns: on naming, would prefer having a name in the spec at editor
discretion that people can open issues on
astearns: don't open an issue until we have something to disagree
about
JoshT: one other question, what spec should this live in?
fantasai: device adaptation
JoshT: is that renamed to CSS viewport
fantasai: yes.. fonts level 5 then?
ChrisL: sounds reasonable
astearns: do we have editors for fonts 5 that are up for this?
ChrisL: new blood always welcome
astearns: if we add a new editor, would it be JoshT or dgrogan?
TabAtkins: this is relatively small, I can do it
keithamus: also happy to pick up the work to relieve TabAtkins
<TabAtkins> That works for me too ^_^
CSS Conditional & Environment Variables
=======================================
scribe: JoshT
Need an approach to check whether an environment variable is supported
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3576#issuecomment-3022505160
<bramus> `@supports (x: env(this-does-not-exist)) { … }`
bramus: about feature detecting environment vars
bramus: if you do a check like this, the check always returns true
bramus: env() only becomes invalid at computed value time, not parse
time, so this check always returns true
bramus: authors need to check some of the env() vars are supported
bramus: depending on support, authors might need to do something else
in their CSS
bramus: proposing a new function to use inside the @supports
bramus: like now you can do @supports selector()
<bramus> `env( <custom-ident> )`
bramus: we'd have @supports env() with your custom ident
bramus: and when the custom-ident is one of the supported env()s, it
returns true
TabAtkins: so I support this, makes sense. fallback is often all that
you need but there will be cases where you need to do an
alternative design
TabAtkins: I saw lea's comment on the thread. 'Why aren't we
detecting whether it is known at parse time?'
TabAtkins: because we need to be able to do fallback
TabAtkins: if it was done at parse time, fallback would not work
TabAtkins: could do it in theory, but would be contrary to how other
things with fallback work
<emilio> +1 to what tab said
lea: indeed what I was going to ask
lea: might be web compat concerns at this point
lea: if there is no fallback, maybe it could become valid at parse
time, and if not, it would be evaluated as it is now
lea: one issue with that is theoretically you could have a var with
the env var and the fallback, and then it wouldn't be possible
to know when you have a fallback.
lea: but that's how vars work anyway so won't be a problem
lea: these things don't have a preset known in advance anyway, but if
it is known it would not be known at parse time
astearns: in looking at this, I thought there may be places where
there needs to be double support calls to see where a var
will be supported for a particular property
astearns: but I don't think in practice that will be an issue. env
vars are normally just <length> values
astearns: Even when you want to test presence in general, without a
particular property in mind, it's common practice to just
pick one, e.g. to test color validity authors often do
@supports(color: foo)
bramus: I fear if we change how env currently works to check at parse
time, that would differ from how var works. people may ask
why you don't do that for var
bramus: I don't think it makes sense right now because all custom
properties come back as supported because you can have any
name
emilio: I think there is value in keeping it consistent with var.
even with lengths, it will just compute to the initial value
of the property when it's not supported, like 'auto'. I
wouldn't need to write a fallback. It feels easier to reason
about at computed time.
emilio: I think we do want to keep env() resolving at computed value
time. The simple thing is good: add the new env() query to
check it's supported
emilio: and even if you need to behave as invalid at parse time, you
can do @supports and call it a day
lea: custom properties are like this because they are defined by
authors and could change.
lea: it's an unfortunate wart in css that we had to accept to make it
possible
lea: but with env() we can do better
lea: right now, it's fixed, the value doesn't change
emilio: the values do change, so you do still need the env()
reference at specified value time. so this would not be like
calc() which can simplify most of the time
emilio: you still need something in between, so I suggest just
keeping it like var()
* lea is confused. Do values change in a way that affects validity?
* fantasai too
<bramus> +1 to what Emilio said
emilio: you still need to keep the reference
emilio: that would significantly change how these work and I still
think there's value make it like var()
emilio: you cannot get rid of the reference anyway, so I don't think
it's as useful as you think. Maybe I'm wrong
emilio: having an in between thing where you evaluate them at parse
time based on whether the name exists I think is weird
TabAtkins: I think this discussion is confused. we are not worrying
about the type of the value
TabAtkins: its a substitution function
TabAtkins: while the set of envs is static over the course of a page
life time, we are adding more envs relatively often so
knowing what is supported in a browser is non-trivial
TabAtkins: we're worried about the fact that new stuff can be added
in a way to predict and engineer around without a query
TabAtkins: often the fallback is fine, but when you need more
complicated reactions, knowing whether a value exists or
not is valuable here
TabAtkins: to have an @supports env() that checks if it exists is
useful here
kbabbitt: on the topic of env vars changing, I remember a proposal to
have author defined global values of some kind
kbabbitt: not sure if it was env vars but that could be useful for
setting values for the entire page
kbabbitt: was that proposed as an extension to env vars, because then
it could be extended by author definitions
TabAtkins: the discussion never settled on that, whether var or env.
TabAtkins: regardless, they are distinct because the keyword would be
double dashed --
TabAtkins: I agree to treat env as like var for simplicity
TabAtkins: but we don't know how that would affect the rest of the
discussion
lea: +1 to the problem
lea: I agree it should be possible to check if a name is known and
not known
lea: the question is the way to do it
lea: what is being proposed, it only makes some of these uses invalid
at parse time. like with a made up env name, it would always be
invalid
lea: if the name is known, same behaviour as today. the only case
that is different is when the name is not knowm
lea: it seems better to improve the API surface than teach a whole
new function
lea: if we have a new API surface and a new function, authors would
have to look it up
lea: and custom envs would need to use -- dash dash anyway
emilio: When I mentioned typing, I was wondering how we could diverge
while parsing
lea: but there's no substitution. you know the name.
lea: if a var is used, it's a different story
emilio: but right now, we don't check the value at parse time.
emilio: it has a performance cost to change root properties after the
page is loaded because you need to inherit it in the whole DOM
<kbabbitt> +1 emilio
astearns: I am agnostic to these approaches. I'm concerned about the
difference of how @supports works with whether there is a
fallback or nor
astearns: it would change the validity if you're asking for an
invalid env var
TabAtkins: It would just be asking about the name
bramus: Regarding what lea proposed, if the custom ident is an env
var, I think that would allow to do something like:
<bramus> `@supports (background: env(safe-area-inset-left)) { … }`
bramus: this seems not good because the pixel value is not the value
of the background
lea: it would be parsed as a background position and everything would
still go back to the initial value
bramus: I think we should still use the @supports env() function
because otherwise authors would still have to look up when an
env() value works in @supports works
astearns: It could be an issue that the @supports version of env(),
copy-pasted env() will fail to work properly if it has a
fallback
<TabAtkins> The suggestion is to allow `@supports env(foo, fallback)`
and just ignore the fallback
bramus: we could then also opt to change the @supports to accept the
fallback, which then wouldn't take it into consideration, but
maybe that's not a good thing
<TabAtkins> (I don't think this is a good idea.)
<lea> TabAtkins: ideally we could validate prop: fallback if foo is
unknown, but that's less important than env(unknown) being
invalid IMO
fantasai: I am sympathetic to lea's option. but I think that's a
separate argument to whether we have @supports env()
fantasai: even if we make that work, having a shorthand to support
this is still useful
<emilio> +1
fantasai: that would let us accept this proposal and we'd still
consider to discuss if you could evaluate env() at parse
time
fantasai: but regarding the proposal, I don't think it should accept
a fallback
<lea> +1 fantasai
fantasai: the top level functions are specific about what they accept
fantasai: it could be checkable in some way but I don't think we
should allow that. we should accept the keyword
<TabAtkins> I think Emilio and Bramus's point about consistency of
operation is important. env() is mostly identical to
var(), giving it different validity behavior makes things
harder to learn.
JoshT: there is a difference between how env and var work
JoshT: because env works in mqs as well
JoshT: but I don't think that's currently supported in any browser
lea: as I wrote on the IRC, we could invalidate property fallback if
the name is unknown, but that is a second tier thing
lea: but that would be the north star. then you could evaluate if ????
lea: that is now app support works in general. it's already taught
that that's how @support works anyway.
lea: consistency has been talked about. it's an ergonomic issue
lea: the way var works now anyway is an ergonomic issue
lea: there is a TAG principle on consistency.
lea: but there are cases where it is warranted to break consistency
if the other option has better ergonomics
<romain> +1
lea: I would argue there are cases where people currently struggle.
this is a pain point.
lea: the priority of constituencies relates. we don't want authors to
learn a new thing.
<TabAtkins> The var() behavior (invalid at computed value time) is
unavoidable and shows up in several places now.
Similarly, `attr(nonsense)` is valid at parse time. Etc.
env() being the sole exception of substitution functions
that can be invalid at parse time, *depending on what you
write*, isn't great.
emilio: quick suggestion
emilio: it seems everyone agrees checking whether env is supported is
a useful thing
emilio: was going to suggest we move how env parses to a separate
issue
emilio: changing how env works has a perf cost and compat risk and
it's more implementation and research cost
<lea> @support env() is nice regardless, even as a shortcut. And it
does fix the immediate issue so +1 to it
<JoshT> extending @supports is easier
<fantasai> +1
<bramus> +1
<ydaniv> +1 to emilio
emilio: if we end up with two ways to test how env() works, I think
that's a relatively small cost to pay
<lea> astearns, I think we have consensus to add @supports env(name)
<kbabbitt> +1 to @supports env(name)
emilio: would anyone object to adding @supports env() to the top
level syntax
RESOLVED: add env() function to @supports
Received on Wednesday, 9 July 2025 23:13:45 UTC