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.
