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/CAOZbSt0mDh8t1Nv9XySUDPcLgo2e4Kn%3DLw4a-F_dNUjZByR%3Drw%40mail.gmail.com.
