Re: [w3ctag/design-reviews] Other Spec Review: <meta name="text-scale" content="scale" /> (Issue #1172)

davidsgrogan left a comment (w3ctag/design-reviews#1172)

Thanks for the great detailed review! Responses inline:

> Hi [@davidsgrogan](https://github.com/davidsgrogan), and thanks for your review request.
> 
> Speaking personally, as someone with a vision impairment, this is something I have wanted to see on the web for some time; thank you for working on it!
> 
> We have some feedback on the feature, the explainer, and concerns and suggestions about adoption.
> 
> Regarding the feature:
> 
> * Overall, this seems like a great improvement.
> * Have you considered keeping _only_ `legacy` and `scale` as values, and having the UA (on behalf of, and influenced by, the user, the device, and other factors) decide on what sort of scaling (linear or otherwise) to apply? This seems to be a decision on which the user would know best (possibly also guided by their UA and device).

Yes! The WG resolution and spec text about linear vs non-linear scaling does not require that a UA always do non-linear scaling (the spec draft has it as a SHOULD -- "user agents should scale these other keywords non-linearly to preserve readability"). I suppose you are suggesting that we expand that a bit to say that UAs should determine (based on the factors you list and maybe others) if linear vs non-linear scaling would be best. If that's what you mean, that seems good, I'll put it in the draft.

As for this part
> Have you considered keeping _only_ `legacy` and `scale` as values

Yeah, we decided to keep only those values. But we'll obviously consider any future author requests for other scaling modes.

>   As you say in the explainer, the reason that `text-scale` has to be opt-in is potential breakage of _existing_ sites. However, new sites that are designed with a more adaptive approach to text sizing could be much more robust against whether the scale is linear or otherwise.
>   Have you considered explicitly making this choice up to the UA?

We hadn't considered that. (Unless I've forgotten and @JoshTumath remembers.) But it seems like a great space for UA innovation -- to analyze if the page would scale appropriately even in the absence of an explicit `text-scale`. That would be great. (Let me know if I've understood that correctly.)

> * Regarding the [question as to whether the font size keywords should also scale](https://github.com/w3c/csswg-drafts/issues/12475): we think this makes sense and should be included.

Agreed. To be clear other font size keywords will definitely scale. https://github.com/w3c/csswg-drafts/issues/12475 was about the further question of if they should scale linearly vs non-linearly.

> * We'd agree in expecting it to be very likely there would be significant breakage of existing site layouts if scaling were the default. But out of curiosity: have you done any testing to check on this?

Yes, but we unfortunately didn't document it. So, just now I did a test simulating default scaling at 1.7x and browsed around a bit. baltimoresun.com is a stereotypical example of breakage. The screenshot shows that the headlines and blurbs are cut off, which is bad enough, but much worse is that the user is even _unable to horizontally scroll_ to see the cropped text. We found many examples like this, unfortunately.

<img width="300" alt="scaled baltimoresun homepage" src="https://github.com/user-attachments/assets/125d334e-aaf3-44b5-882f-3699c29d6c6a" />


> Regarding the explainer:
> 
> * It's a well-written document, but it would be really helpful to have more illustrative examples - at least one "before and after" style example - of the effect of the proposal.

1000% agreed. Will fix.

> * Our read on the proposal is that it _would_ affect the base font size on desktop too (i.e. as well as mobile) - but [the table](https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/meta-text-scale.md#comparison-of-legacy-and-scale) makes this seem a little unclear - could you clarify?

Yes, it would affect base font size on desktop too. That's what we were trying to say with the "font-size: medium on desktop" row having "legacy: 16px × UA-level scale" vs "scale: 16px × OS-level scale × UA-level scale". (Suggestions for making that clearer are welcome. Perhaps we should explicitly say that font-size:medium is the base font size?)

> Concerns regarding adoption:
> 
> From experience working with developers, the huge barrier this has to get over is that people need to opt in. It may be very hard to persuade busy development teams to opt in without some substantial resources to help them get started with such layouts. These may include:
> 
> * Guidance for authors in the spec.
> * [WAI Tutorials](https://www.w3.org/WAI/tutorials/) for authors to make more adaptive/robust/accessible layouts.
> * Making PRs on established projects such as
>   
>   * React Starter
>   * Svelte
>   * anything to do with bootstrapping projects
> 
> Getting this into the default `<head>` for projects will help achieve adoption - but it will also need some helpful resources for busy developers to ensure that the DX is still good.
> 
> You might want to contact [Docs CG](https://www.w3.org/community/docs-cg/) to see if they can assist you with writing the developer documentation.

Yes, agreed. We are planning a bit of a PR push once the feature has shipped and stabilized for a few milestones. I see that https://www.w3.org/WAI/tips/developing/#write-code-that-adapts-to-the-users-technology is a candidate for where some instruction might live. We also have a few ideas for chrome's developer tooling to make this easier on authors, one of which we already implemented (simulating changing the OS text scale factor.) I'd considered pushing vscode to get this meta tag in their default HTML template, similar to meta viewport, but attacking it at the framework level also seems prudent. Thanks for the suggestion.

> We look forward to hearing your thoughts on this.
> 
> Thanks to [@AutoSponge](https://github.com/AutoSponge) in APA WG for the benefit of his experience managing development.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1172#issuecomment-3667481287
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1172/3667481287@github.com>