- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Apr 2025 19:19:17 -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 Values & Environment Variables
----------------------------------
- Though issue #10674 (UAs inconsistent in how OS font settings
affect the default font-size `medium`) was brought for a
resolution on the name, through conversation the group discovered
a lack of clarity around what are the different behaviors across
browsers and devices. In addition to names, it was suggested
something like an explainer be created that lays out the various
behavior combinations and expected results to help guide
understanding.
- RESOLVED: Working title is preferred-text-something (Issue #10674)
- RESOLVED: Working title is preferred-text-scale, continue work on
defining how it interacts with all the zooms and things
(Issue #10674)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Apr/0006.html
Present:
Rachel Andrew
Rossen Atanassov
Kevin Babbitt
David Baron
Mike Bremford
Kurt Catti-Schmidt
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Simon Fraser
David Grogan
Hoch Hochkeppel
Daniel Holbert
Brian Kardell
Jonathan Kew
Roman Komarov
David Leininger
Vladimir Levin
Chris Lilley
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Josh Tumath
Bramus Van Damme
Lea Verou
Scribe: fantasai
Scribe's scribe: dholbert
CSS Values & Environment Variables
==================================
UAs inconsistent in how OS font settings affect the default
font-size `medium`
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10674#issuecomment-2750125931
Rossen: Bikeshedding issue, 4 proposed names in the issue
dgrogan: This is about naming an environment variable to use inside
env()
dgrogan: Represents the font scale factor that the user has selected
dgrogan: we've gone over a lot of potential names
dgrogan: reason why "font" is there is because it's about changing
font size
dgrogan: "text" because maybe use with text-size-adjust
dgrogan: "factor" was proposed for more explicitness
<dbaron> From the issue:
<dbaron> 1. preferred-font-scale
<dbaron> 2. preferred-text-scale
<dbaron> 3. preferred-font-scale-factor
<dbaron> 4. preferred-text-scale-factor
Rossen: Why not use 'system' in the name of the property?
dgrogan: Considered that earlier. Not sure what happened.
dgrogan: Ah, emilio had a reason -- would avoid system/os in the name
because it could be a browser-specific setting
dgrogan: For most platforms, can only override at UA or OS, but on
windows can be both levels
dgrogan: For windows we were planning to multiply them
dgrogan: So not system, because could include the UA
emilio: To text scale, at least on windows/linux, gets used as a DPI
multiplier, which we wouldn't want to expose here
jensimmons: What kind of value is returned? A <number>?
dgrogan: It's a unitless value like 1.4, used as a multiplier
jensimmons: What do you expect the range? 1 is keep it the same?
dgrogan: Right
jensimmons: So 0.5 makes it half, 2 makes it double?
dgrogan: Yes
<ChrisL> My top choice would be preferred-font-scale
smfr: Is this linear scaling for all font sizes? Text that's already
large would be doubled? Does that match what browsers and OS
want?
dgrogan: This is just the environment variable. Authors can use
strategically as they want
dgrogan: if asking about linearly scaling all font sizes, author could
smfr: There's a danger that they will, which would make large text
ridiculously large
iank: They could also apply their own scaling
smfr: I'm not sure how Apple system scaling works, but probably more
smart than linear scaling
iank: This isn't smart, just exposes the factor
smfr: alternative would be some API to do the mapping, but that would
be more complicated
fantasai: There were several conversations in this thread
fantasai: Did we resolve to add any other [...] in this issue?
dgrogan: We did resolve to add the unit, zem or pem or something
fantasai: I wanted to add another name to the pile, for polling...
"preferred font zoom"
fantasai: that avoids some confusion around what "scale" might mean.
zoom factor is more obviously a factor
dgrogan: Discussed on thread. Careful to differentiate, only applies
to text. We casually use "zoom" for full page zoom, which we
do on Windows for now but trying to move away from
dgrogan: move to text-only scaling
<iank> I think `zoom` might get conflated too much with other zoom.
fantasai: there's a feature in Firefox called "text zoom" which zooms
the text, and we have several different kinds of zoom in
CSS, so it shouldn't be too confusing to call this a flavor
of zoom
emilio: We have a 'zoom' property that does layout zoom, so would try
to avoid overloading zoom even more ...
emilio: Maybe we could narrow down by asking 2 questions
emilio: between 4 choices in the comment, 2 questions are should we
call it "scale" or "scale-factor" and should we use "font" or
"text"
emilio: I prefer to avoid adding -factor
emilio: I would use text rather than font
emilio: implies it would apply to font properties, but might want to
use it elsewhere
emilio: and I think "text" matches what OS usually calls it
dholbert: ... browser has not acted upon. Is there any potential
problem to having a 2x zoom factor already applied, and
then pages reacting to it and applying more zoom?
emilio: If you apply it, either full zoom or whatever, you're
supposed to return 1 as the scale factor
Rossen: We're talking about the final result of some combination
between the UA and the system font settings, that will be
represented as part of this scale factor
Rossen: which is to say, if they end up cancelling each other, that's
OK. But the final combined result
Rossen: that is exposed to the user
dgrogan: yep, that's the plan
dholbert: So this is representing a request from user for increased
text size that the browser has not already applied
Rossen: if you have 2x in the system and .5 in the browser, your
document will receive 1.
Rossen: assumes you as the user knew what you're doing when scaling
things up/down
iank: Question was did we apply this to 'em' yet, and the answer
is no.
dholbert: If ask 2x, is the browser already drawing text at 2x, or is
it drawing at 1x and tells author that there's a request so
author can apply
emilio: My understanding was that if you scale the web content in
some way, then you shouldn't expose this factor, right?
emilio: let's say you apply 2x in windows settings, we keep our
current behavior, we do the full zoom
emilio: arguably doesn't scale the text, but...
emilio: then not supposed to expose this again
dgrogan: Definitely what we plan to do. Will ship on Android first,
which only has one slider (OS level)
dgrogan: On other platforms we'll leave as 1 until we figure out what
we want, as the UA, to do
dgrogan: It's going to be 1 everywhere until we sort it out
<dholbert> FWIW Firefox on Android does have its own "Font Size"
slider
<dholbert> (in settings|accessibility)
dgrogan: Right now, on windows, if you slide the OS level over, we
don't do font scaling, we don't even do full page zoom. We
do full browser zoom, which is ridiculous
dgrogan: as long as Chrome does that, we're going to leave this as 1
fantasai: My understanding was that this represents the factor that
you as an author would want to apply to the initial value
of `16px` in order to get the user's preferred font-size
fantasai: ...for body text specifically (there might be different
scaling factors that are appropriate for other text, e.g.
headings)
fantasai: We need to be very clear that that's the intention, so on
systems where there are multiple scale factors, it's not
ambiguous
fantasai: This will affect different zooms in different ways... e.g.
if you pinch-zoom, it shouldn't influence this environment
variable. If the browser's doing a full-page zoom as a way
to respond to user's preferred text size by zooming
everything, then this env var should return `1`. That might
be a case where you'd want to ask the page to do it for you
instead
fantasai: but you'd need confirmation from the page that the page
could handle it
fantasai: so you'd need some sort of two-way negotiation similar to
what we do for dark mode
fantasai: I don't like "scale factor" naming. "scale" sounds like it
could have multiple mappings instead of a single
multiplier. That's why I prefer 'zoom', seems more like a
single thing that has just this purpose
smfr: I'm confused. There are multiple things happening here.
smfr: In iOS there's accessibility settings to change the size of
text. And in the browser you can change the text size with +/-
buttons
jensimmons: Currently browser setting is per-site
iank: On iOS, when you do the + button on a site... that doesn't
trigger browser zoom, that just changes the text?
smfr: On Mac, it effectively increases size of CSS px. Can't remember
on iOS. I think it's a text zoom?
smfr: On iOS the text gets bigger, but images etc don't, don't get
side scrolling
iank: Images, depends how they're set up.
<davidleininger> opt+cmd++ is font size adjustment on safari
smfr: My pref for this env() is that it simply reflects the scaling
you get if you use the Apple system fonts
smfr: interacting with browser zoom is confusing
iank: Our intention is to remain stable for browser zoom
iank: Chrome has an additional scale factor, which is applied on top
of OS setting. Not describing browser zoom.
smfr: on Mac Safari there's an option for text-only zoom
<davidleininger> Also, on Mac in Safari, Dynamic Type is 13px.
Rossen: Listening to the conversation, doesn't seem like naming is
the only thing to discuss here. Seem to be more refining of
expected behavior that we need to get alignment on before we
name it.
iank: Only on iOS, I think.
Rossen: I'm expecting this property should work everywhere
iank: Confusion is only on iOS
dholbert: Firefox on Android also has a text zoom setting in addition
to OS setting
dholbert: works similar to Safari on iOS
dgrogan: Which one?
dgrogan: Firefox on Android, you guys have an option where you were
defer the UA level to the OS level
dgrogan: but then if you don't do that, your UA level overrides the
OS level
dgrogan: so you only have one on Android effectively
<jfkthame> in safari on iOS, I'm seeing both text and images getting
zoomed when I use the text-size adjustment
dholbert: We ignore the OS level, at least on example.org
dholbert: but if you change the slider then it increases the text size
emilio: It increases everything.
dholbert: We call it "font size" "make text bigger", maybe that's
misleading
smfr: Risk is multiple scale factors from different places, and get
massive text
smfr: Users need a minimum text size
iank: We covered previously why we want to expose this as a scale
factor, in that we expect users to use this with
text-size-adjust and stuff like that
iank: exposing a minimum factor is broken
iank: that's why we want to expose as a factor
iank: Would be fine if you want to propose a name like minimum scale
factor ...
smfr: text-size-adjust, you're talking about font boosting?
iank: Sites today will do text-size-adjust: 1.5; and turn off the
auto font boosting and increase text size that way
iank: Sites want to do something like this
jensimmons: Alluding to my question/thought, which is that, a lot of
authors are confused in some ways about text sizing
works, font zooming works right now
jensimmons: Tension comes up every time we try to make things better
for accessibility
jensimmons: truth is many sites don't do anything, or do little, or
do it wrong
jensimmons: so browser try to create situation where sites are usable
despite authors
jensimmons: So on Apple platforms, a lot of mitigations already in
place
jensimmons: We force creating situation that users need
jensimmons: Nice to be able to let author take over
jensimmons: on the other hand, authors are already so confused. I
don't even know how to explain what's happening now,
nevermind the future
iank: The original problem here was text autosizing, which was added
when mobile was first taking off
iank: Ideally as the browser, we'd choose the font sizes. But we
can't really do that in a correct way because it's very easy
for text to get ??
iank: so making something that was small and difficult to read
completely unreadable
iank: because of this, authors want a lot more control
iank: currently, they're using a lot of different mechanisms to probe
for this underlying text scale factor
iank: e.g. on iOS they're using a magical Apple extension to probe
this
iank: on Chrome they're using a different magic thing
iank: and then they're applying that text factor
iank: It would be nice if nice if browsers could just increase the
size of text but fundamentally can't do that. Will clip content.
iank: Authors want a way to access this value, and this is our
proposal for enabling that. Does it make sense?
jensimmons: Yes, you're explaining it well. :)
iank: A lot of websites will turn off [missed]
iank: And that is also bad for users, because they're explicitly not
respecting the OS level thing
iank: So lots of sites want to use, currently hacking around to get
this info, and we want to expose this in a consistent way
schenney: Jen's point is that websites don't do the right thing. but
websites are trying to do the right thing by adjusting the
fonts in a sensible way. But don't have the necessary
information.
schenney: so this is letting the website know what the browsers going
to do. So doesn't make the bad things worse
jensimmons: It sounds in some ways that we're trying to standardize
something that's not been standardize
jensimmons: Now reaching into browser user settings, and exert more
standardization
jensimmons: hopefully we're looking at multiple browsers and OSes to
figure something out here
jensimmons: I imagine how Android handles this is different from iOS,
or Mac or Windows
<Rossen> +1 to jensimmons
jensimmons: The more we look at this problem the more complicated it
gets. Want to make sure solution works for all OSes
jensimmons: Don't want something to work great on one OS and not on
others
jensimmons: [cites earlier example of a thing]
iank: OSes are quite consistent in exposing "how much do you want to
boost your minimum font size?"
iank: Browsers have interpreted that in different ways
iank: It's going to take time to move browsers to a consistent state
iank: Android is most painful but also on Windows etc.
iank: but we want to start there. We want to fix this mess.
iank: OSes are consistent, it's how we represent that that's a mess
dbaron: wrt idea that stuff been around for decades...
dbaron: not quite
dbaron: we tried to honor user prefs in default font size, but that
broke stuff, because authors assumed 16px
dbaron: what the proposal is trying to do is to enable pages to
access that default
Rossen: I think we're farther in our understanding of the expected
behavior...
weinig: To back up what Jen said, I think that it is hard to wrap
your head around the current state of affairs.
weinig: Adding more things here is confusing
weinig: Efforts to really converge the browsers together on behaviors
that make sense would be great.
iank: Agree, but it will take time.
emilio: Ideally we find a consistent thing to do across browsers
everywhere
emilio: but confusing for a lot of reasons
emilio: Even if we do that, that doesn't necessarily make this useless
emilio: Worst case you have a scale factor, that's always 1
emilio: I don't see a reason not to do this necessarily. This gives a
tool to authors
emilio: to do the right thing
fantasai: It sounds like what might help this conversation would be
an explainer that talks about all the different things that
play into the size of text, and how they interact, and how
this is going to help the situation
fantasai: there's been a lot mentioned here - text-size-adjust,
browser zoom factors, layout zoom, pinch zoom, OS/browser
settings...
<Rossen> fantasai taking the words out of my mind again... all I want
to see here is a table of combinations between OSs and UAs
<ChrisL> fantasai++ an explainer would be great to tie the different
inputs to this value together
fantasai: drafting up an explanation of how these all fit together,
and how this would get us to a more consistent useful
world, would be helpful here
<iank> we have a spec for `text-size-adjust`
<iank> https://drafts.csswg.org/css-size-adjust-1/#adjustment-control
fantasai: Is that spec actually correct?
iank: It's correct in that 'auto' is magic
iank: A lot of developers get frustrated with 'auto' and turn it off
iank: In webkit and blink, text-size-adjust:auto is really bad for
most websites so webdevs get frustrated and turn it off
<ChrisL> I note that Mobile Text Size Adjustment has not yet had FPWD
iank: it's specced, but devs turn it off, which is partly why we want
this new value
iank: devs want to replace it with something, which is why we want
this knob. they use magical webkit/blink specific stuff, and
might not have a similar magical thing on Firefox
<Rossen> so, is text-size-adjust: env(preferred-text-scale) the
answer to people turning this off?
dgrogan: We had a long conversation at the Apple F2F in January, and
there the group resolved that we would expose this
environment variable
dgrogan: Are we revisited that decision? Do we need to explain why we
need this?
Rossen: I'm hearing strong agreement on the why. I think there's a
lot of details that people are struggling with, so I would
start there.
dgrogan: So that would help the name?
Rossen: Name is the artifact that comes at the end. Will be
uncontroversial once we understand what the outcome is
supposed to be.
Rossen: What I'm hearing is, people are poking at various
intersections on the table of combinations
Rossen: and then how do these properties overlay on top of that table?
Rossen: I think once we clarify all these interactions, we'll be able
to resolve on the name
Rossen: not about the name, but about the how
Rossen: We started with a question about the name, but the
conversation in the last half-hour was all about "what is the
expected behavior?"
Rossen: so the group is not clear on how this is going to work
Rossen: to add to it, you even said that parts that you are not going
to support to start with
Rossen: so this is the problem, I understand you want to get a name
so you can release something on Android
Rossen: but the feedback I'm paraphrasing here, maybe not greatly, is
that there's still lack of clarity on what this behavior is
supposed to be when it's generalized across all these
combinations
iank: We can write out what we expect the behavior to be for Chrome
on different OSes. Don't want to write down what other browsers
want to do.
emilio: Part of nice thing of doing this is we don't need to come up
with those answers
emilio: If browser does magic scale by default, then expose variable
as 1
emilio: that's whole point of this
emilio: This is an enhancement on what browser do, which is just turn
it off
Rossen: that's not winning. This is exposing another auto, just call
it 1, and people still can't rely on it
emilio: If browser is doing its own scaling, then should expose it
as 1
Rossen: Now we're saying sometimes it is, sometimes it's not. This is
the lack of clarity the conversation is exposing
fantasai: This all needs to be made clear, how all this fits together
and how the new stuff fits in with the existing stuff
fantasai: having an explainer would be useful; needs to explain how
authors are expected to understand and use it
fantasai: The viewport spec and text-size-adjust spec, we need to be
sure they're explained coherently in terms of how they hook
into this comprehensible world
fantasai: I'm assuming this new env var would live in
text-size-adjust spec
dgrogan: nope, env spec
fantasai: units aren't gonna live in env spec
fantasai: If we want a central concept of what this thing is, from
which env variable and units are computed, that needs to
exist somewhere. text-size-adjust is a place that makes
sense to me (and then other specs can refer to it)
fantasai: There needs to be a coherent story for how this stuff all
fits together
Rossen: So we started with wanting a name. I think we can still
resolve on a working name. Clear signal that more work is
needed to bring the consensus and the final unified behavior
that authors can depend on
Rossen: We can deal with a quick straw poll and at least have a
working name.
Rossen: First, should it be text or font? And then scale or factor,
and then leave it at that, and leave for further work
POLL: a) preferred-text- b) preferred-font-
<schenney> a
<jfkthame> a
<kizu> a
<dgrogan> a
<dholbert> a
<hoch> a
<jensimmons> B
<astearns> a
<dbaron> b
<iank> a
<kbabbitt> a
<kurt> a
<flackr> a
<davidleininger> B
<Rossen7> a
<rachelandrew> a
<smfr> a(bstain)
<miriam> a?
<fantasai> b?
<emilio> a
<bkardell> abstain as well
<ChrisL> b
RESOLVED: Working title is preferred-text-something
POLL: a) preferred-text-scale b) preferred-text-factor
c) preferred-text-scale-factor d) preferred-text-zoom
<ChrisL> a
<schenney> a
<astearns> a
<jensimmons> A
<iank> a
<dbaron> a
<dgrogan> a
<kurt> a
<flackr> a
<kbabbitt> a
<smfr> c
<Rossen> a
<kizu> a
<hoch> a
<fantasai> d
<jfkthame> a
<dholbert> a
<emilio> a
RESOLVED: Working title is preferred-text-scale, continue work on
defining how it interacts with all the zooms and things
Received on Wednesday, 16 April 2025 23:19:50 UTC