- From: Daniel Herr via GitHub <noreply@w3.org>
- Date: Tue, 14 Jul 2026 21:06:01 +0000
- To: public-css-archive@w3.org
My feedback as follows is 100% from the perspective of a user, not a developer, as someone who has used the Web with increased font size settings above the default on desktop browsers for many years. I have attempted to comprehensively address the arguments I found made in favor of the opt in meta tag. From the explainer: > Browsers can’t simply apply the user’s system-level font scale to all web pages, because – if they did – many existing page layouts would break, causing content to be invisible or to lose interactivity. >Authors would need to test their websites before opting in to see if they need to adapt them to protect from overflowing text or content that is too squashed to be able to read or view easily. Based on my experience, while some unusable UI does occur rarely, 99% of the time, the breakage caused by having an increased font size is purely cosmetic, things like the body being too wide and causing the page to be horizontally scrollable, text in a button wrapping to the next line, and similar cases in which the UI remains fully functional. That is mainly due to the forgiving nature of HTML/CSS, where the page becomes scrollable and contents overflow their container when the developer didn’t anticipate that scenario. This is in contrast to various native UI frameworks, where increasing system text size preferences above the default often results in unusable UI. > You could make the argument that users on desktop browsers can already change the UA’s initial font size in their browser settings, so there’s already a risk that websites could break. That is true, but the vast majority of users don’t do that (compared to approximately 36% of users on mobile OSs), so authors are much less likely to receive complaints about broken content, and therefore are less likely to be aware of it. That to me is a good argument against an opt in. This is indeed already a problem for the stated small portion of desktop users. But making an opt in for mobile means that the problem would remain often ignored for desktop users. If instead ~40% of a website’s users experienced the visual glitches caused by increased font sizes, that would provide a much greater impetus for web devs to actually fix the problem instead of ignoring the users affected by it. > Also, desktop browsers tend to have large viewports, so content is unlikely to get squashed. Authors are not used to dealing with scaled up text on small mobile-device-sized viewports. That makes sense if the amount of content or UI being presented is the same on different screen sizes, which is usually not the case. A laptop webpage has more space available than a phone, but websites usually respond by putting more stuff on the screen. > After gathering feedback from authors, we don’t believe pem units are useful. Authors we spoke to described that they are already ‘doing the right thing’ by using existing font-relative units like rem and em, so they would not like to change their pages to use pem everywhere; they would like to continue to use rem and em and are surprised to learn that browsers do not already use OS-level text scales for the UA’s initial font size. As this states, the authors who use relative units are already trying to respect the user’s preferences, so browsers should just do it. The authors who don’t are using hardcoded px font sizes, which wouldn't be broken by changes to the default font size, only broken where users set a minimum font size. So please reconsider requiring an opt in, and just make respecting the OS level text scale the default behavior. As an aside, personally, I would like respecting the user’s preferences to be the default in most cases, not just this one. There is also a comparison to be made with the meta opt in for dark/light system theme. In that case many webpages don’t include the meta tag, and so tens of millions of users have gone out of their way to install extensions which force websites to respect their preference. I think it's pretty clear that many users prioritize respecting their preferences over the possibility of visual flaws, and I would ask you to consider doing likewise in general. -- GitHub Notification of comment by DanielHerr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12380#issuecomment-4973992853 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 July 2026 21:06:02 UTC