blog/never-use-px-for-font-size #19
Comments
|
Very interesting article! |
|
great read! Still using px till now it's because of clients preferences. |
|
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): The only difference came when I added a wrapper. Indeed the px fonts remained unchanged, while the em ones were magnified. |
|
@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. |
|
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? |
|
Why does this matter if, at the end, the user will use the zoom function in the browser? |
|
I think that using relative sizes is a good design practice;
|
|
@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 |
|
@1127 To clarify the "20px is 20px" comment: what I mean is, But zoom isn't where the issue lies, as the post details. |
|
Please correct me if I'm wrong: |
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. |
|
“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. |
|
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. |
|
If the user wants to increase the font, why not increase the icons and others elements? With that - why 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. |
|
To all the people arguing that users can, or should, or do just use zoom instead of changing the font size:
|
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.
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.
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. |
|
@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. |
|
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. |
|
I really vibe with 1127's attitude and it sounds like I really am in the wrong. 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. |
|
"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." 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). 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 On Samsung S21:
On xiaomi mi3:
And on both phone - change font size in system change font size in px |
Finally, to clear up one last misconception there: the user can set font size in If the user chooses If the user chooses |
|
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. |
|
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. 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: This may be nice topic to next article. Regards |
|
There is a “user agent stylesheet” applied before the website’s code, and it’s possible that its 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 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 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, |
|
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 But as a designer, let’s say I want a 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 As a developer bonus, managing your type scales, borders, margins and padding is a lot easier using relative units. |
|
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!
|
|
@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:
@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 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. |
|
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 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 Where you lost me is at all the other things ( 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 In the meantime, I am not convinced that I should even make the switch to |
|
@fuad-tareq I feel you may have misread the bit about margin, padding, and border. I actually do think it makes sense to use As for media queries: I can promise you that if those use 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? |
|
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. |
|
Comparing accessibility to "every little change browsers make" is a pretty inaccurate false equivalence. The 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 |
|
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!
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. |
|
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. |
|
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. |
|
"We did." "The browsers most certainly can fix this, can we at least agree on that?" |
|
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. |
|
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 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 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. |
|
Personally, there is not more to say about this. |
|
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? |
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. |
|
Of course. And as you can see people approach the same topics differently. We as frontend developers should do our best. |
|
@josh-collinsworth Using FireFox -> Settings -> General -> 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. |
|
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. |
|
"Personally, for me there was never a question what unit to use setting font sizes - rem ALWAYS". ALWAYS? 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. 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" 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 🖖 |
|
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 🙂 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 🙂), 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! |
|
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 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 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. |
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
The text was updated successfully, but these errors were encountered: