blog/never-use-px-for-font-size

[utterances-bot]

Why you should never use px to set font-size in CSS - Josh Collinsworth blog

Many developers seem to believe there's no difference between px and other CSS units. Let's dispel that myth, for the sake of better accessibility.

https://joshcollinsworth.com/blog/never-use-px-for-font-size

[meksone]

Very interesting article!

[rgie]

great read! Still using px till now it's because of clients preferences.

[francis-vila]

I tried it out and it's not as bad as what the article leads us to believe.

This snippet gives identical results for px and em, however much I zoomed in and out, or changed the display settings (Firefox on Windows 10): <p style="font-size:16px">font-size:16px</p> <p style="font-size:32px">font-size:32px</p> <p style="font-size:1em">font-size:1em</p> <p style="font-size:2em">font-size:2em</p> So I think people working on browsers have adjusted the size of the px fonts according to the zoom factor. Seeing that the px is no longer equivalent to a hardware reality, there's no reason not to.

The only difference came when I added a wrapper. Indeed the px fonts remained unchanged, while the em ones were magnified. <div style="font-size:200%"> <p style="font-size:16px">font-size:16px</p> <p style="font-size:32px">font-size:32px</p> <p style="font-size:1em">font-size:1em</p> <p style="font-size:2em">font-size:2em</p> </div> I can't remember ever using a container to zoom on font sizes, but it's interesting to know anyhow.

[josh-collinsworth]

@francis-vila I have to assume you did not change the browser's font size; if I use that first demo and change Firefox's base font size to 44px, this is what I see:

That would explain why you don't see the difference unless using a wrapper; if you don't change the browser's font size, you're only working with zoom. Adding a wrapper that sets the font size to 200% is essentially the same as making the browser's font size twice as large.

[1127]

In my opinion, this is fake news and scruples ... if you use px and zoom in/out the font size changes just as you'd expect. The author claims that 20px is 20px no matter what- that simply isn't true - might have been 10 years ago but that's not how browsers work these days... am I wrong?

[nathanredblur]

Why does this matter if, at the end, the user will use the zoom function in the browser? It's easier for the user to find the zoom control in the browser and reduce the mental load for the developer about think how to make the site looks good when the font-size change and do that math to convert pixels from Figma designs to rem or em. https://benfrain.com/just-use-pixels/

[meksone]

I think that using relative sizes is a good design practice; we know that is faster and simple to zoom, but not all user can, or want, zoom. If you use Windows, and simply change the font size setting to 125 or 150%, you not simply zoom the applications (Chrome and webpages included), but you're only resize the fonts. So, if you have designed a site without taking care of this aspect, your work will be ruined. You can't (and shouldn't) design a site thinking it like a printed media.

Why does this matter if, at the end, the user will use the zoom function in the browser? It's easier for the user to find the zoom control in the browser and reduce the mental load for the developer about think how to make the site looks good when the font-size change and do that math to convert pixels from Figma designs to rem or em. https://benfrain.com/just-use-pixels/

[josh-collinsworth]

@1127 @nathanredblur I feel you may not have read the post closely enough; zoom is not the only way users change the way the webpage works or the size of text.

Users can, and do, and in many cases, need to set their own font size. By using px units for font-size in CSS, we take away that ability. And we should not be doing that, or forcing them to use zoom instead if that's not what they want, or need.

[josh-collinsworth]

@1127 To clarify the "20px is 20px" comment: what I mean is, px units are based on whatever the browser is currently treating as one pixel. And yes, when you zoom in, that gets larger.

But zoom isn't where the issue lies, as the post details. px units only scale with zoom; they do not scale with the user's font size preference. In fact, px units override that preference. That's the point I was attempting to make; a value set in pixels will not be relative to font size, and so it will not scale up and down as font size changes.

[hayyaun]

Please correct me if I'm wrong: using em will end up unmanageable nested font-size in DOM. so there is no use for it. so using rem will help having better user experience on huge screens. using rem considered as 16px for spacing like margin and padding and even sizes will improve the design. But there is a question? why we don't have such a thing like rem in ReactNative? Isn't rem and specially em one of the things that makes website designs much more breakable than mobile ones? Isn't that better to handle HUGE SCREENS by @media query?

[1127]

@1127 @nathanredblur I feel you may not have read the post closely enough; zoom is not the only way users change the way the webpage works or the size of text.

Users can, and do, and in many cases, need to set their own font size. By using px units for font-size in CSS, we take away that ability. And we should not be doing that, or forcing them to use zoom instead if that's not what they want, or need.

Sorry Josh - you are 100% right - I thought you were only talking about zoom. It does "fail" as described. Thanks for the article! I'll be using em/rem from now on.

[kleinderg]

“Users can, and do, and in many cases, need to set their own font size,” from author’s comment.

In what cases do they need to? Browsers have increased the discoverability of the zoom and have been keen on burying the font size options deeper into their settings. There are discussions on needing to for accessibility reasons, that the visually impaired may be more likely to change the browser default, but I’ve never seen substantial quantitative evidence pointing toward this as the preferred or more common method of satisfying that group’s needs.

(I speculate that, if enough users did so, browser’s developers would not have been so keen to bury the setting further and further into advanced settings.)

I know these arguments often default to some point like, “It’s not hard to and users could change the setting so why not cater to them?” But. There’s little quantitative evidence for anyone to claim someone should. A decade ago, when browsers’ zoom feature was not as foregrounded or reliable, sure. But for anyone not developing for ≈IE6 this becomes a very hollow recommendation.

[DerKoun]

While I agree with the core recommendation of this article I'd like to clarify that PX has been a physical unit specified as "1px = 1/96th of 1in" for years, long before display resolutions skyrocketed. It has nothing to do with screen pixels.

[kartofelek007]

If the user wants to increase the font, why not increase the icons and others elements? With that - why they not use zoom instead? I think this is not important like in IE5-6 era (bacause these old browser zoom only font-size), because most users use fingers to zoom, mouse wheel etc. And if they cant increase font-size on your page, It cope by doing zoom.

[francis-vila]

• do they need to set their own font size?
• why do they not use zoom instead?

They can and they do. Why they do it is another question. Whether the feature is relevant or not is for the browser to decide. Is it worth changing one's habits for a minority, adding in pesky dots into font sizes (1.2rem instead of 20px), with conversion approximations to boot ? I guess it depends on how many readers we have.

[josh-collinsworth]

To all the people arguing that users can, or should, or do just use zoom instead of changing the font size:

1. It is not the same thing. That is the entire point of this post. Sometimes users want a bigger font, without making other elements larger.
2. To tell a user how they should use what we build, rather than accommodate for how they want or need to use it, is, categorically, ableism. It is literal discrimination. We should not be at all comfortable either assuming we know how our users use what we build, or telling them they're wrong for doing it the way that suits them best.

[kleinderg]

It is not the same thing. That is the entire point of this post. Sometimes users want a bigger font, without making other elements larger.

Of course it's not the same thing, but they solve functionally the same inherent problem, especially if you're talking about it for accessibility reasons.

To tell a user how they should use what we build, rather than accommodate for how they want or need to use it, is, categorically, ableism. It is literal discrimination.

Restricting the user's autonomy is neither ableism nor discrimination. If changing the font size was the only option, the primary option, or even the option browsers seemed to prefer/advance over the other, then it might be, especially in terms of restricting access to a solution oriented toward the visually impaired.

Absolutely, a decade ago, I'd have agreed that restricting the only solution would be these things. It's an assumption, for sure, to assume that browsers' foregrounding and improving the zoom feature was a decision made based on research and insights into their visually impaired users use of the browser, but I'm hoping it's a well-informed one. That the font-size settings are buried deeper than browsers' zoom features, I think, should be telling enough about their users' needs and how well this solution solves that problem.

We should not be at all comfortable either assuming we know how our users use what we build, or telling them they're wrong for doing it the way that suits them best.

You know, these claims you make (and especially being as wild as to call the alternative ableist and discriminatory) are relying heavily on assumptions. They were built on best practices for less-modern browsers, for sure, but that there's such steadfast push as to imply irresponsibility for not following these recommendations... There is, from what I can find, very little substantial quantitative research on users' use of the font-size setting in any modern context. In the past, prior to the advancement and foregrounding of the zoom feature. That you're so making these claims without any of that evidence means you too are operating under a hefty assumption.

It seems more irresponsible to be pushing supposed best practices without any real, recent, substantial, quantitative evidence. Sheep-leading and clickbait-ish.

Without that evidence, really, the argument comes down to 'literally any user could be doing this and we shouldn't make that choice for them'. There's an argument as to whether that's good or bad to restrict the user's autonomy, but the same would even apply to knowingly making CSS decisions that might interfere with a user's darkmode extension, ad-blocking preferences, etc. It's a decision on the part of the developer/team and it certainly doesn't make someone an ablist or discriminatory for relying on the browser's foregrounded tool for tackling the problem as it stands for the visually impaired.

I would love to see whatever category you're referring to that emboldens you to call a developer/team at least 'categorically' ableist and discriminatory for relying on a valid solution to the real problem that solution aims to solve.

EDIT: Granted. If you can provide considerable (and recent) enough quantitative evidence to support that changing the font-size over using the browser's foregrounded zoom feature is the "needed" solution (because want doesn't make for ableism or discrimination), please do. Otherwise I will consider this (and encourage others to consider this) as relevant as the other articles that well proclaimed the same... in the time of development for IE6.

[josh-collinsworth]

@enklein There is a big misconception here that you keep embracing, which is that this advice is outdated. It absolutely is not. I have actual acquaintances with real visual disabilities who now, this day, in 2022, on the most up-to-date browser, need to change font size and not use zoom, because zoom does not fit their needs and changing the font size does. Zoom causes the web to be unusable for them; changing the font size does not. Zoom has side-effects that font size adjustment does not. Please stop insisting zoom is a substitute; it isn't always.

What would you say to those people, exactly? That the only way they can use the web is wrong? That the web isn't for them? That they are outdated? That we shouldn't have to consider them because they use the web in an uncommon way? None of those are acceptable answers.

Both options exist for a reason. A setting is no less valid based on where it is in the UI. A user's needs are no less valid based on how common they are.

That is ableism; "most people don't do it that way, so we shouldn't consider them." "That's not really the right way to do it, so we don't have to cater to them."

Any further posts insisting otherwise or arguing this point will be hidden.

[1127]

Seems to me this is like wheelchair ramps - at first people were like "That's dumb hardly anyone needs that!" but now, decades later, they are everywhere and no one cares/minds - the additional cost is minimal and it is expected. Able-bodied people use them sometimes too and it doesn't matter.

So I think the article is saying "hey developers, it takes no more effort to type 'em' instead of 'px' so use that instead and it will help some people who need it" - I'm not going to redo the thousands of CSS files out there (unless my clients are going to pay me) but going forward, I'll make a concerted effort to spec font sizes in em.

[kleinderg]

I really vibe with 1127's attitude and it sounds like I really am in the wrong. As much as I'd love to groan over the implication that my cravings for empirical over anecdotal evidence imply that I'd tell people their way of using the web is wrong (and I'd love to groan, because that's not cool man).

It's really not been hard to use this in practice when there are literal Figma plugins for the design side and NPM packages for the dev's side to make using relative units a breeze.

I'd love to see a better browser-first solution for this kind of thing. Especially if the foregrounded zoom feature is not so much a substitute, if it's as difficult to find the empirical evidence I'd really love to see on it, and for the the innumerable articles like this one echoing a practice that's been echoed for... well-over a decade?

Though if, in another decade, you revisit this and find the issue still present and feel compelled enough to write on it again -- an anniversary piece, perhaps, I'd be really keen to see how not using responsive units can break a UI. The codepen embeds sell that the experience for those that rely on font-size settings changes could be subpar, but it's still hard to believe that after this long whatever feature that Google-pours-jaw-dropping-amounts-of-money-into-the-production-of's browser foregrounds isn't cutting it. It's as disappointing to me as I imagine the grumpus naysaying replies of mine have been to Collinsworth.

[kartofelek007]

"It is not the same thing. That is the entire point of this post. Sometimes users want a bigger font, without making other elements larger." Ok. Then why you want create entire page in em/rem? You want emulate entire zoom by font-size?

Yes - em/rem give you more option. For example scale entire page on different screen (vw). But sometimes this may be wrong (some external plugins is writen in px, some clients dont want their page to scale etc, scaled em/rem is more difficult to use in JS).

Another thought. If you look at statistic, px is most used unit and users have gotten used to it. How? Maybe set default zoom in browser, use additional app, some plugin for this (like read mode in safari). If you do something different compared to the rest of the internet - sometimes it can be to your disadvantage. Most pages (included most popular - for example twitter, google result etc) is scaled only by zoom. If you use want bigger pages, should set the default zoom in browser. But your page use font-size as zoom. User will get 2x zoom.

I dont say em/rem is bad. Its super useful. rem - if you want scale entire page (some layout is very hard to code without this technique). em - if you want scale single component (or entire page - but you must be good in this stuff). px - if you dont want scale with vw, ch - if you want create element baset on characters in line etc.

in my opinion nowadays you can use all units and your argument is not most important. The user will easily manage anyway.

Ps1. It is a pity that this topic does not appear in the annual surveys about css/ux Ps2. Maybe we should create big and definitive survey to test this subject. Ps3. I do some quick test on phones:

On Samsung S21:

• vivaldi mobile : only option I can find is "scale text". Change this change all font-size - even in px. But lots of layout is broken after this (for example login by google on twitter)
• firefox mobile - same as vivaldi
• edge mobile - same as vivaldi
• chrome mobile - same as vivaldi

On xiaomi mi3:

• samsung browser - change font size change font in px
• firefox - change font size change fonts in px
• chrome - same as above

And on both phone - change font size in system change font size in px

[josh-collinsworth]

• Our own ease of use is not a good reason to choose implementation details; we build things for our users, not ourselves.
• Using ems and rems does not lock you into scaling the whole page up and down with font size. The post covers this. There are times to use px. I'm not arguing you should use em and rem for everything, but definitely for font-size.
• Most importantly: even if most of the internet is currently inaccessible, that still doesn't mean we should make our products inaccessible, too. That argument is basically "disabled people have gotten used to being disregarded, so we should keep disregarding them so they're not surprised." Predictably broken is not better than surprisingly usable.

Finally, to clear up one last misconception there: the user can set font size in px. Most likely, that's what their browser, device, and/or OS will offer. That's fine. That's not the same as us setting it in px.

If the user chooses 20px and I choose 1rem, they get their preference; 20px.

If the user chooses 20px and I choose literally any other px value, mine completely overrides their choice.

[calvinmorett]

Great article, thank you for the push. This is something that I've probably have been avoiding, farewell my beloved pixels.

In terms of responsiveness + legibility, the slider example made me think about the need for minimum font sizes. Using pixels might be the solution for responsive configurations, so you sort of set a minimum threshold and the text will still be readable for all devices after a certain point. Instead of the always present problem if a really small device, making the font completely impossible to read.

It's great to constantly scale the font up for larger devices, but scaling down might be a problem that can actually be the solution, to use pixels.

[kartofelek007]

Yep I know this point. But look at this from other side. If I have problem with font size on internet and most of internet (99%?) use px, i must use "something" to change this size. If I can't use font-size in preferences, then I use "default zoom" or something else. But your page use font-size (from system for example), then on entire internet i will get my prefered zoom, but on your page I will get 2x zoom and I must zoom out. Yes I know, I'm picking on...

Another thing. On eveny mobile browser witch I tested scale font size in preferences also increase font in px on page. Look at this page for example. If you change font-size in chrome preferences on DESKTOP - you cant see any changes, because text have font-size: 14px (but 2 option below there is default zoom). But on every mobile I tested text will change its size regards of em/px.

btw. this is very interested. If you look at top bar (this with green Open button) you notice, that this element is not change (and also have font-size in px). This happend on vivaldi/chrome. On firefox/edge all text is increase

vivaldi default: vivaldi increase scale text: edge scale: chrome scale text: firefox scale:

This may be nice topic to next article. Regards

[myobie]

There is a “user agent stylesheet” applied before the website’s code, and it’s possible that its font-size is not 16px. If you want to support tools that use this UA sheet (or a similar technique), then you can’t use px.

The UA stylesheet is “an old-school feature” many aren’t used to using, but we used to use it a lot before browser extensions existed, like to hide ads (using common class names) or even change the default background color of html. While it’s old-school, some tools still use it. Desktop Chrome’s font size setting (“larger”) and iOS’s dynamic type both use this “before” method and so px defeats them. (And they are not only ones, they are just easy to point to.)

There are other tools (like zoom or even Firefox’s “zoom only text”) which are applied after all stylesheets, and so they will scale up any unit whether it’s px or whatever. These are the tools the vast majority of browser users are familiar with.

I will say the best thing you can do is 1) test using chrome’s “larger” and iOS’s dynamic type and just see how you site looks and 2) talk to somehow who relies on these features everyday. It’s all theory until you see how what you’ve made affects others. Go find out.

And of course there is a real cost to testing and supporting more types of UAs and their features. It’s not free to support every little thing. I always just try to be honest about what I’m choosing to support and prioritize, etc.

And thanks for the article @josh-collinsworth (as you’ve found yet again, px is always a barn burner of a discussion 😅).

[leonp]

I’d have to ask why anyone wouldn’t use relative units by default, regardless of anything else.

By default it’s a more robust, accessible approach – the starting point is that you’ll scale font sizes (and therefore most of your typography) according to whatever you’re given, rather than trying to override it with an absolute pixel setting.

A good example is if someone changes their browser’s default font size from 16px to 20px because generally text is too small on the web.

But as a designer, let’s say I want a 16px size becuase it looks “right”. If I use this CSS: html {font-size: 16px;} I’ll see that, but so will the person who wants to see 20px. However, if I use html {font-size: 100%;} I get my 16px (as will most people, who won’t have changed their browser default font size), but I’m respecting the person who wants 20px.

Similarly, we can be reasonably certain that a relative unit works with the device or screen that’s viewing content at any given time; we can only be sure an absolute unit works with whatever screen you’re designing on.

We even have rem (for how long?) to make it easy to size relatively but do the maths in absolute terms.

As a developer bonus, managing your type scales, borders, margins and padding is a lot easier using relative units.

[YaroslavFrolov]

Totally disagree with article. My rule of thumb - "Use pixels everywhere if possible. Use em only near text!! (say, paddings inside button, margin between li-items, and so on)". That's it!

• 1. I don't know anyone who even knows how to change default font-size in browser; or know if it's possible at all;
• 2. For me - almost all web-sites are too small for reading. And I'm using the "ctrl +" or pinch-zoom. And this zoom-setting is individual per particular web-site.. pretty convenient. And everybody I know - uses this method.
• 3. I've tried to change default font-size - and almost all web-sites become ugly. And opposite, the "ctrl+" or "pinch-zoom" does not break web-sites.. they still have same layout/view proportion - as expected and as was developed by designers.
• 4. You did not consider the development-experience (aka DX) of using em/rem. The explicit is better than implicit! As a developer, I don't want heavy-calculation in my head during making some quick-hot-fix after another smart-guy on 2-year-project. You always have to think about next developers after you who will be supporting project. Development from scratch with dozens of redundant abstractions is pleasure and easy. But senior must be able to write code that every junior will understand after couple of years (it's pretty difficult - writing simple and maintainable code as much as possible).
• 5. There is a special place in hell for guys who use em/rem in media-queries, or who like programming via preprocessors (scss, etc)
• 6. Using "hardcoded" pixels over long distance is more robust, reliable, cheaper, maintainable and supportable way for project, for developers, for businesses and for users. And we can be sure that our layout won't break if someone will change the default font-size.

[josh-collinsworth]

@YaroslavFrolov You can "disagree" if you like, but this is not a matter of opinion; this is a matter of user accommodation. We're not talking about something subjective here, like whether dark mode is better than light mode, or what the best coding font or editor theme is. We're discussing real decisions that have a real impact on users' lives and experiences with the things we build. To your points:

1. Not personally knowing people who do things does not mean there are no people who do them. I don't know any blind people, or any people who use crutches, or anybody currently in a wheelchair. But I am certain they exist, and have needs and preferences to accommodate.
2. I'm glad you have a method that works for you. What I am advocating for is everyone be given a chance to use the method that works for them. Using em and rem for font-size and media queries allows everyone to do what works for them.
3. This is actually an argument for doing what I'm suggesting, not against it. If you upsized the text and things broke, it's because the developers on those sites failed to write either font sizing or media queries (or both) properly. And besides, just because most people are doing it wrong is not an argument that nobody should be doing it.
4. DX is important, but it does not override user experience. Locking a user out of their preferred (possibly needed) option is not an acceptable tradeoff for better experience for a developer. Again: we do not build things for ourselves; we build things for our users. Plumbers don't put the toilet in the kitchen just because it makes their experience better. Electricians don't put all the outlets in one room in the house because it makes their job easier. Developers shouldn't default to px just because it makes their experience better.
5. Using em/rem in media queries is actually much more resilient than px. Using px can seriously mess things up for users who adjust font size, as mentioned in the post. But since you don't elaborate on why, I'm going to pass this over.
6. I don't think this is true at all—they're just units; there's nothing that makes them any of these adjectives—but especially false on the "for users" part. (The only case in which it might be true is if one were using em everywhere; that would certainly be unpredictable and difficult to maintain. But we don't need to do that, because we have rem, so that's a bit of a straw man anyway.)

@YaroslavFrolov That comment is so personally motivated, so full of opinion, and frankly, so far-off on so many points laid out in the post that I considered just deleting it. Ultimately, I decided it was better to address and correct each of these points instead.

You have a way of using the web that works for you. That's great. Nobody wants to take that away from you. But imagine if they did. Imagine somebody writing a fiery bulleted list of why you should not be allowed to pinch and zoom or use ctrl +. Imagine wishing zoom would work for you, but it doesn't on 99% of websites because developers broke it. Imagine somebody telling you but there's a "special place in hell" for people who build the web the way that works for you.

I'm not asking anyone to do anything but accommodate everyone's needs and preferences, and to put the user experience above the developer experience. That's it.

[fuad-tareq]

After reading this article and all the comments for and against it, I've decided to be against it for now.

I was with you and was ready to start changing all my future font-sizes to use rem and em instead of px... that is up until you insinuated that it seems almost pointless to do so without also changing the margin, padding, and border to also use the same. And the worst offender of all, media queries!!!

I'm all for positive changes to development best practices and keeping up with the times... things such as using container queries in place of media queries wherever possible is a great example of this. Incorporating small changes here and there is a no big deal for me (that is why I was willing to start using rem and em for font-sizes after initially starting to read your article).

Where you lost me is at all the other things (margin, padding, border, and media queries) that would also need to be changed to start using rem and em... that is a seismic shift in development (that requires way too much overhead) and no longer a "small change here and there" that I'm not even comfortable making!

Seismic changes like this in my opinion are more suited for browsers to deal with rather than the developers themselves (I see a lot of potential solutions that the browsers can implement to solve the 99% of px-related issues in one go).

In the meantime, I am not convinced that I should even make the switch to rem or em for the font-size because if I did that and then sometime in a year or two from now the browsers come up with a solution for this exact issue, I doubt their solution would incorporate a "half-and-half" website (i.e. a website that's using rem and em for font-size but px for everything else) right off the bat. It is more likely that their solution would be centered towards one or the other, at least initially.

[josh-collinsworth]

@fuad-tareq I feel you may have misread the bit about margin, padding, and border. I actually do think it makes sense to use px values for those, in many cases. It just depends whether, design-wise, it makes sense for those elements to scale with the font size, as stated in the article.

As for media queries: I can promise you that if those use px values for breakpoints, as long as the site is doing any kind of constraining elements by their width, that will be creating a broken experience for some users. I'm sorry that's inconvenient for you, as the site author, but as I've stated over and over again in these comments: that's literally our job. We as developers should not choose things based on how convenient they are for us, any more than a store should decide not to put handicap parking spaces and wheelchair ramps in because it's not convenient for them.

Lastly, the "if browsers come up with a solution" argument is purely hypothetical and, in my opinion, not at all likely. I am aware of no such effort, but even if it were to come to fruition in a year or two (and again: I see absolutely no reason to think that), why would you want to provide users with a broken experience for that long?

[fuad-tareq]

Thank you for the article and your extra clarification Josh. But I still believe this is not a one-to-one accurate comparison to a handicap parking spot for a store. This is more like trying to keep up with every little change browsers make in real-time. It's not inconvenient for me, it's a massive overhead that you're suggesting to throw on the developers lap. Your efforts are wiser spent asking the browser developers to fix the mess that they created instead.

I'm up to date on a lot of things and I like updating my code to make things better and easier, but I know developers who are still using coding practices from 20 years ago. What you're asking is not updating my code practices, it's asking me to replace numbers with letters when doing Math formulas. It doesn't make sense!

Furthermore, you did not even address my last paragraph which makes me believe you're being unnecessarily defensive about your article. Thanks for shedding more light on this issue, but I hope a better solution is developed sooner than later to address this.

[josh-collinsworth]

Comparing accessibility to "every little change browsers make" is a pretty inaccurate false equivalence. The rem unit has been around since IE9 (12 years ago, as of this writing). This isn't a new practice, and it isn't something browsers have messed up; it's something we, as developers have messed up by using the system improperly.

That's the entire point of this article; we've been doing things the wrong way, in many cases, and failing to take all users' needs into account by doing so.

And I did address your last paragraph, but to restate: a) you don't always need to use em or rem for margin, padding, and border; and b) the whole paragraph is pure conjecture and frankly, not at all realistic. Browsers aren't going to "fix" this situation because browsers didn't break anything. We did. Until and unless there's a realistic shift in how browsers handle font sizing (wildly unlikely), it's on us, not them.

[fuad-tareq]

If what you're saying is true, then "We as developers" is completely false. This has nothing to do with "we", and has everything to do with all the thousands of books and professors teaching us to use pixels instead of em and rem (I bet they're still teaching that today). Which means your efforts are better suited changing what's being taught at universities today and helping tomorrow's developers avoid these problems!

browsers didn't break anything.

The browsers most certainly can fix this, can we at least agree on that? If so, how long do you think they've known of and silently ignored this issue? Whatever number of years you answer here, then that's how long they've had to fix this "mess" that was "created" by their ignorance of this issue.

[josh-collinsworth]

If developers refuse to adapt their practice to accommodate all users, then yes, it is the developers' issue. My plumber or electrician or contractor doesn't get to do a horrible job that's against code and say "welp, that's how I learned, not my fault." We don't get to abdicate our own responsibility, either. If we know better and yet we still choose to do nothing, we are at fault.

And again, let me reiterate: this is not a problem for browsers to fix. The browser is working as intended. We are using it wrong.

Here is the water. Drink if you choose.

[fuad-tareq]

You're being too defensive about your article and choosing to agree on nothing. It is quite rude and I will no longer continue this conversation.

If that was your goal, then congratulations, we have agreed on nothing. Thanks for your time. Have yourself a good day.

[kartofelek007]

"We did." Nope. IE6 did. And every graphics program we've worked in over the years and continue to work in to this day. And the browsers themselves, which convert em/rem to px.

"The browsers most certainly can fix this, can we at least agree on that?" Surprisingly, mobile browsers can increase the text described in px. Take a look at the screenshots above. This is similar to "dark mode". Some browsers turn on dark mode on demand, even if the site does not support prefers-color-scheme. It would be possible to introduce such functionality into every browser. And why is it not introduced? It is possible that it has too low a priority (like broken order in grid/flex)? Or maybe because of the way the Internet is, people have learned to deal with this problem in a different way? Unfortunately, I don't know of any real large studies.

[fuad-tareq]

Thank you @kartofelek007 , that is exactly what I have been trying to say.

I firmly believe browsers are in a better position to fix this, should they put it into a higher priority! In the meantime, this article will come in handy for those who cannot wait for the browsers to sort out this mess.

[josh-collinsworth]

Let me restate, for the final time: there is no "mess." Browsers are not going to "fix" this because there's nothing to fix. When you set font-size in px, the browser is working as intended. It's just as if I put opacity: 0.1 or font-size: 1% on the document. I've broken it; the browser has done nothing wrong and has nothing to fix. Literally the only difference between those examples and setting font-size or media query breakpoints in px is who will notice them.

Let me emphasize: this is the way the browser works, is meant to work, and will continue working.

What "fix" would there be, anyway? Would you propose that browsers begin to scale up px values for font-size? Because that kind of complete change of functionality is not something browsers do. In all but the most extreme of cases, a browser has to maintain backwards compatibility to ensure that sites already built and on the web aren't suddenly changing. Many of those sites may have used px on purpose, knowing full well that's how it works, for some reason or another. Browsers don't just go around changing how established properties work without a very, very good reason, and there isn't one here.

You can indulge in the made-up fantasy that the system is broken, and this is all somebody else's problem, but it's not. Developers are simply using their tools the wrong way.

But even forgetting all of that, and assuming this was on browsers to fix: we should still be building sites the right way for our users in the meantime. A site isn't suddenly usable just because you weren't the one who broke it. A person who needs an accessibility feature still needs it, regardless of whose fault it is they don't have it. If you have the ability to make things accessible and choose not to...well, I don't know how that would be on anybody but you.

Have you actually tried up-sizing the text in your browser? Or your OS? Have you even gone so far as to experience what some of your website's users may be trying to do? Have you tried both ways to see the difference it makes? If you won't believe me, Josh W. Comeau has an article like this one. Or, there are plenty of web accessibility experts out there you can ask.

I don't really care what you think of me, or this article. I care that people who need accommodations receive them. I care about educating developers on how their tools work so we can build a better, more inclusive web. If you don't like me or my writing, fine. But you should at the very least spend your time finding out what your users are actually encountering and whether what you build is actually accessible, and not centering yourself in the discussion.

I am telling you that there are users who need us to build sites the right way. They need the ability to scale text properly.

If you've gotten this far and you still think that's not your problem, I'm sorry, I don't know how to convince you to care about other people. I can only tell you what that looks like, and remind you that if you're a developer, you are building things for others, not for yourself.

[nathanredblur]

Personally, there is not more to say about this.

[kartofelek007]

nathanredblur: This option is for global zoom, not for "change font size". Is there even a shortcut in chrome to change font-size?

josh-collinsworth: This isn't about any fix, just an option in the browser. Is there even a shortcut in chrome to change font-size? If the authors of a particular browser see that most of the internet is px based (and it is) and they care so much about everyone, they could add an additional checbox "scale text in px too" (something like prefer-color-scheme for sites that don't support it). It might not solve the age-old px vs em dispute, but it would probably help some. I don't know if there is even a single desktop browser with such an option. Apparently, it's not such a pressing problem in this day (where zoom exists), or the browser makers are bad people.

[josh-collinsworth]

most of the internet is px based

Just because most people did the job wrong doesn't mean it doesn't need to be done right.

There are users who rely on text sizing. Not zooming, as mentioned; upsizing the text.

We have not the right, nor should we have the audacity, to tell them they are wrong for their needs, and we should not blame browser makers when we have the power to do better by these users—by all users—by making what ultimately amounts to an utterly trivial change in how we write our code.

[kartofelek007]

Of course. And as you can see people approach the same topics differently. We know that problems exist in the web. Both with font-size, order on pages, contrast, bad implementation of form controls, noopener, many errors of the past.

We as frontend developers should do our best. At the same time, I also believe that tools should make it easier for us to browse the web. We can make the best, super-useful website in the world. But next to it will be a million badly coded ones, with bad constrast, masses of ads, etc. And sooner or later every user will encounter them. And how will he be expected to cope? Maybe it's the role of browsers to make his life easier.

[AlexMVoiture]

@josh-collinsworth I'm primarily a user and not a web developer, but let me throw this out:

Using FireFox -> Settings -> General -> Fonts Is how we change the font size(Or at about:preferences#general) Using Chrome -> Settings -> Appearance -> Font size To do the same (Or chrome://settings/fonts)

So yes, there are other people like me who need or want to change the default size on the browser. I did not find this article because web developing is my career, but rather because I was experimenting with some HTML examples(where they used px) for a personal project and they did not function as I would want it. So through google search about why the font couldn't scale, I ended up here.

[LittleBlueDot]

Great article!

I'm a bit astonished reading comments and discussion about it... I think, in some cases, the article is totally misunderstood - the author talks about font-size and NOT converting everything from px to rem or em. Personally, for me there was never a question what unit to use setting font sizes - rem ALWAYS. And it's not such a big work to convert font sizes from pixels – there're a lot of great online converters. And you do it once and that’s all. In the end, I think, a question is how much you care about users, how much you want to be a part of the idea that the web should be accessible to everyone.

P.S. I’m not buying the idea that using zoom is the same as setting font preferences in the browser. It's totally different!!! Zoom breaks all the design! And in the comments that icons and other decorations also than should be bigger, I can say only this – the user increases text because he/she wants to access an important information. Icons, I think, is not such a critical primary information.

[kartofelek007]

"Personally, for me there was never a question what unit to use setting font sizes - rem ALWAYS".

ALWAYS? You have many different techniques for approaching texts. Sometimes you want to scale a particular element without scaling the rest of the page, then it's better to use em. But screw em. After all, you have many other units that will work in a given situation: ch, vw, vh, cqi, cqh, etc.

For convert px->rem I prefer use simple scss function for this. This is much faster and has muuuuch more power.

The main question is still relevant. Browsers can turn on a dark mode on your page (even if you don't use prefer-color-scheme). They can highlight for you links with a phone number with a corresponding icon (even if you have not marked anything like that). They can change the contrast for you, translate the whole page, read it aloud, etc. But at the same time they can't add an additional option to scale on demand the text also described with PX. Why?

From the very beginning of the discussion, we keep saying that we know the use of relative units and support their use. But the question continues. Why is there no such option? Why are mobile browsers able to enlarge texts described by px, but desktop browsers are not? Since this is one of the most important things, it should have been there for a long time. The vast majority of the net is based on px! If you know of any new research on this topic - we'd love to read!

"I think, a question is how much you care about users, how much you want to be a part of the idea that the web should be accessible to everyone" I was recently approached by a person who deals with a site for people with disabilities. On their site, I helped them create a bar with which you could enlarge/decrease the text on the page, change font-face, but also radically change its color scheme (e.g. white/black to black/yellow). Despite the fact that, after all, users could enlarge the text for themselves in the browser, they decided to create such a bar. Why? And at the same time, there was also other questions. Why does no one pay attention to the fact that some users should use yellow-black color scheme? Maybe there is addon for this? Did you know that sharks never sleep? Did you know that when you enlarge only the text in Windows, in the browser everything is enlarged? So many questions...

Meanwhile, I'm back on Twitter, Youtube and Github. None of them allow you to change the font size. Ok that was a pinch. Regards 🖖

[LittleBlueDot]

I can just repeat that the article was about using relative units vs. absolute in font sizes. And we know about other units you mentioned :slightly_smiling_face: but the scope of this article and my comment was about font sizes.

I mentioned online calculators because you can work on very different projects in the IT company: some of them uses scss, some of them react frameworks where you don´t do so a lot of manual css (but they offer setting font size in rem or em :slightly_smiling_face:), etc.

Well, we can agree to disagree – I don't see any advantage of using px in font sizes and I'll continue using rem. And more and more often I use clamp() in defining font sizes.

P.S. Twitter, Youtube and Github are well known brands, I have never read about them as the leaders implementing the best practice on the web (well, I saw the blind person with the screen reader searching, finding and playing the right video on Youtube. So kudos for Youtube). If you know new research on this topic - I'd love to read!

[josh-collinsworth]

I admit I have stopped reading these comments for the most part, as I just don't have time. I appreciate the folks here who have advocated on the side of accessibility.

To the rest—or, those skeptical of the message of this post—let me add one final thought about using px units to set font size.

If your CSS doesn't load, the user can choose their own font size, as intended.

Once your CSS does load, they cannot. Your code has taken that ability away from the user.

If the user can do less because of your code, then it's bad code. That's it, plain and simple.

We can argue all day long about what we think browsers should be doing or ought to do in the future. There are valid points to be made in that debate.

But regardless, the unavoidable fact is: when we set font size in static px values, we take freedom away from actual, non-hypothetical users, right now, in the real present—freedom they may well need. And that's just not something we should be doing when we can very easily just adjust our techniques to achieve the same result without the hit to accessibility. We do not come before users, and accessibility is not a feature on a roadmap; it's something that needs to be included in what we build from the very beginning.

Putting the way we like to write code before the way the user will experience it is not something we should consider acceptable in this practice.