LGTM2
Thank Philip and David for elaborating on the differences between mobile
and desktop platform that have led to this approach, and Domenic for your
summary of the situation.
Thinking about the longer term, I think it's important that the addition of
env(preferred-text-scale) and yet other mechanisms for desktop doesn't doom
us to different code and opt-ins for desktop and mobile. And it doesn't,
this is Domenic's third bullet point on greenfield projects, using rem/em
and <meta scale-ems>.
On Fri, May 30, 2025 at 5:55 AM Domenic Denicola <dome...@chromium.org>
wrote:
> Thanks for the patient explanation David. I'm convinced that this is one
> of those cases where the web has enough unfortunate legacy that we need to
> add extra complexity. LGTM1.
>
> To summarize back the main points of concern I had, and how they're
> actually OK:
>
> - I was concerned about forward-compatibility due to us shipping on
> mobile first, and only later on desktop. This is not a problem, because the
> plan of record will require a separate opt-in for desktop.
> - I was concerned that this separate opt-in for desktop was inelegant
> and maybe just an artifact of our engineering prioritization. This is not
> the case: there are entrenched differences between desktop and mobile
> platforms, which we cannot fix, such that (at least for `px` users) we
> really do need separate pieces of functionality.
> - I was concerned that we were not creating a sensible path forward
> for web developers who wanted to do the right thing on greenfield projects.
> This is not the case: we will be able to tell such web developers "use
> `rem`s/`em`s and `<meta scale-ems>`, ignoring the `env()` stuff.
>
>
> I especially appreciate that you took the time to respond to these
> concerns, even after writing an extensive explainer which contained the
> information in a different format.
>
> On Fri, May 30, 2025 at 11:12 AM David Grogan <dgro...@chromium.org>
> wrote:
>
>> On Tue, May 27, 2025 at 6:37 PM Domenic Denicola <dome...@chromium.org>
>> wrote:
>>
>>> Thanks for the detailed response. However, I might not be understanding,
>>> so let me try asking the following question.
>>>
>>> It sounds like the proposal is to ship two opt-ins for adapting to
>>> OS-level font-scaling, one mobile-specific and one desktop-specific:
>>>
>>> - On mobile, authors would opt-in by adding `:root { font-size:
>>> calc(100% * env(preferred-text-scale)); text-size-adjust: none; }`
>>> - On desktop, authors would opt-in by adding `<meta name="viewport"
>>> content="width=device-width, initial-scale=1.0,
>>> text-scale-behavior=initial/scale-ems/none">`, and then also also adding
>>> the same CSS as on mobile.
>>>
>>> Ah, not quite.
>>
>>
>>> This seems like an undesirable design to me from an interoperability
>>> perspective. Is there any way we can require the same opt-in on both
>>> platforms?
>>>
>>
>> Yes, the proposal includes opt-ins that take effect on both desktop and
>> mobile, namely <meta ... scale-ems or none>. We expect that scale-ems
>> will be the most popular way for sites to incorporate OS-level font
>> settings. If a site needs none, then the same env() stuff that worked on
>> mobile will work on desktop.
>>
>>
>>>
>>> From what I gather from your writing below, you need the "double opt-in"
>>> on desktop because of a Windows-specific problem. I don't quite understand
>>> why you can't roll that into a single opt-in. But assuming that you do need
>>> a double opt-in, I think requiring the double opt-in on both platforms
>>> would give a better interoperability story.
>>>
>>
>> The mobile and Desktop platforms are unfortunately already different
>> enough that they have technically-different opt-in requirements. For
>> example, if we rolled out env() to Desktop with no <meta> opt-in support
>> (or other similar handshake mechanism), there'd be double-scaling on all
>> Desktop OSes, not just Windows. Double scaling would happen because, since
>> antiquity, if a user changes the UA-level font setting in a Desktop
>> browser, the default value of rem changes. So, if a site had something
>> like
>>
>> <html>
>>
>> <div style="font-size: calc(100% * env(preferred-text-scale))">I'm
>> double scaled</div>
>>
>> … the inner DIV gets the user's UA font setting doubly-applied, once by
>> rem, once by env(). That's bad.
>>
>> The double scaling problem is exacerbated on Windows because in addition
>> to the above UA-scaling problem, all major browsers change the ratio of
>> device pixels : CSS pixels in response to the Windows OS-level font
>> setting. So, with the above CSS, the user's OS font setting would be
>> applied twice on Windows.
>>
>> <meta … none> would disable both the Windows device pixel scaling AND
>> the rem effects of the Desktop UA setting, allowing sites to use env()
>> where they see fit. This is a double opt-in (1. meta 2. env), but would
>> have the same effect on both Desktop and mobile:
>>
>> <html>
>>
>> <meta something="none">
>>
>> <div style="font-size: calc(100% * env(preferred-text-scale))">Properly
>> scaled!</div>
>>
>> Note that no <meta> is technically required on mobile because the default
>> rem is always 16px on mobile AND no mobile OSes do the Windows device
>> pixel change thing in response to font settings. There are no inherent
>> built-in mechanisms on mobile browsers that would cause double scaling if
>> left enabled.
>>
>> scale-ems
>>
>> We do have a single opt-in option, <meta scale-ems> that works the same
>> on Desktop and mobile. We think most sites will be able to use this. If a
>> site has been consistently coded with rem and em units, adding the
>> single <meta something="scale-ems"> would cause the site to just start
>> obeying the OS-level font setting. No messing with env() needed. Yay.
>>
>> If scale-ems is great, why provide env() at all?
>>
>> Because, unfortunately, not all sites are coded with (r)em. Many major
>> sites are coded in a mix of px and rem, or even all in px. For these
>> latter sites in particular, <meta scale-ems> would do nothing at all. Those
>> sites need env(preferred-text-scale) because they need to surgically
>> inflate parts of the page to respond to user font settings, e.g.
>>
>> .foo { font-size: calc(100% * env(preferred-text-scale)) }
>>
>> .bar { width: calc(200px * env(preferred-text-scale);
>>
>> height: calc(150px * env(preferred-text-scale) }
>>
>> Then shouldn't these sites just change to use rem instead of px?
>>
>> That would be great! But we have to meet the web where it is today, and
>> changing over to (r)em can take years, even for a *single* complex site.
>> If we ever get to a future where sites are all using scale-ems and look
>> good with various user font settings without using
>> env(preferred-text-scale), that would be a big success.
>>
>>
>>>
>>> On Wed, May 28, 2025 at 8:47 AM David Grogan <dgro...@chromium.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 22, 2025 at 7:07 PM Domenic Denicola <dome...@chromium.org>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, May 23, 2025 at 9:00 AM Chromestatus <
>>>>> ad...@cr-status.appspotmail.com> wrote:
>>>>>
>>>>>> Contact emails dgro...@chromium.org, p...@chromium.org
>>>>>>
>>>>>> Explainer https://davidsgrogan.github.io/env-explainer.html
>>>>>>
>>>>>> Specification https://drafts.csswg.org/css-env-1/#text-zoom
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> Exposes a user's preferred font scale to CSS. Currently, it is not
>>>>>> practical for a page to detect if the user has changed their preferred
>>>>>> font
>>>>>> size via the Operating System's preferences. This CSS environment
>>>>>> variable
>>>>>> will reflect the scale chosen by the user.
>>>>>>
>>>>>>
>>>>>> Blink component Blink>Accessibility
>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EAccessibility%22>
>>>>>>
>>>>>> TAG review https://github.com/w3ctag/design-reviews/issues/1101
>>>>>>
>>>>>> TAG review status Pending
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> None
>>>>>>
>>>>>>
>>>>>> *Gecko*: No signal (
>>>>>> https://github.com/mozilla/standards-positions/issues/1229)
>>>>>>
>>>>>> *WebKit*: No signal (
>>>>>> https://github.com/WebKit/standards-positions/issues/499)
>>>>>>
>>>>>> *Web developers*: Positive (
>>>>>> https://github.com/w3c/csswg-drafts/issues/10674) This proposal
>>>>>> started with a request from a BBC developer
>>>>>>
>>>>>> *Other signals*:
>>>>>>
>>>>>> WebView application risks
>>>>>>
>>>>>> Does this intent deprecate or change behavior of existing APIs, such
>>>>>> that it has potentially high risk for Android WebView-based applications?
>>>>>>
>>>>>> None
>>>>>>
>>>>>>
>>>>>> Debuggability
>>>>>>
>>>>>> This can be debugged using existing devtools support by connecting to
>>>>>> a device. We have a plan for making this easier at
>>>>>> https://crbug.com/419595584.
>>>>>>
>>>>>>
>>>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? No
>>>>>>
>>>>>> Initial support will be limited to Android, which has limited
>>>>>> practical ability to respect the OS font scale today. On Windows, we
>>>>>> scale
>>>>>> the entire browser in response to the OS setting, and some followup work
>>>>>> is
>>>>>> needed to support this while not double-zooming.
>>>>>>
>>>>>
>>>>> I'd like to learn more about this from a compat and interop
>>>>> perspective. From skimming the explainer, this seems like a complicated
>>>>> problem space.
>>>>>
>>>>
>>>> Interop: there's a pretty simple fallback for browsers that don't
>>>> support this env variable: env(preferred-text-scale, 1). We have 1p
>>>> and 3p partners that have started to experiment with this variable. They
>>>> needed a good rollout story. We are also thinking about @supports (
>>>> https://github.com/w3c/csswg-drafts/issues/3576#issuecomment-2881619620)
>>>> for env variables to make this easier and more powerful in the future.
>>>>>
>>>>>
>>>>> If we never ship support on desktop, and authors start using this
>>>>> feature, what will the user experience be?
>>>>>
>>>>
>>>> Same as today. Users will continue to use browser zoom on desktop (ctrl
>>>> +/-), which is not a big deal (compared to mobile) because it's relatively
>>>> easy to use and there's usually plenty of screen space to avoid lawnmower
>>>> swiping.
>>>>
>>>> Mobile is where we've heard demand for this feature because authors
>>>> relay their users' subpar experience. We haven't heard about user pain on
>>>> desktop.
>>>>
>>>> If this ends up being mobile only, that is not our desired end-state,
>>>> but it's not catastrophic because the zoom options on desktop are less
>>>> problematic.
>>>>
>>>>
>>>>>
>>>>> If we don't ship support on desktop for 10 milestones, but then
>>>>> suddenly do, what will the user experience be?
>>>>>
>>>>
>>>> No matter when we ship on desktop, whether today or in 10 milestones,
>>>> we'll need to provide an opt-in for authors (explainer has a sketch of
>>>> our opt-in proposal
>>>> <https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/env-preferred-text-scale.md#new-meta-viewport-key-for-changing-text-scale>)
>>>> to avoid definite double scaling on Windows (because of its automatic
>>>> page zoom) and potential double scaling on the other Desktop platforms
>>>> (because they change how font-size:medium is resolved in response to
>>>> the UA-slider).
>>>>
>>>>
>>>> Windows is the most complicated desktop platform for us to add support
>>>> for OS-level font scaling, mainly because Chrome does a full browser
>>>> zoom of both the browser’s UI and the web page
>>>> <https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/env-preferred-text-scale.md#windows-11>in
>>>> response to the OS font slider. We can't unilaterally disable this
>>>> automatic scaling because users may rely on it. So if an author wants
>>>> better control over their page scaling on Windows, they'll have to signal
>>>> to the browser to not do this automatic scaling. When they've signaled
>>>> that, the browser will intelligently populate the environment variable
>>>> (meaning values other than 1 are eligible).
>>>>
>>>>
>>>> The other desktop platforms are degenerate/easier cases of windows; as
>>>> such our proposed opt-in mechanism will handle them properly as well ("for
>>>> free"). Mobile doesn't have any potential double scaling issues (no
>>>> UA-slider to affect font-size:medium), so no opt-in mechanism is needed.
>>>>
>>>>
>>>> If we do ship the opt-in and env var on desktop in 10 milestones, users
>>>> who have changed their OS-level font settings will get improved font sizes
>>>> on sites that use the opt-in and env var. Sites that had used the env var
>>>> just for mobile will not change when viewed on desktop; there will be no
>>>> spontaneous breakage.
>>>>
>>>>
>>>> What we want to ship now, just the env variable on mobile, always
>>>> populated to the value of the OS-level setting, is a small incremental
>>>> platform change, is sufficient to fix the highest-demand problem, is
>>>> required for some complex sites (some of our partners), and doesn't block
>>>> later desktop work.
>>>>
>>>>
>>>>>
>>>>> You mentioned Windows, but what about macOS, Linux, ChromeOS, and
>>>>> Android WebView?
>>>>>
>>>>>>
>>>>>>
>>>> Apologies for the omissions.
>>>>
>>>> Android WebView — this will also be supported at initial launch
>>>>
>>>> Desktop platforms including CrOS – the environment variable will be
>>>> available with this launch but will always return a value of 1, essentially
>>>> being a no-op. As described above, we intend to later intelligently
>>>> populate the value on desktop, which will require an opt-in.
>>>>
>>>>
>>>>
>>>>>
>>>>>> Is this feature fully tested by web-platform-tests
>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>> ? Yes
>>>>>>
>>>>>> This is tested with internal WPT tests due to lack of support for OS
>>>>>> font scale setting in tests.
>>>>>> https://github.com/web-platform-tests/wpt/issues/12725
>>>>>>
>>>>>>
>>>>>> Flag name on about://flags None
>>>>>>
>>>>>> Finch feature name CSSPreferredTextScale
>>>>>>
>>>>>> Rollout plan Will ship enabled for all users
>>>>>>
>>>>>> Requires code in //chrome? False
>>>>>>
>>>>>> Tracking bug https://crbug.com/397737223
>>>>>>
>>>>>> Measurement UseCounter:
>>>>>> https://chromestatus.com/metrics/feature/popularity#CSSEnvironmentVariable_PreferredTextScale
>>>>>>
>>>>>> Estimated milestones
>>>>>> Shipping on Android 138
>>>>>>
>>>>>> Anticipated spec changes
>>>>>>
>>>>>> Open questions about a feature may be a source of future web compat
>>>>>> or interop issues. Please list open issues (e.g. links to known github
>>>>>> issues in the project for the feature specification) whose resolution may
>>>>>> introduce web compat/interop risk (e.g., changing to naming or structure
>>>>>> of
>>>>>> the API in a non-backward-compatible way).
>>>>>> https://github.com/w3c/csswg-drafts/issues/10674
>>>>>>
>>>>>> Link to entry on the Chrome Platform Status
>>>>>> https://chromestatus.com/feature/5328467685801984?gate=6195643460354048
>>>>>>
>>>>>> Links to previous Intent discussions Intent to Prototype:
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOZbSt1dSWUwuFD%2Bu%3DwGXf-ubdgh8K%3D0oj13%3DkrvADSOM41xtw%40mail.gmail.com
>>>>>>
>>>>>>
>>>>>> This intent message was generated by Chrome Platform Status
>>>>>> <https://chromestatus.com>.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "blink-dev" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to blink-dev+unsubscr...@chromium.org.
>>>>>> To view this discussion visit
>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/682fba7d.170a0220.2aa17e.152d.GAE%40google.com
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/682fba7d.170a0220.2aa17e.152d.GAE%40google.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9SnYb4ZXPBJpnqsXzM_kKTAq8TBPjNqQM3%2Bpk8WHYNmw%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9SnYb4ZXPBJpnqsXzM_kKTAq8TBPjNqQM3%2Bpk8WHYNmw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYd%2Bz0rQ8Hx0nENox0skEZEJWEMNw0D3MkJygGy2zo8ftQ%40mail.gmail.com.
