Rethinking Text Resizing on Web

This is also important for being able to show normal size text on smaller phones. I&#x27;ve got a 5.8&quot; screen and basically every app is visually broken, with about 10% functionally broken as well. Every web or app designer should get an iPhone Mini or similar, crank the font size accessibility setting, and make sure everything works. In particular, any text that is truncated needs to have a line-wrapped version available somewhere, every page with content needs to be scrollable, and the input box needs to be functional (e.g. it must show at least one line) when the keyboard is out.<p>On web, use `overflow-wrap: break-word` and make sure your header can shrink.

The vertical candybar formfactor of smartphones really is just a total nightmare when it comes to usability. Coupled with the fact that touchscreens are a nadir of effective user input design, it really feels like phones were a regression in every respect <i>except</i> fit-in-your-pocket portability. Here&#x27;s hoping that whatever eventually disrupts smartphones turns out better.

The problem with most &quot;resize&#x2F;zoom&quot; solutions is that they assume everything needs to be resized, which is not ideal. This approach makes well-known buttons and text unnecessarily large, reducing overall visibility.<p>For Gmail, I use this small extension [1] that only resizes the message text and subject line, keeping other elements like the search bar, buttons, and labels unchanged. I wish every website does this way.<p>[1] <a href="https:&#x2F;&#x2F;chromewebstore.google.com&#x2F;detail&#x2F;email-zoom-text-reader-by&#x2F;kllnaciiffhiobclgfhldgobnoajnbpa" rel="nofollow">https:&#x2F;&#x2F;chromewebstore.google.com&#x2F;detail&#x2F;email-zoom-text-rea...</a>

Looking at the example near the bottom of the page, they seem to be making the common mistake of thinking that if I want 16px text turning into 32px, then I also want 24px text turning into 48px.<p>I really really don&#x27;t. I&#x27;m already much shorter of screen space than the designer planned for, and huge headings make that much worse.

I find the experience of Airbnb user hostile. The last time I checked, the app pushed irrelevant search results on me with no option of turning that off. Now they give advice on UX? The advice might be sound, but it comes from an authority in marketing, not UX

Using the default 12px text size is a pretty good indicator that a website&#x27;s entire engineering team is under 40.

There’s a graphic with giant text that claims that “200% Zoom = 1&#x2F;2 Viewport”.<p>If I’m understanding them correctly isn’t it worse than that? 200% Zoom leaves you with 1&#x2F;4 of the space you had at 100% I think.

I guess nobody bothers to mention the text size issues on this very site anymore knowing it won&#x27;t be fixed.

<a href="https:&#x2F;&#x2F;archive.ph&#x2F;vYY8I" rel="nofollow">https:&#x2F;&#x2F;archive.ph&#x2F;vYY8I</a>

While not directly related to the post, I have found that a surprising number of people with limited vision do not know about iOS’s Display Zoom feature, which is much better supported than Dynamic Text given the former only relies on developers handling different screen resolutions properly.<p>While it doesn’t blow things up by 200% like what AirBnb’s approach supports, it’s a quick way to make a big difference for people.

&gt; the same screen shown at 200% showing the search and categories are cut off entirely and not able to even see the first listing.<p>Well, duh, that&#x27;s because you retain so much useless whitespace where you can only fit a single short word &quot;Display&quot; (~30% width vs 70% whitespace) in a line<p>And the example in the video isn&#x27;t much rethinking - instead of hiding crucial info with &quot;California&quot; becoming &quot;Ca...&quot; not only can you fit more info if you squeeze the overly wide ... (so readable Cali would fit), but also you could expand into the half-empty 3&#x2F;4 lines, where a price unit could also be moved to a separate column instead off &quot;night&quot; being repeated, that would fit the whole California right there at high text size (and again you could fit more relatively valuable text if you remove some of the relatively less valuable spacing)

The tldr is basically that if you size your text in `rem` but everything else (the grid, whitespace) in `px`, you allow the user-agent to increase font size _without_ zooming in everything else. Which can be useful for those who can&#x27;t read small fonts, especially on small (mobile) screens.<p>If you size _everything_ in rem, then user-agent font scaling ends up doing pretty much exactly the same thing as user-agent zooming, which is less useful than allowing user-agent font-scaling and zooming to do _different_ things, each of which may have a different context of use.<p>This seems obvious once said -- but is there an argument against it? I don&#x27;t think it is the common advice -- I feel like there was a _lot_ of talk about sizing _everything_ using `rem` for accessiblity (that began back before most people knew about sizing anything with rem). And that this is what most people (including me) are doing -- using rem for all sizing. And what many design frameworks (bootstrap?) have and are doing.<p>It&#x27;s making me think the standard advice should be as in OP instead, rem for text, px for everything else. And of course to maximize accessibility benfits you then need to actually test under text-scaling (on small screens), but to begin with (and avoid the need for a huge refactor later), it seems like you should start with `px` for grid spacing etc, contrary to much current common conventional wisdom?

Websites should set the base font size to the browser default, and scale that <i>only</i> for text <i>other</i> than body default: larger for headings, smaller <i>only</i> for truly superflous text, or notional elements such as super- and sub-scripts.<p>Readers who are aware of the ability to set a browser-level font default will be annoyed at any other behaviour or choices. Readers who are <i>unaware</i> of that capacity, the overwhelming majority, are a lost cause regardless, but will likely use other mechanisms to zoom pages to a comfortable reading level.<p>Otherwise, Air UI&#x2F;UX are Beyond the Bend.

&gt; Moving from pixel-based values to rem units as a company-wide change in CSS practice can be a significant challenge, especially when working across multiple teams.<p>What bothers me is why does a company find itself in this situation. Why does it not include web accessibility in the building of its product from the start? Why do designers talk to developers in pixels instead of checking how their design decisions on different screens, in different browsers, and with different accessibility settiongs?

200% font scaling sounds so innocent and fundamental. Is it hard because they waited too long and have too many teams &#x2F; frontend systems? Or is font scaling CSS just tough for everybody?

Things were heading in the right direction in the early 2000s. Browsers had default font sizes built in and everything else could be scaled with the font using the em unit. Then browsers made zoom increase the pixel size. That was it. They fucked it. To this day it&#x27;s still broken.<p>Now you get phones where the zoom in does something utterly useless and people still can&#x27;t reliably set their own font size.

I’m not sure if this is related, but recently I began to *omit* this viewport &lt;meta&gt; tag from the &lt;head&gt; of my sites, so that I can pinch-and-zoom instead of having a fixed scale set and needing to mess with text size controls:<p>&lt;meta name=&quot;viewport&quot; content=&quot;width=device-width, initial-scale=1&quot; &#x2F;&gt;<p>I find it makes sites much more pleasant to browse.

I used WAVE browser addon on the Airbnb website and it showed 37 errors, 1 contrast error and 98 alerts. And they want to talk about accessibility?<p>Accessibility aside, their website is an unusable, resource-hogging mess which doesn&#x27;t even use proper cursor pointers for &lt;a&gt; tags and tries to mess with my scroll.

I miss the way the original Opera handled scaling which was to resize the entire draw surface after rendering. So everything, including pictures, kept the same relative sizes and there was no reflow or jumping around. That meant you had to horizontal scroll but so what?

Apple’s own webpage[0] doesn’t properly resize text on my iPad using safari with the text set to 125%.<p>[0]: <a href="https:&#x2F;&#x2F;www.apple.com&#x2F;shop&#x2F;buy-ipad&#x2F;ipad-pro" rel="nofollow">https:&#x2F;&#x2F;www.apple.com&#x2F;shop&#x2F;buy-ipad&#x2F;ipad-pro</a>

Image and text resizing both seem rather broken in HTML&#x2F;CSS. Especially images. If I care somewhat precisely about how a mixed-media site is going to show on different screen sizes, I have to set up React and start calculating stuff based on window dimensions.

I think the change in browsers from text-only zoom to whole-page zoom was a huge mistake. At least Firefox still gives you the option.<p>Front-end developers: test your layouts in Firefox with &quot;Zoom text only&quot; set. It should work for all settings from 50% to 200%.

The solution to text resizing according to AirBnB engineering is CSS in JS.<p>These frontend web dev tendencies are devastating to me. I feel like these people haven&#x27;t lived through the CSS Zen Garden days or the fight for semantic HTML.<p>I still love the web, but the current frontend culture is batshit.

Here&#x27;s what I used in my app [1] to do scaling with <i>CSS only</i>, no breaking points or JS complicated needed. All sizes of fonts and elements (like cards) are derived from the visible viewport and the golden ratio:<p><pre><code> :root { --gr: 1.618; --font-baseline: clamp(16px, calc(5.725vh + 5.725vw), 72px) !important; --font-baseline: clamp(16px, calc(5.725svh + 5.725svw), 72px) !important; --baseline-unit-1: var(--font-baseline); --baseline-unit-2: calc(var(--font-baseline) &#x2F; var(--gr)); --baseline-unit-3: calc(var(--font-baseline) &#x2F; pow(var(--gr), 1)); --baseline-unit-4: calc(var(--font-baseline) &#x2F; pow(var(--gr), 2)); --baseline-unit-5: calc(var(--font-baseline) &#x2F; pow(var(--gr), 3)); --baseline-unit-6: calc(var(--font-baseline) &#x2F; pow(var(--gr), 4)); --baseline-unit-7: calc(var(--font-baseline) &#x2F; pow(var(--gr), 5)); --baseline-unit-8: calc(var(--font-baseline) &#x2F; pow(var(--gr), 6)); } </code></pre> (Initially there was no `clamp()`, but I had to concede that point for a better UX on really large and really small screens.)<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40408418">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40408418</a>

The newly standardized css `zoom` property might help with this.

AirBnB&#x27;s designers have trouble understanding em and rem that have been part of CSS since at least 1999? I wonder what they do in their professional lives.

I honestly don&#x27;t understand what the whole issue with web design is about (it&#x27;s as far away as possible from my domain of expertise, so this is a statement of ignorance, not of arrogance).<p>A &quot;motherfucking website&quot; without any css nor js is perfectly readable and usable on <i>all</i> devices and browsers. Users can select their preferred font sizes, and even colors. It is just like an ebook, that is readable everywhere, and responsive with user-chosen display setups and settings. What is the problem, then? Some websites want to look &quot;fancier&quot;, and then they specify styles in manner that is incompatible with some usage patterns? This is an entirely self-inflicted problem. The problem did not exist in the first place, they created it.<p>I have real trouble accepting that &quot;web design&quot; is not a bogus and fully useless human endeavour. I hope someone around here enlightens me to the contrary.

&gt; extremely impossible<p>seriously?

I would recommend reading Josh Comeau&#x27;s brilliant article[0] on this subject, I prefer his more intuitive approach for deciding when to choose `rem` or `px` for CSS values.<p>For example, from this Airbnb article:<p>&gt; In the case of Airbnb, the team decided to prioritize the use of rem units specifically for font scaling, rather than scaling all elements proportionally.<p>This can lead to undesirable outcomes as sometimes spacing between elements can have a functional purpose, e.g. making it easier to vertically separate one paragraph from another. If you use `rem` solely for font-size and nothing else users with `32px` as their default font-size would not have the necessary amount of space to help discern one paragraph from another in this case.<p>PS It looks like they use Linaria, one can simplify the transition from `px` to `rem` by declaring this helper function and using inside their `css` rules:<p>```ts<p>export const px = (...spacing: number[]) =&gt; spacing.map(s =&gt; `${s * (1 &#x2F; 16)}rem`).join(&quot; &quot;)<p>&#x2F;&#x2F; Example usage<p>const styles = css`<p>p { &#x2F;&#x2F; This inline padding is for aesthetic reasons, we don&#x27;t want this to scale<p><pre><code> &#x2F;&#x2F; with users preferred font-size padding-inline: 16px; &#x2F;&#x2F; This serves a functional purpose, it will become `0.5rem 1rem` &#x2F;&#x2F; which should match `8px 16px` if users are using the default 16px font-size margin-block: ${px(8, 16)};</code></pre> }`<p>```<p>[0] <a href="https:&#x2F;&#x2F;www.joshwcomeau.com&#x2F;css&#x2F;surprising-truth-about-pixels-and-accessibility&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joshwcomeau.com&#x2F;css&#x2F;surprising-truth-about-pixel...</a>

just use tailwind, and everything else just ask ai