Pixels and Accessibility(joshwcomeau.com)
joshwcomeau.com
Pixels and Accessibility
https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/
20 comments
> "So maybe 'rems for body text, px for headings' is the way to go."
what's probably a little more useful is that headings scale up slower than body text, using different clamp() functions, e.g., https://www.aleksandrhovhannisyan.com/blog/fluid-type-scale-...
what's probably a little more useful is that headings scale up slower than body text, using different clamp() functions, e.g., https://www.aleksandrhovhannisyan.com/blog/fluid-type-scale-...
Browsers typically support a minimum font size setting.
That's not quite the right thing either, alas, because sometimes there's text that's legimately supposed to be "small print" where it's OK if it's hard to read. In practice setting it high tends to go wrong near small buttons.
Ideally what I want in an accessibility-settings dialog is "minimum font size that I can comfortably read", and a way for UI authors to say "this is normal body text".
Instead what we tend to get is blanket advice like Android's "use sp dimensions for text", which simply scales everything up.
iOS's preferredFontFor textStyle stuff seems like the right approach in principle, but they still seem to have the idea that if I want large body text I must also want huge headings (which is terrible, because if I have large body text I also have less space than usual).
Ideally what I want in an accessibility-settings dialog is "minimum font size that I can comfortably read", and a way for UI authors to say "this is normal body text".
Instead what we tend to get is blanket advice like Android's "use sp dimensions for text", which simply scales everything up.
iOS's preferredFontFor textStyle stuff seems like the right approach in principle, but they still seem to have the idea that if I want large body text I must also want huge headings (which is terrible, because if I have large body text I also have less space than usual).
> 1px is equal to a single dot in a computer monitor or phone screen.
Far from always!
“For screen displays, it traditionally represents one device pixel (dot). However, for printers and high-resolution screens, one CSS pixel implies multiple device pixels. 1px = 1/96th of 1in.”
— https://developer.mozilla.org/en-US/docs/Web/CSS/length
Far from always!
“For screen displays, it traditionally represents one device pixel (dot). However, for printers and high-resolution screens, one CSS pixel implies multiple device pixels. 1px = 1/96th of 1in.”
— https://developer.mozilla.org/en-US/docs/Web/CSS/length
The article does talk about this directly after about the sentence you quoted.
But the part the parent commenter quoted is incorrect and the article would be better for having that fixed. The explanation that follows is misleading as well (it's not a "bit of a lie") and would also benefit from not introducing hardware sub-pixels into the discussion (which are irrelevant).
>“For screen displays, it traditionally represents one device pixel (dot). However, for printers and high-resolution screens, one CSS pixel implies multiple device pixels. 1px = 1/96th of 1in.”
And this multiple isn't necessarily an integer, it's specified as a floating point number (though I've in practice only seen fractional parts of .5 (on a samsung galaxy IIRC) )
( https://developer.mozilla.org/en-US/docs/Web/API/Window/devi... )
And this multiple isn't necessarily an integer, it's specified as a floating point number (though I've in practice only seen fractional parts of .5 (on a samsung galaxy IIRC) )
( https://developer.mozilla.org/en-US/docs/Web/API/Window/devi... )
Blink on Android maps CSS pixels to Android's DP (density-independent pixel) unit, which is derived from a device's "density bucket", which traditionally has been defined by some multiple of 160ppi in .5x increments. There are some oddball values out there (e.g. the "tvdpi" bucket for Android TV apps), but you'll usually see the .5 multiple on phone-sized screens.
This is one of the long form frontend blogs that I greatly enjoy, and learn sometime new every time. So, I am excited anytime a new one comes out. I hope with Josh releasing his own course[1], that the blog continues to provide excellent resources for "free".
[1](https://css-for-js.dev/)
[1](https://css-for-js.dev/)
Appreciate it :)
And yeah, the plan is to keep providing a bunch of free content, knowing that a small % of people who read the blog will go on to buy the course. Way more sustainable than it used to be, when this was something I did outside of my job.
And yeah, the plan is to keep providing a bunch of free content, knowing that a small % of people who read the blog will go on to buy the course. Way more sustainable than it used to be, when this was something I did outside of my job.
It'd be more accurate and illuminating to say that a px is an angle.
The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch). - https://www.w3.org/TR/css-values-4/#absolute-lengths
This explains why 1px is small on phones and large on televisions; the physical size varies by expected reader distance. The angle tries to stay constant, though in practice it gets rounded to the nearest multiple of the physical pixel size.
The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch). - https://www.w3.org/TR/css-values-4/#absolute-lengths
This explains why 1px is small on phones and large on televisions; the physical size varies by expected reader distance. The angle tries to stay constant, though in practice it gets rounded to the nearest multiple of the physical pixel size.
It's quite ironic how the font settings page for Chrome doesn't do well with different font sizes itself. They got the sidebar backwards and appeared to have used px for the font-size but em for the padding.
> In theory, 1px is equal to a single dot in a computer monitor or phone screen.
Even in theory, this has never been true AFAIK. Pixels (px) are relative to the properties of the viewing device, the user's OS and browser settings, etc. The author appears to be confusing "physical pixel" with "logical pixel".
Even in theory, this has never been true AFAIK. Pixels (px) are relative to the properties of the viewing device, the user's OS and browser settings, etc. The author appears to be confusing "physical pixel" with "logical pixel".
There is a big blue information box in the article that explains this. It's called "Hardware vs. software pixels".
I agree with CharlesW here. That information box doesn't mention that a normal grid of pixels can also have a non 1-to-1 mapping between physical and logical pixels. Any discussion of pixels that doesn't specifically call out `window.devicePixelRatio` is not going to give people a complete understanding.
This is important. If you're rendering images/graphics with a pixel as your smallest unit then you're not going to look good on most modern devices.
This is important. If you're rendering images/graphics with a pixel as your smallest unit then you're not going to look good on most modern devices.
Along with talking about very different issues in that aside, the author calls the px unit "a bit of a lie" when in fact CSS pixels have always been logical (not physical) pixels. My editor-hat advice is that the article would benefit from a rewrite of the px explanation, and I'd also recommend eliminating the confusing hardware pixels vs. sub-pixels distinction.
Try reading more. He’s not confusing anything, he specifically calls out how resolution changes and such effect things.
(Or, ideally, "make small text and fiddly diagrams bigger, but leave most images alone", but let's walk before we try to run.)
So maybe "rems for body text, px for headings" is the way to go.