I am happy they didn’t do one of my biggest pet peeve: touching the base font-size (such as a plain <p>). Users can (& should) set values in their use agent to their preferred size & websites should respect it. No, I don’t want 12px hard coded as it’s too small for me. No, I don’t want the font size to mysteriously grow bigger on wide viewport as I already have it set at a comfortable size for that too. I see this too often & it massively hurts accessibility.
When I try to push for adhering to standards like respecting Accept-Language in projects at work, it's always shot down with the argument that the user doesn't know how to configure their applications properly so we have to do it for them.
I imagine something similar gets said for font size :/
I recently got the same argument about target="_blank". The speaker thought users would rather have a link forced into a new tab than learn to control whether it opens in a new tab or not.
I cut target=_blank from my rant as a bit too much. It’s the same thing tho… you went from having like 5 different action that allow new tab, to now having 0 ways to do the default behavior: opening in current tab. When to use target="_blank" is still one of my favorite posts.
I was against target=_blank, but my boss really insisted on it. I think in retrospect, it does make sense in a lot of cases where users will expect the link to open a new tab, but it is sort of prioritizing the lowest common denominator over the power user.
When you design for low-common-denominator type users, that is what you get. If you design for power users & treat users with respect, those are the users that will be attracted to what you build. This is how you get a generation of mobile-OS-only, cloud-first, what-is-a-file/directory users by coddling in this way. It’s depressing—as you get no reward for actually exploring your digital setting, reading the settings/manual, when folks just disregard things. As the ones building on the technology & knowing more about it than the marketing team, we should have the ability to veto these calls on these accessibility grounds. …& as a poweruser, I always prefer/praise the tools that respect me.
/rant
It’s still worth pushing back per project on Accept-Language since you have the right idea. It drives me nuts when I have to use Google (Maps being the only place with PoI’s data, Google Form was chosen as the survey host, etc.) & I get foreign languages when I didn‘t ask for it & many times there isn’t even a language-switching button in sight—& they still show dates using the counting system of the region just in English if I switch (so SEA uses the Buddhist calendar years which unhelpfully means I need to do math to subtract 543 from the year). One downside with it specifically tho with Accept-Language is that it was one of the earliest fingerprinting vectors, so the likes of Tor-settings-inspired browsers will be sending "en-US", "en", but I don’t think that changes a whole lot; as I’m sure you use Accept-Language as the fallback/default & the UI gives an clearly-present button to explicitly set.
This variable and this data attribute are not useful.
Get people to write <html style="font-family:serif"> instead,
it’s roughly as easy in both templating and client-side scripting,
and shorter and less complicated.
As it is, it may mislead people into thinking they could write
<html data-font-family="some-webfont, serif">, which won’t work.
Also: do not use monospace as your document font.
It’s a stylistic choice inconducive to readability,
and when a stylesheet is named “readable.css”, well…
But to praise them: I’m glad to see restraint to a single generic family.
--line-width: 0.125rem;
--line-height: 1.5;
Ouch! First “line” means “ruled lines between elements”,
second means “run of text”.
[A tangled combinatorial explosion of (prefers-color-scheme) and (prefers-contrast) media queries,
and [data-theme] and [data-high-contrast] selectors.]
This stuff was poorly planned and written.
Some of the values and interactions are not documented.
The @media (prefers-contrast: more) and (prefers-color-scheme: dark) combination (in the absence of <html data-*> overrides) is obviously broken, giving #000 on #fff.
It also needs color-scheme: dark and color-scheme: light declarations.
a {
color: inherit;
}
You know what, I’m stopping there.
I’m not even going to get to the false claim of vertical rhythm.
This is such a bad thing, I just can’t respect the stylesheet.
I might possibly have let it pass, but the nav styles suppress text-decoration,
and are a disaster.
(There are a couple of popular styles of header and footer where nav can often get away with this,
but this nav thing does not so qualify.
A large fraction of users will not realise that there are are links there.)
Do not do this.
Leave links blue (or at least a saturated accent colour),
leave links underlined,
or I will be disappointed with you.
Your comment reminds me about an other I wrote a while ago about readability. I am by no means an actual expert, but one thing I do notice is that very few people are aware that things like readability have been researched and fairly well understood for decades ago. I figure I might as all share the information from that other comment in here for those interested.
There are two main principles I often encounter being done "wrong" which I'll mention specifically. Line length and font choice. But, there is a lot more to readability on websites like font size, line height, contract and much, much more. So I'll also link to a variety of other resources as well.
Line length (or width if you will)
Line length has a minimum and maximum size that allows most people to comfortably read text. This range is roughly between 50-70 characters per line. For resources:
As I mentioned it is closely linked to accessibility, so it is not surprising the W3C WCAG also contains something about it stating"Width is no more than 80 characters or glyphs (40 if CJK)."
A bunch of the resources I will cover below also echo a variant of this rule. I didn't link them here since they go in many more aspects of typography as well.
Font choice
Sans-serif fonts generally speaking are easier to read on the widest range of screens. Having said that, on modern higher dpi screens Serif fonts generally are considered to be equal. Monospaced fonts are rarely a good choice as they reduce legibility for most people. The exception here might be people who work a lot in terminals and code editors who are used to monospaced fonts and people with dyslexia who sometimes have an easier time reading text in monospaced fonts. While not exciting, when in doubt Arial is the safest choice ;) Resources:
- Stack exchange thread on monospaced fonts
Other resources.
The US government has an entire page devoted to typography. These are guidelines for government websites, but effectively apply a lot of sound principles. Which makes it worth going through.
If you really want to go for an extreme deep dive, Butterick's Practical Typography goes in extreme detail for everything. It probably is overkill for most people, but when in doubt it likely is then and properly cited with sources.
I chose to submit this because, while I am always on the lookout for frameworks like PicoCSS and MVP, this one caught my eye since it's meant to be a starting point. It seems like a nice place to build from, but I'd love the thoughts of folks with more design knowledge than I possess.
Honestly, the default font-size is too low and it is hard to read. I don't understand why folks go for this sort of size. It is not accessible and readable to me.
This is downstream of two issues in the web platform.
First, as toastal notes, it's beneficial to stick to browser-provided fonts&font-sizes, as that honors user preferences, if they explicitly stated those. But it is also true that a) very few users explicitly state their preferences (c.f. opt-in vs opt-out for organ donations) and b) on many common default configurations, the resulting font size is too small, on the lower end of legible, due to browser vendors not changing historically contingent defaults.
But it gets worse: font-size doesn't have stable, absolute meaning across different fonts. font-size: 16px can be quite different depending on specific font. For example, here's how default sans and default sans-serif fonts look for me on Safari: https://github.com/user-attachments/assets/182608e1-3224-4f02-8d94-9ee2850dbf08. You probably can notice how in this very comment the size of monospace font doesn't match the rest :-)
So, you just can't fix this properly. Something will be broken somewhere, and it's a question of webmaster's personal preferences regarding the tradeoff. For myself, I stoped caring about website's design, as long as I can use reader mode. Though, the undefinedness of font-size part has a decent fix these days: https://matklad.github.io/2025/07/16/font-size-adjust.html.
Okay, cool, I'm not going crazy then... I have a weird 140ppi monitor that looks bad at the 125% scaling I probably should apply to it, and so instead I run at 100% and do fun default-zoom tricks to make things readable. I was wondering if this site somehow bypassed that zoom level because wow those fonts are tiny.
cranks Firefox minimum font size setting up another notch
toastal | a day ago
I am happy they didn’t do one of my biggest pet peeve: touching the base font-size (such as a plain
<p>). Users can (& should) set values in their use agent to their preferred size & websites should respect it. No, I don’t want 12px hard coded as it’s too small for me. No, I don’t want the font size to mysteriously grow bigger on wide viewport as I already have it set at a comfortable size for that too. I see this too often & it massively hurts accessibility.Sharparam | a day ago
When I try to push for adhering to standards like respecting
Accept-Languagein projects at work, it's always shot down with the argument that the user doesn't know how to configure their applications properly so we have to do it for them.I imagine something similar gets said for font size :/
kevinc | 14 hours ago
I recently got the same argument about
target="_blank". The speaker thought users would rather have a link forced into a new tab than learn to control whether it opens in a new tab or not.toastal | 10 hours ago
I cut
target=_blankfrom my rant as a bit too much. It’s the same thing tho… you went from having like 5 different action that allow new tab, to now having 0 ways to do the default behavior: opening in current tab. When to usetarget="_blank"is still one of my favorite posts.wink | 11 hours ago
Valid opinion! In 1999.
diktomat | 9 minutes ago
Well, I can’t configure my browser to ignore it in 2026, so valid still.
carlana | 3 hours ago
I was against target=_blank, but my boss really insisted on it. I think in retrospect, it does make sense in a lot of cases where users will expect the link to open a new tab, but it is sort of prioritizing the lowest common denominator over the power user.
toastal | 14 hours ago
When you design for low-common-denominator type users, that is what you get. If you design for power users & treat users with respect, those are the users that will be attracted to what you build. This is how you get a generation of mobile-OS-only, cloud-first, what-is-a-file/directory users by coddling in this way. It’s depressing—as you get no reward for actually exploring your digital setting, reading the settings/manual, when folks just disregard things. As the ones building on the technology & knowing more about it than the marketing team, we should have the ability to veto these calls on these accessibility grounds. …& as a poweruser, I always prefer/praise the tools that respect me.
/rant
It’s still worth pushing back per project on
Accept-Languagesince you have the right idea. It drives me nuts when I have to use Google (Maps being the only place with PoI’s data, Google Form was chosen as the survey host, etc.) & I get foreign languages when I didn‘t ask for it & many times there isn’t even a language-switching button in sight—& they still show dates using the counting system of the region just in English if I switch (so SEA uses the Buddhist calendar years which unhelpfully means I need to do math to subtract 543 from the year). One downside with it specifically tho withAccept-Languageis that it was one of the earliest fingerprinting vectors, so the likes of Tor-settings-inspired browsers will be sending"en-US", "en", but I don’t think that changes a whole lot; as I’m sure you useAccept-Languageas the fallback/default & the UI gives an clearly-present button to explicitly set.chrismorgan | 15 hours ago
This variable and this data attribute are not useful. Get people to write
<html style="font-family:serif">instead, it’s roughly as easy in both templating and client-side scripting, and shorter and less complicated. As it is, it may mislead people into thinking they could write<html data-font-family="some-webfont, serif">, which won’t work.Also: do not use monospace as your document font. It’s a stylistic choice inconducive to readability, and when a stylesheet is named “readable.css”, well…
But to praise them: I’m glad to see restraint to a single generic family.
Ouch! First “line” means “ruled lines between elements”, second means “run of text”.
This stuff was poorly planned and written. Some of the values and interactions are not documented. The
@media (prefers-contrast: more) and (prefers-color-scheme: dark)combination (in the absence of<html data-*>overrides) is obviously broken, giving #000 on #fff.It also needs
color-scheme: darkandcolor-scheme: lightdeclarations.You know what, I’m stopping there. I’m not even going to get to the false claim of vertical rhythm. This is such a bad thing, I just can’t respect the stylesheet. I might possibly have let it pass, but the nav styles suppress text-decoration, and are a disaster. (There are a couple of popular styles of header and footer where nav can often get away with this, but this nav thing does not so qualify. A large fraction of users will not realise that there are are links there.)
Do not do this. Leave links blue (or at least a saturated accent colour), leave links underlined, or I will be disappointed with you.
And it called itself readable.css!
creesch | 11 hours ago
Your comment reminds me about an other I wrote a while ago about readability. I am by no means an actual expert, but one thing I do notice is that very few people are aware that things like readability have been researched and fairly well understood for decades ago. I figure I might as all share the information from that other comment in here for those interested.
There are two main principles I often encounter being done "wrong" which I'll mention specifically. Line length and font choice. But, there is a lot more to readability on websites like font size, line height, contract and much, much more. So I'll also link to a variety of other resources as well.
Line length (or width if you will)Line length has a minimum and maximum size that allows most people to comfortably read text. This range is roughly between 50-70 characters per line. For resources:
-
This stack exchange thread has some decent responses about the matter.
- As I mentioned it is closely linked to accessibility, so it is not surprising the W3C WCAG also contains something about it stating"Width is no more than 80 characters or glyphs (40 if CJK)."
- A bunch of the resources I will cover below also echo a variant of this rule. I didn't link them here since they go in many more aspects of typography as well.
Font choiceSans-serif fonts generally speaking are easier to read on the widest range of screens. Having said that, on modern higher dpi screens Serif fonts generally are considered to be equal. Monospaced fonts are rarely a good choice as they reduce legibility for most people. The exception here might be people who work a lot in terminals and code editors who are used to monospaced fonts and people with dyslexia who sometimes have an easier time reading text in monospaced fonts. While not exciting, when in doubt Arial is the safest choice ;) Resources: - Stack exchange thread on monospaced fonts
Other resources.alexandria | 3 hours ago
There is also Atkinson Hyperlegible, which was designed by the Braille Institute to be legible to a wide audience of people.
[OP] yonkeltron | a day ago
I chose to submit this because, while I am always on the lookout for frameworks like PicoCSS and MVP, this one caught my eye since it's meant to be a starting point. It seems like a nice place to build from, but I'd love the thoughts of folks with more design knowledge than I possess.
aae | 18 hours ago
i use picocss on a lot of projects. thanks for submitting this, i love this kinda stuff
this is also the first i've seen MVP
mysticmode | a day ago
Honestly, the default font-size is too low and it is hard to read. I don't understand why folks go for this sort of size. It is not accessible and readable to me.
matklad | 21 hours ago
This is downstream of two issues in the web platform.
First, as toastal notes, it's beneficial to stick to browser-provided fonts&font-sizes, as that honors user preferences, if they explicitly stated those. But it is also true that a) very few users explicitly state their preferences (c.f. opt-in vs opt-out for organ donations) and b) on many common default configurations, the resulting font size is too small, on the lower end of legible, due to browser vendors not changing historically contingent defaults.
But it gets worse:
font-sizedoesn't have stable, absolute meaning across different fonts.font-size: 16pxcan be quite different depending on specific font. For example, here's how defaultsansand defaultsans-seriffonts look for me on Safari: https://github.com/user-attachments/assets/182608e1-3224-4f02-8d94-9ee2850dbf08. You probably can notice how in this very comment the size ofmonospacefontdoesn'tmatchtherest :-)So, you just can't fix this properly. Something will be broken somewhere, and it's a question of webmaster's personal preferences regarding the tradeoff. For myself, I stoped caring about website's design, as long as I can use reader mode. Though, the undefinedness of
font-sizepart has a decent fix these days: https://matklad.github.io/2025/07/16/font-size-adjust.html.klardotsh | 14 hours ago
Okay, cool, I'm not going crazy then... I have a weird 140ppi monitor that looks bad at the 125% scaling I probably should apply to it, and so instead I run at 100% and do fun default-zoom tricks to make things readable. I was wondering if this site somehow bypassed that zoom level because wow those fonts are tiny.
cranks Firefox minimum font size setting up another notch