LGTM3
On Fri, May 30, 2025 at 1:11 PM Philip Jägenstedt <foo...@chromium.org>
wrote:
> 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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYd%2Bz0rQ8Hx0nENox0skEZEJWEMNw0D3MkJygGy2zo8ftQ%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/CADsXd2MoXOEYfY1b8Cfwb00QcrHAd6tH%2BxN8vb65M8b7Xx7JYw%40mail.gmail.com.
