A formula for responsive font-size(jameshfisher.com)
jameshfisher.com
A formula for responsive font-size
https://jameshfisher.com/2024/03/12/a-formula-for-responsive-font-size/
113 comments
I would expect two large groups of user behavior:
1. People who never adjust font size.
2. People who regularly adjust font size as needed.
The first group is helped by a reasonable responsive font size. The second group isn't hindered by it.
Is there really a significant group of people who carefully set their preset font size, but then do not adjust it as needed when they visit a page? It seems unlikely to me. Even if all webpages used your defaults, there’s still no one-size-fits-all preset to pick, since typeface, weight, layout, leading, colors and many other things also impact readability. The tool to take control of all of that is reader mode, which is a great option when a website has screwed up its typography.
1. People who never adjust font size.
2. People who regularly adjust font size as needed.
The first group is helped by a reasonable responsive font size. The second group isn't hindered by it.
Is there really a significant group of people who carefully set their preset font size, but then do not adjust it as needed when they visit a page? It seems unlikely to me. Even if all webpages used your defaults, there’s still no one-size-fits-all preset to pick, since typeface, weight, layout, leading, colors and many other things also impact readability. The tool to take control of all of that is reader mode, which is a great option when a website has screwed up its typography.
> I would expect two large groups of user behavior:
I think you're missing:
3. People who set the font size once, when they configure their browser, to their preferred font size and expect, for some weird reason, that this will be respected!
> The tool to take control of all of that is reader mode, which is a great option when a website has screwed up its typography.
That would be great, if there wasn't a huge correlation between websites that screw up their typography, and websites that use an ungodly mess of nested `div`s and javascript-based content rendering that breaks reader mode.
I think you're missing:
3. People who set the font size once, when they configure their browser, to their preferred font size and expect, for some weird reason, that this will be respected!
> The tool to take control of all of that is reader mode, which is a great option when a website has screwed up its typography.
That would be great, if there wasn't a huge correlation between websites that screw up their typography, and websites that use an ungodly mess of nested `div`s and javascript-based content rendering that breaks reader mode.
On Firefox there's a preferred, minimum and maximum sizes. If you want sites to respect it, you set the minimum, otherwise it's a suggestion.
That third group is small enough that if it is impractical to properly support all three, they are the ones that will be ignored first.
I set the text size on my mobile browser. You'll understand as you get older and your devices keep getting more pixels.
I do too, and I’m in group #2. Are you saying you’re not?
No, I set it one for each device, then I never touch it again. So I'm am the third group that you doubt exists.
I don't want to fiddle with it. I read text on my phone, I have a preferred size to read, I shouldn't have to change it more than once. The few sites which end up too big or too small I read begrudgingly. Can I even set font size per site?
Pinch zoom doesn't work because now I have to pan left and right for each sentence?
I'm totally with Karellen on this.
I don't want to fiddle with it. I read text on my phone, I have a preferred size to read, I shouldn't have to change it more than once. The few sites which end up too big or too small I read begrudgingly. Can I even set font size per site?
Pinch zoom doesn't work because now I have to pan left and right for each sentence?
I'm totally with Karellen on this.
At least in safari, you can hit the AA button and increase the font size there.
All CSS font sizes are already responsive because CSS pixels are an abstract concept. Adding your own hacks on top of that instead of respecting system settings is counter-productive.
This method uses the root font size as the base and therefore scales with the user's custom setting.
The point of the user's custom setting is that you don't need to scale with it. The user's custom setting is the font size they want! That's why they set it.
If the user wants a different root font size, they'll set it themselves.
If the user wants a different root font size, they'll set it themselves.
If every site used the same font, maybe. But different font faces vary in readability at the same size. Also, we still have to set sizes for things like titles, subtitles and other elements to create a hierarchy on the page.
'Don't resize my fonts' is such a narrow view of whole range of design considerations.
'Don't resize my fonts' is such a narrow view of whole range of design considerations.
font size needs to scale because font size can also affect contrast, unless the user is setting custom font size per site it will not be adequate for the user to set the custom font size for all potential situations.
Unfortunately, while making a site, I can't query for "does the user set special preferences" in CSS.
I use somewhat similar formula in one project to create a common baseline font size that 1) does not break with viewport size changes 2) remain legible for baseline user 3) gives good base value to scale UI elements by rem/em units.
Of course it's also a project where the user does not have a chance to mess with font size anyway for the main user, but I'd reuse the formula elsewhere.
Wish I could query the browser if the user has specific preferences, just like with "Dark mode"
I use somewhat similar formula in one project to create a common baseline font size that 1) does not break with viewport size changes 2) remain legible for baseline user 3) gives good base value to scale UI elements by rem/em units.
Of course it's also a project where the user does not have a chance to mess with font size anyway for the main user, but I'd reuse the formula elsewhere.
Wish I could query the browser if the user has specific preferences, just like with "Dark mode"
You don't query for it; you don't override. Either the setting is custom and desired, or it's default and it hasn't been adjusted because it's fine.
My personal experience is that the default is usually wrong, especially when I move between different displays. I end manually zooming in/zooming out a lot.
Meanwhile using the default size + CSS keyword size modifiers (large/x-large etc.) ended up on breaking on the project I mentioned, especially after for all practical purposes we had to deal with the fact that claims of single display size & resolution to target weren't actually delivered, and when client also asked about possibly opening the interface from portable devices.
Meanwhile using the default size + CSS keyword size modifiers (large/x-large etc.) ended up on breaking on the project I mentioned, especially after for all practical purposes we had to deal with the fact that claims of single display size & resolution to target weren't actually delivered, and when client also asked about possibly opening the interface from portable devices.
> My personal experience is that the default is usually wrong, especially when I move between different displays. I end manually zooming in/zooming out a lot.
Then fix your setup. Campaing for better browser defaults. Do whatever it takes, but don't add hacks with hardcoded (=faulty) assumptions to your websites.
Then fix your setup. Campaing for better browser defaults. Do whatever it takes, but don't add hacks with hardcoded (=faulty) assumptions to your websites.
Sadly, I agree that browsers have forgotten what defaults are for. Instead of prvoiding something useable for the user, default CSS has turned into a nearly completely abstract set of values of relevance only to developers.
But that situation should be fixed on the side of the Web browsers, not every website's author.
But that situation should be fixed on the side of the Web browsers, not every website's author.
OR, the setting is default and it hasn't been adjusted because the user doesn't have the faintest idea how to adjust font sizes.
Which I suspect is the case for the majority of end users.
Which I suspect is the case for the majority of end users.
The responsibility for making sure the default is reasonable for those users is the browser vendor, NOT each individual website.
> Wish I could query the browser if the user has specific preferences, just like with "Dark mode"
You can't query that with dark mode since there is no "no-preference" in the spec and the "preference" that browsers expose normally has not been influenced by the user in anyway. You should still respect the indicated dark mode preference because the user can influence it to set their preference for all sites. Same with the font size.
You can't query that with dark mode since there is no "no-preference" in the spec and the "preference" that browsers expose normally has not been influenced by the user in anyway. You should still respect the indicated dark mode preference because the user can influence it to set their preference for all sites. Same with the font size.
[deleted]
For me, HN is one of the hardest to read on default zoom.
It's a real shame the site is never improved due to the captive market and lack of need to make things better. I am constantly downvoting on mobile when I mean to be upvoting for example, surely they could just make the clickable area bigger.
I also sometimes wish this site got an overhaul, but then I look at the new Reddit layout and feel glad HN hasn't changed like that.
That's the most slippery slope argument possible. "Whoa can't refine the hit state on two arrows by a few pixels! The whole site might become anew Reddit!"
I think the argument is more “if I had to choose between the two extremes, I'd definitely prefer this one” than the slippery slope of “I don't want change because change might lead to abomination”.
Yes completely, I can't understand why Reddit hate their users so much, I find the site totally unusable and I often just leave immediately if I visit it!
I use a Safari extension to add my own CSS and edited a Stylish package that already existed to update the design a bit. On iOS and iPadOS I use Hack. https://apps.apple.com/us/app/hack-for-hacker-news-reader/id...
That’s interesting; this seems like one of the better mobile sites to me. I mean it is just a column of text. I don’t really care that much if I hit the wrong voting button, though. I’m just one little signal, if my inputs are slightly stochastic it shouldn’t matter too much. If I really love a comment I can zoom in a bit to hit the arrows.
Then change your DPI scaling factor to match your display size and viewing conditions. HN has a perfectly reasonable font size.
There are exactly 2 websites where I feel like I need to increase my front size, HN (140%, no less) and old.reddit.com. Every other website I use looks fine.
And I'm not changing the font size on every website I visit for the rest of my life just so that HN can display properly at 100% zoom.
And I'm not changing the font size on every website I visit for the rest of my life just so that HN can display properly at 100% zoom.
Exact same boat. HN font size is outrageously small.
Same here, and for this reason I prefer Firefox because it remembers the zoom size on a per domain basis instead of a tab basis.
Chrome and Safari do this too.
It's 9pt, most recommendations I see are between 14-16 for body text. I usually have HN on 130% in my browser.
Browsers have 16px font as the default. HN is set to half.
"just change your settings for your whole monitor for every site you visit because HN has the _perfectly reasonable_ font-size of 9pt."
Laughs in pinch to zoom which works for zooming into images as well. I just really hate those websites that disable this and the regular zoom.
I actually liked it more when browser zoom affected only the font size and images were left 1:1 - for a normal Desktop usage anyway.
Browsers should definitely support both, they are very different features.
I know that Safari has two zoom modes, one which zooms the whole page and one which zooms just the text, leaving everything else intact.
If only CSS supplied some sensible keywords based on the user's preferences, so you could just ask for say a medium, large, or x-large font.
Of course CSS actually does. I've found using font size keyword and rem units can make a UI that scales with user preferences quite possible. Not _easy_ of course, but possible.
Of course CSS actually does. I've found using font size keyword and rem units can make a UI that scales with user preferences quite possible. Not _easy_ of course, but possible.
Actually, Medium—the app, at least—does have an option under "Display settings" that lets you switch between two font sizes that are almost imperceptibly different...
Full-page zoom won already. Browsers all make it very difficult to even scale the font size without zooming the page (Firefox is the easiest, with the setting buried in a submenu as a toggle). And frankly, scaling just the fonts but leaving the rest of the layout is a bad experience: scaling just the font size often breaks the layout, particularly around interactive controls like buttons and tabs. There are two good paths to accessibility here: full-page zoom, and reader mode.
I have found myself in my own private war against web sites over text viewability. Gievn that I am a longtime-coder, and longtime-electronics engineer, I had a life-altering experience a few years ago: as I was laying out a new circuit board design via CAD for a longtime client, a board which I would also have to write all the code for, my eyesight went all-goofy <technical term?>. I had to depend on family members to get me an emergency admission to an eye clinic, where I learned I had a detached-retina in one eye, was told it must hurt, and they didn't have anyone on-staff that could fix it. A few years later, and I have my vision blocked in that same eye due to a cataract, they won't do surgery becuase I'm 'allergic to lasers' and I need to shift to audio books. Huh. No, here's what I need from web pages and web browsers: an end to de-emphasised background comments that appear as light-gray on white background, and a quick button that let's me view everything in undecorated font Libre Sans (Libre mono for code), Boldface, and 14-pixel. The boldface is a huge sticking point, and I really need it. And nobody supports it :(
My eyesight is like viewing everything through a 'snowstorm whiteout'. The thin strokes of non-Boldface are nearly invisible, and size-alone doesn't quite fix it enough. Then there are the web site that insist on havign a hard-lock on low-contrasty themes......they seem to feel their precious theme to be more important than the word.
In your browser of choice, install the "Stylus" plugin. This is a plugin that will let you write custom CSS styles for any and all page(s). If your browser of choice does not have the exact "Stylus" plugin it will have a plugin of another (similar) name that will do the identical task.
As it seems from your post that you may not be extremely familiar with CSS, here is a ruleset that will do something close to what you wish. Font is set to 26px, not 14. You can easily change that.
Make it valid for "Everything" and it will be valid for everything but those sites that are extremely convoluted.
As it seems from your post that you may not be extremely familiar with CSS, here is a ruleset that will do something close to what you wish. Font is set to 26px, not 14. You can easily change that.
Make it valid for "Everything" and it will be valid for everything but those sites that are extremely convoluted.
*, html, body, section, article, div, span, p, i, b, strong {
font-family: "Libre Sans" arial, helvetica, sans, sans-serif !important;
font-size: 26px !important;
font-weight: bold;
line-height: 1.5em !important;
background-color: white;
color: black;
}
pre, code {
font-family: "Libre Mono", Courier, monotype !important;
}
a {
text-decoration: underline;
}Added: Here is the ruleset I use for Hacker News specifically
* {
font-size: 23px;
line-height: 1.5em
}
a {
text-decoration: underline;
}Websites should be designed better, but it is 2024, that ship has sailed I think.
The Dark Reader addon for Firefox is somewhat poorly named, it seems to be a pretty solid overall website customization tool. It can, for example:
* force websites into light mode
* change backgrounds to plain white and text to plain black
* apply tints in general
* force font line width changes.
Might be worth a glance. I have pretty good vision but I just use it because the way the internet is supposed to work is: send me text, I’ll render it however I want. This lets me ignore more meddling by designers.
The Dark Reader addon for Firefox is somewhat poorly named, it seems to be a pretty solid overall website customization tool. It can, for example:
* force websites into light mode
* change backgrounds to plain white and text to plain black
* apply tints in general
* force font line width changes.
Might be worth a glance. I have pretty good vision but I just use it because the way the internet is supposed to work is: send me text, I’ll render it however I want. This lets me ignore more meddling by designers.
I've been asking myself what I want out of visiting particular sites and what I need to get it. How far do I need to move from the command line to fulfill my goal?
At the browser level I've found myself wanting to reorganize layout quite a bit, and am starting to think about templating from a user perspective beyond light/dark theme. What assumptions am I making about intent in my work? How can I provide flexibility and when should I step back and just link a csv dump?
I think my ideal modern browser looks more like a crawler. Display of info loosely coupled to site content. All of the scripts I'd actually want to run pulled down on my side from public repos.
At the browser level I've found myself wanting to reorganize layout quite a bit, and am starting to think about templating from a user perspective beyond light/dark theme. What assumptions am I making about intent in my work? How can I provide flexibility and when should I step back and just link a csv dump?
I think my ideal modern browser looks more like a crawler. Display of info loosely coupled to site content. All of the scripts I'd actually want to run pulled down on my side from public repos.
Yes! The day I made my website serve a "posts.atom" file was the day I realized:
The posts.atom file has all my actual content.
What is the rest of my website for? Somehow I was tricked into writing it, but it's essentially a feed reader for a single feed.
Why can't I just serve a posts.atom and trust Firefox to know what to do with it? It already has a Reader mode.
The posts.atom file has all my actual content.
What is the rest of my website for? Somehow I was tricked into writing it, but it's essentially a feed reader for a single feed.
Why can't I just serve a posts.atom and trust Firefox to know what to do with it? It already has a Reader mode.
If you're on Mac, I recommend the Arc Browser, and using their Boost to adjust sites with custom css with the font + bold specification you want. Or a chrome extension, but I'm sure you've already found a similar solution and it's annoying to just have to re-do that everytime.
I wonder if there are custom CSS chrome extensions that allow you to apply a font to all sites not just one.
I wonder if there are custom CSS chrome extensions that allow you to apply a font to all sites not just one.
Does the browser reader mode help?
I like how it behaves on desktop, but I don't like making it "responsive" on mobile.
We can fix that :D
We can fix that :D
:root {
font-size: 1rem;
}
@media (pointer: fine) {
:root {
font-size: calc(1rem + 0.25vw);
}
}
@media (pointer: coarse) {
:root {
font-size: 1.25rem;
}
}
Let's actually fix it:
:root {
font-size: 1rem;
}
I'm not so sure..
There are good reasons to use different font sizes for body text depending on purpose. Hacker News' small fonts fit more comments on the page. A documentation site may benefit from fitting more text on the page. A spreadsheet benefits from even smaller text. The article is easier to read with larger fonts. I tried the article with your rule, it's just not as nice.
Then I changed around my "preferred font size" (chrome://settings/fonts -> Font Size). Blog responds just fine to it. Ironically many, many, many sites don't. It's actually so useless in general to change your default font size that browsers have a much more useful way of letting users have small or large text -- zoom levels.
There are good reasons to use different font sizes for body text depending on purpose. Hacker News' small fonts fit more comments on the page. A documentation site may benefit from fitting more text on the page. A spreadsheet benefits from even smaller text. The article is easier to read with larger fonts. I tried the article with your rule, it's just not as nice.
Then I changed around my "preferred font size" (chrome://settings/fonts -> Font Size). Blog responds just fine to it. Ironically many, many, many sites don't. It's actually so useless in general to change your default font size that browsers have a much more useful way of letting users have small or large text -- zoom levels.
All of your examples benefitted from smaller text. And the caveat is always that it has the be big enough to read. Therefore, just let the user set the size, they can set it to the smallest size they can read.
[deleted]
Please, please please have reasonable bounds around that if you do want to use a responsive font-size. `clamp(10px, 1rem + 0.25vw, 60px)` (say) doesn't harm anyone else.
There are some worst offenders who chose the fontsize based on the size of the viewports... and it get's ludicrous big at my work, where I have an ultra wide curved monitor.
Everybody please clamp!
Everybody please clamp!
It's definitely a fascinating game to try websites Full Screen on an ultra wide. I definitely tend to stick to FancyZones for most browser windows to get "normal" breakpoints, but every now and then it's fun to play with sites and see which ones tested extremes in responsiveness.
I get a lot of flak that my blog [0] scrolls horizontally by default when JS is enabled, because that is intentionally weird, but it's one of the only websites I know of that is "readable like a newspaper" when full screen on an ultra-wide monitor. Some posts you can read the entire article at full screen on an ultra-wide with no scrolling at all. I'm proud of that and I like that for my own enjoyment, even if few others appreciate it.
[0] https://blog.worldmaker.net
I get a lot of flak that my blog [0] scrolls horizontally by default when JS is enabled, because that is intentionally weird, but it's one of the only websites I know of that is "readable like a newspaper" when full screen on an ultra-wide monitor. Some posts you can read the entire article at full screen on an ultra-wide with no scrolling at all. I'm proud of that and I like that for my own enjoyment, even if few others appreciate it.
[0] https://blog.worldmaker.net
Really need to adjust more than just the font size, line height, grid spacing etc all need adjusting too
https://utopia.fyi/ is good for these calculations
https://utopia.fyi/ is good for these calculations
I used Utopia as the baseline for my sites; though I hadn't previously encountered people who had force-changed their font-size per site.
I also came here to recommend Utopia.fyi. An incredible solution done right. Use it on all my projects - for don’t size, typographic scale, and spacing.
Funny typo. For a moment I thought the link would be about how not to size things on websites.
Yes, I noticed the autocorrect but it was too late. Thought the context was sufficient to expose it as a typo.
“…for font size, typographic scale, and spacing.”
“…for font size, typographic scale, and spacing.”
[deleted]
This is going to make text very large whenever somebody with an ultrawide monitor decides to maximize their browser window.
Although not exactly ultra-wide, on my 27" screen, the font-size with maximised window (2500px horizontally) would compute to ~22px for the submitted website. While that’s noticeable bigger compared to a narrow view port, I’m not sure that would qualify as “very large”. To me, it looks alright.
The main container’s width on their website also doesn’t scale infinitely, so on a very wide screen you’d have a lot of blank space on both sides.
That being said, it might still be reasonable to set a break point (or use CSS clamps) and prevent further font-size growth beyond a certain point.
The main container’s width on their website also doesn’t scale infinitely, so on a very wide screen you’d have a lot of blank space on both sides.
That being said, it might still be reasonable to set a break point (or use CSS clamps) and prevent further font-size growth beyond a certain point.
Yes how is the viewport size really relevant? A sensible site would have a max column width for any paragraph. So if I have a 4000px wide viewport and view a 500px wide column of text, it has to be the same size as the 500px column of text also if the browser window is just 1000px?
Ironically, the font is too large for the table to fit on the screen, introducing horizontal scroll on this mobile page which I’m sure isn’t best practice. (I’m viewing this page on an iPhone 15)
That in itself might mean, that a table is not the right way in this case.
I think a table can be alright, there is only so much you can do. It could be fine tuned though to only require horizontal scrolling on the table and not the whole web page. Maybe anchor the first row and column if you want to be fancy.
Silly idea! A font size must depend on the vision of the reader.
Isn't the whole point of em that you don't have to do this?
how would one use em to implement something like this?
1em is your base text size (what your content should use), >1, <1 when you want larger or smaller text, point being you don't dynamically adjust and break the users font size configuration.
For example comparison with the OP's site:
- dynamic on : https://files.catbox.moe/qwa2az.png
- dynamic off: https://files.catbox.moe/glu3ud.png
For example comparison with the OP's site:
- dynamic on : https://files.catbox.moe/qwa2az.png
- dynamic off: https://files.catbox.moe/glu3ud.png
Don’t you mean rem? If you use em like that you have to make sure that you don’t multiply your font size more than once when nesting elements.
Except that's exactly what you want e.g. when you want something to stand out relative to its context. For instance, you want your headings to be 150% the size of surrounding text, so when you have an info box with smaller text and a heading, that heading should not end up as tall as your main text headings.
Of course you could also have distinct heading classes or equivalent selectors for different contexts, and specify every case in rem, if that's how you like your stylesheets.
Of course you could also have distinct heading classes or equivalent selectors for different contexts, and specify every case in rem, if that's how you like your stylesheets.
What is the motivation behind changing font size between mobile and desktop? My understanding is that browsers and apps already show the same font size at roughly the same perceptual physical size based on DPI and likely viewing distance, using relative units (em/rem on web, points on iOS, dp/sp on Android).
I'm guessing it's one of these two things?
1. Designers now disagree with the result of that preexisting calculation.
2. Designers are OK with making fonts on mobile smaller than the ideal reading size so that they can fit more content on screen (doesn't seem like a very designer-y thing to do).
Edit:
Or, #3, this is an alternative to the trick I assumed was ubiquitous:
Edit 2:
Scratch theory #3. The author's site and all three of the sites he cites have that viewport line.
I'm guessing it's one of these two things?
1. Designers now disagree with the result of that preexisting calculation.
2. Designers are OK with making fonts on mobile smaller than the ideal reading size so that they can fit more content on screen (doesn't seem like a very designer-y thing to do).
Edit:
Or, #3, this is an alternative to the trick I assumed was ubiquitous:
<meta name="viewport" content="width=device-width, initial-scale=1" />
Edit 2:
Scratch theory #3. The author's site and all three of the sites he cites have that viewport line.
> Which, I never understood why this is necessary in the first place (I'm not an experienced web dev).
It's because the first phone browsers had an insane default, and the standards body decided the insanity should be kept for backwards compatibility.
Having a viewport meta turns the insanity off, but only if you set the content area.
It's because the first phone browsers had an insane default, and the standards body decided the insanity should be kept for backwards compatibility.
Having a viewport meta turns the insanity off, but only if you set the content area.
Oh, thanks, I think I see. Before we had to think about mobile, any web page that wasn't just a block of text (e.g. inline images, side bars, etc) had bad/broken layout at small widths. Instead of waiting for the whole world to fix their websites, mobile browsers just shrank them a bit. The browser couldn't distinguish between a website that looked good and bad on mobile, so it shrank all of them. And because the web is inherently a slave to backwards compatibility, it's that way forever now.
Mobile browsers do the shrinking by messing with viewport defaults, so we fix it by re-applying those defaults.
I think the MDN doc's only mistake was describing "device-width" as "100% viewport width", since that seems like circular logic.
Mobile browsers do the shrinking by messing with viewport defaults, so we fix it by re-applying those defaults.
I think the MDN doc's only mistake was describing "device-width" as "100% viewport width", since that seems like circular logic.
> Instead of waiting for the whole world to fix their websites, mobile browsers just shrank them a bit.
What comically never fixed anything. But yeah, that's the rationale.
AFAIK, mobile browsers only actually managed to display non-text sites when pinch-to-zoom was invented and the sites started to include the viewport meta. And they only managed to display text-only sites by reflowing the contents. The shrinking the viewport era was a deep local minimum of usability.
What comically never fixed anything. But yeah, that's the rationale.
AFAIK, mobile browsers only actually managed to display non-text sites when pinch-to-zoom was invented and the sites started to include the viewport meta. And they only managed to display text-only sites by reflowing the contents. The shrinking the viewport era was a deep local minimum of usability.
The point of having font size jumps is to only test screen dimensions right before and after the jump, to check for overflow or excessively large containers. But with a linear scaling this checking requires looking at all resolutions
My strong recommendation is to stick to 1 browser em (~16px) on mobile-sized displays, and not to exceed 1.25 browser ems (~20px) on large displays. The formula provided in this article starts you at around ~17px, and exceeds ~20px on viewports wider than 1600px (quite common). That is: it’s too big.
I’d suggest instead something like ~16px at 360px viewport width, and ~20px at 1600px viewport width, and clamping at these values. Slightly different curve, and capped a little more sensibly, in my opinion. (Personally, I tend to stop shy of ~20px, going more for ~18px.)
With these specific values, a verbose expression of the font-size is:
I’d suggest instead something like ~16px at 360px viewport width, and ~20px at 1600px viewport width, and clamping at these values. Slightly different curve, and capped a little more sensibly, in my opinion. (Personally, I tend to stop shy of ~20px, going more for ~18px.)
With these specific values, a verbose expression of the font-size is:
/* 1rem @ 22.5rem, 1.25rem @ 100rem */
clamp(1rem, 1rem + ((1.25 - 1) / (100 - 22.5) * (100vw - 22.5rem)), 1.25rem)
I like using clamp() so there is a minimum and maximum size. Here's a Sass function to abstract away all the math --> https://gist.github.com/kingkool68/d2da6d3461eb7d47ca5815f9d...
While I agree with most of the comments that font-size for body text should ideally be 1rem (and certainly clamped), what about headings? When I think about different font sizes I think about headings, where it absolutely makes sense to have a much larger size on wide (/"desktop") screens.
HTML has a header command, maybe that would work?
This absolutely the wrong thing to do. Don't scale font size with viewport size. CSS "pixels" are already an abstract concept - if things are too small on your high-DPI screen adjust your pixel ratio accordingly instead of wasting everyone elses screenspace.
My favorite solution in this space remains https://www.modularscale.com/, because (like others mentioned) different device types warrant different scales, BUT ALSO changing line height and padding on a modular scale (also per device type) takes the math out of my responsibilities and puts it on the computer - where it belongs.
I use rfs for that. https://github.com/twbs/rfs
What about the font-size: = 62.5% trick?
html { font-size: 62.5%; }
https://www.aleksandrhovhannisyan.com/blog/62-5-percent-font...
Has it gone by the wayside? Is it no longer a best practice?
html { font-size: 62.5%; }
https://www.aleksandrhovhannisyan.com/blog/62-5-percent-font...
Has it gone by the wayside? Is it no longer a best practice?
This was always a terrible thing to do.
The idea behind it was that the browser default font size was 16px, so if you set the root font size for your document to 62.5%, then 1em = 10px, and designers who really, really wanted to work with pixels could use ems and pretend they were using pixels without doing complicated maths every time they wanted to set the size of something – they just needed to divide or multiply by ten.
The reason for not just using pixels was partly because it was drummed into everybody’s heads at the time that ems were better than pixels (which, in context, they were, but not when you pretend they are pixels), and partly because Internet Explorer at the time was unable to resize text set in pixels when you increased the text size, which was an accessibility failure.
The problem with this idea is that pixels and ems are fundamentally different types of unit. You can’t make them equivalent using any kind of calculation in CSS. Pixels are objective, whereas ems are based on user preferences. The browser might default to 16px font size, but users can pick something else. So if somebody had poor vision and increased their default font size; or if they had a small laptop screen and decreased their default font size, 1em * 62.5% != 10px, everything the designer set in ems was a different size than they intended, and a lot of their page layouts disintegrated into an unholy mess.
You can’t convert between ems and pixels in CSS. Any calculation like this is fundamentally broken from the start. Nobody should have ever used the 62.5% hack.
The idea behind it was that the browser default font size was 16px, so if you set the root font size for your document to 62.5%, then 1em = 10px, and designers who really, really wanted to work with pixels could use ems and pretend they were using pixels without doing complicated maths every time they wanted to set the size of something – they just needed to divide or multiply by ten.
The reason for not just using pixels was partly because it was drummed into everybody’s heads at the time that ems were better than pixels (which, in context, they were, but not when you pretend they are pixels), and partly because Internet Explorer at the time was unable to resize text set in pixels when you increased the text size, which was an accessibility failure.
The problem with this idea is that pixels and ems are fundamentally different types of unit. You can’t make them equivalent using any kind of calculation in CSS. Pixels are objective, whereas ems are based on user preferences. The browser might default to 16px font size, but users can pick something else. So if somebody had poor vision and increased their default font size; or if they had a small laptop screen and decreased their default font size, 1em * 62.5% != 10px, everything the designer set in ems was a different size than they intended, and a lot of their page layouts disintegrated into an unholy mess.
You can’t convert between ems and pixels in CSS. Any calculation like this is fundamentally broken from the start. Nobody should have ever used the 62.5% hack.
> The browser might default to 16px font size, but users can pick something else. So if somebody had poor vision and increased their default font size; or if they had a small laptop screen and decreased their default font size, 1em * 62.5% != 10px, everything the designer set in ems was a different size than they intended, and a lot of their page layouts disintegrated into an unholy mess.
Howdy, author of the article you're responding to (but not the person who originally discovered/pioneered this trick). This is not true, and my article explains why.
The 62.5% trick is rarely used on its own, but people often cite it this way, leading to confusion. In practice, you set the root font size to 62.5% (of the user agent font size) and then also scale all body text back up to 1.6rem so it's not stuck at 10px. From here on out, all font sizes remain proportional no matter what, even if a user changes their preferred root font size in browser settings. Play around with the math if you doubt it (the article offers examples).
> everything the designer set in ems was a different size than they intended
That's working as intended—your design will scale up or down, according to the user's preferred font size. If you don't like this, your only option is to set font sizes in pixels, which [you shouldn't be doing anyway](https://www.aleksandrhovhannisyan.com/blog/use-rems-for-font...) (disclaimer: also written by me).
Howdy, author of the article you're responding to (but not the person who originally discovered/pioneered this trick). This is not true, and my article explains why.
The 62.5% trick is rarely used on its own, but people often cite it this way, leading to confusion. In practice, you set the root font size to 62.5% (of the user agent font size) and then also scale all body text back up to 1.6rem so it's not stuck at 10px. From here on out, all font sizes remain proportional no matter what, even if a user changes their preferred root font size in browser settings. Play around with the math if you doubt it (the article offers examples).
> everything the designer set in ems was a different size than they intended
That's working as intended—your design will scale up or down, according to the user's preferred font size. If you don't like this, your only option is to set font sizes in pixels, which [you shouldn't be doing anyway](https://www.aleksandrhovhannisyan.com/blog/use-rems-for-font...) (disclaimer: also written by me).
> From here on out, all font sizes remain proportional no matter what, even if a user changes their preferred root font size in browser settings.
I think you might have misunderstood my point. My point is not that font size is no longer proportional. It’s actually critical to my point that it is proportional.
The 62.5% trick became popular because designers were used to designing with pixels and didn’t want to design with more fluid units like em. They were forced to by external requirements or often they were just following trends without really understanding them. So they used ems with the 62.5% trick as a substitute for pixels but didn’t change how they designed. So they were still designing with pixels in theory, but using ems as a really bad placeholder.
So if they wanted something to be 100px wide, using the 62.5% trick, they would set it to 10em. This will not get them something that is 100px wide though. This will get them something that is 10em wide, which will happen to be rendered 100px wide only when the browser is using a 16px default font size.
What happens when that fake-100px-but-actually-10em wide element is meant to coexist with something that is actually set in pixels? For instance, a 120px skyscraper ad? The things sized in fake-pixels-but-actually-ems will change proportionally with the user’s font size, but the things sized in real pixels will not. All of a sudden different elements on the page have different ideas about what scale they should be rendered at, and the layout falls apart.
Were you surfing the web with a non-default font size when this particular practice took off? I was, and I could always tell when a site started to use it because their layouts all got screwed up.
If you want to design in pixels, design in pixels. If you want to design in ems, design in ems. But don’t use ems as fake pixels because it cannot work reliably. The two units are fundamentally different and you cannot convert between them. One is rooted in a subjective user preference that can be different on every device, one is an objective measurement.
I think you might have misunderstood my point. My point is not that font size is no longer proportional. It’s actually critical to my point that it is proportional.
The 62.5% trick became popular because designers were used to designing with pixels and didn’t want to design with more fluid units like em. They were forced to by external requirements or often they were just following trends without really understanding them. So they used ems with the 62.5% trick as a substitute for pixels but didn’t change how they designed. So they were still designing with pixels in theory, but using ems as a really bad placeholder.
So if they wanted something to be 100px wide, using the 62.5% trick, they would set it to 10em. This will not get them something that is 100px wide though. This will get them something that is 10em wide, which will happen to be rendered 100px wide only when the browser is using a 16px default font size.
What happens when that fake-100px-but-actually-10em wide element is meant to coexist with something that is actually set in pixels? For instance, a 120px skyscraper ad? The things sized in fake-pixels-but-actually-ems will change proportionally with the user’s font size, but the things sized in real pixels will not. All of a sudden different elements on the page have different ideas about what scale they should be rendered at, and the layout falls apart.
Were you surfing the web with a non-default font size when this particular practice took off? I was, and I could always tell when a site started to use it because their layouts all got screwed up.
If you want to design in pixels, design in pixels. If you want to design in ems, design in ems. But don’t use ems as fake pixels because it cannot work reliably. The two units are fundamentally different and you cannot convert between them. One is rooted in a subjective user preference that can be different on every device, one is an objective measurement.
> What happens when that fake-100px-but-actually-10em wide element is meant to coexist with something that is actually set in pixels? For instance, a 120px skyscraper ad? The things sized in fake-pixels-but-actually-ems will change proportionally with the user’s font size, but the things sized in real pixels will not. All of a sudden different elements on the page have different ideas about what scale they should be rendered at, and the layout falls apart.
This is technically also working as intended. When a user scales their preferred font size in their browser settings, their expectation is that the font sizes on pages will scale accordingly, not that every element will scale. The latter is what zoom accomplishes, but there's a reason why both zoom and preferred font sizes exist in browser settings.
In your example, the ad (or image, or whatever) should only be sized in rems/ems if it has text. For all other elements that aren't related to text, it makes more sense to size with pixels. If everything is sized in ems/rems, then scaling the preferred font size behaves identically to zoom. This is less than ideal because if I want to increase font sizes, and what you do in response is zoom the whole page, then there is less space for that same text to fit on the page because it competes with other scaled elements. So while I can read the text more easily because the glyphs are larger, I can read _less_ of the text within the same amount of space than if text were the only scaled element.
Also, at least in my experience, designers aren't the ones thinking in ems; they typically hand us Figma compositions that use pixels, and we translate to rems in our code base. Designers design for the base experience, and we are responsible for coding it in a way that scales proportionally/in a way that respects user preferences.
This is technically also working as intended. When a user scales their preferred font size in their browser settings, their expectation is that the font sizes on pages will scale accordingly, not that every element will scale. The latter is what zoom accomplishes, but there's a reason why both zoom and preferred font sizes exist in browser settings.
In your example, the ad (or image, or whatever) should only be sized in rems/ems if it has text. For all other elements that aren't related to text, it makes more sense to size with pixels. If everything is sized in ems/rems, then scaling the preferred font size behaves identically to zoom. This is less than ideal because if I want to increase font sizes, and what you do in response is zoom the whole page, then there is less space for that same text to fit on the page because it competes with other scaled elements. So while I can read the text more easily because the glyphs are larger, I can read _less_ of the text within the same amount of space than if text were the only scaled element.
Also, at least in my experience, designers aren't the ones thinking in ems; they typically hand us Figma compositions that use pixels, and we translate to rems in our code base. Designers design for the base experience, and we are responsible for coding it in a way that scales proportionally/in a way that respects user preferences.
> So if they wanted something to be 100px wide, using the 62.5% trick, they would set it to 10em.
I never ever heard of anyone using the 62.5% trick for sizing elements. I only ever heard it being used for text.
I never ever heard of anyone using the 62.5% trick for sizing elements. I only ever heard it being used for text.
I use:
html {font-size: 16px;}
This is very bad for a different reason. It makes it impossible to ensure the size of your text is readable for the user. Your source for this information is the font size of the root element. If you override that using a fixed unit like pixels, you discard this information.
Is 16px too large? Too small? How far away are your text size choices from being readable? You have no way of knowing because you threw that information away and decided 16px was good enough. 16px is not good enough for a lot of people.
The only way to ensure that the size of your text is readable for the user is to use a unit that is derived from their preferences somehow. That means that if you set a font size on the root element, it needs to be a unit like ems. Pixels break this mechanism completely.
Really, just give up trying to make ems work like pixels. You can’t, and everything you do to try to force the issue hurts your design. Design your text to be readable first and foremost. That’s its entire purpose for existing; to be read. If you can’t answer the question “is my body text a size that is readable to the user?”, then it’s bad design.
Is 16px too large? Too small? How far away are your text size choices from being readable? You have no way of knowing because you threw that information away and decided 16px was good enough. 16px is not good enough for a lot of people.
The only way to ensure that the size of your text is readable for the user is to use a unit that is derived from their preferences somehow. That means that if you set a font size on the root element, it needs to be a unit like ems. Pixels break this mechanism completely.
Really, just give up trying to make ems work like pixels. You can’t, and everything you do to try to force the issue hurts your design. Design your text to be readable first and foremost. That’s its entire purpose for existing; to be read. If you can’t answer the question “is my body text a size that is readable to the user?”, then it’s bad design.
You're right… your reply made me realize that was a bad habit carried over from a pixel art website. I need to remit control of my site's base font size. Taking this line off my other projects.
Huh, interesting. I've been using a clamped version of 1.5vw + 1vh for landscape and 1vw + 1vh for portrait, and then scaling everything else by rem for consistency. Might give this a try though.
do you have any clamping suggestions for overflowing/wrapping text in buttons etc.?
I ask just because not very many people seem to clamp yet, so looking for experiences.
I ask just because not very many people seem to clamp yet, so looking for experiences.
I don’t understand why font size on mobile should be smaller. Being he device smaller, font sizes should increase, if any.
Others commenters are right here - don’t mess up with the font size, please.
Others commenters are right here - don’t mess up with the font size, please.
Is there a way to do a curved function instead of a linear function?
Medium.com is the worst offender. Their font size is small and they disable zooming on mobile!