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.
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?
>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.
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/CAM0wra81Bw1Z%3Dy%2B%2B4E3COHe8yFfLs9AkBcpyBg90vTk8dXG9Nw%40mail.gmail.com.
