Update: after further discussion with Torne, we've decided on a WebView 
plan, namely that for the time being:

   - 
   
   env(preferred-text-scale) will be set only when the layout_mode is set 
   to TEXT_AUTOSIZING (which is similar to how Chrome on Android works)
   - 
   
   setTextZoom 
   
<https://developer.android.com/reference/android/webkit/WebSettings#setTextZoom(int)>()
 
   behavior will be unchanged
   

We plan to later launch the <meta> opt-in that pages can use to make rem 
honor the OS-level text scaling, including on Desktop. (An older iteration 
of this <meta> opt-in mechanism is described in the env explainer 
<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>
 -- updated standalone <meta> explainer is in progress). When these 
opted-in pages are loaded in a WebView, Blink will incorporate the 
setTextZoom parameter into (r)em, falling back to the OS-level text scale 
setting if the Android app hasn't called setTextZoom. This is consistent 
with the current WebView contract that setTextZoom overrides the user's 
OS-level text scale setting.

On Friday, May 30, 2025 at 10:21:49 AM UTC-7 Vladimir Levin wrote:

> 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 <dom...@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 <dgr...@chromium.org> 
>>> wrote:
>>>
>>>> On Tue, May 27, 2025 at 6:37 PM Domenic Denicola <dom...@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 <dgr...@chromium.org> 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 22, 2025 at 7:07 PM Domenic Denicola <dom...@chromium.org> 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, May 23, 2025 at 9:00 AM Chromestatus <
>>>>>>> ad...@cr-status.appspotmail.com> wrote:
>>>>>>>
>>>>>>>> Contact emails dgr...@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+...@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+...@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+...@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/677ba9de-73b1-41b3-8508-d768d07e3f15n%40chromium.org.

Reply via email to