I do have a high DPI display, and HN is ridiculously tiny without manually overriding, because it's setting text size in pixels instead of points, for no good reason. It doesn't make any sense. View source shows:
line-height:12pt; height:10px;
Why use device independent units for line-height, but not the text itself?
That's jlarocco's comment. He goes on to say that was done for "for no good reason", which suggest he's opposed to using pixels and prefers using points instead.
The rest of his comment gave me the impression that he prefers using points to pixels because:
1. on a high dpi display, each pixel is smaller
2. css pixels correspond to physical pixels
therefore using "px" in css would result in small text, whereas points presumably wouldn't have this issue.
>> "px" in css doesn't correspond to literal pixels on the display.
That's my comment. I mentioned this fact to correct his prior assumption that he thinks "px" in css corresponds to physical pixels on the display. I didn't explicitly state that 1.33px = 1pt because I couldn't find the exact reference for it, but I did go on to state it later.
>You ”justified” (I don’t know the intent of your comment, really) the use of points because pixels don’t match physical pixels.
no, I justified the use of pixels, because they were in fact independent of the physical pixels on the display, contrary to what jlarocco thinks. If they did in fact correspond to physical pixels on a display, that would be a defect on high dpi screens, because it would result in smaller text.
Thank you. It seems "px" is really the worst of both worlds, then.
It's not device independent like "pt", it's not what most people expect it to be (one device pixel), and there's subjective "wiggle room" in what it actually means.
>It's not device independent like "pt", it's not what most people expect it to be (one device pixel), and there's subjective "wiggle room" in what it actually means.
This seems to also be incorrect. px and pt are both absolute units, and 1.33px == 1pt. If you want relative units you need to use something like em.
em and rem are relative to properties on other nodes in the document's CSS hierarchy; they're not relative to some screen-size specific metric.
I've not studied the topic in any depth, but I believe that an adaptive ruleset would just use CSS media queries (use this font size when viewport width is more than something). That is what Bootstrap does. Or, use viewport-relative units like vw, vh, vmin, vmax, but I doubt that would work well.
1rem is the font size of the html element, which if you don't set it otherwise, is relative to user-agent decisions about what 1rem is. Which could be related to screen size or density, but it's up to the user-agent, I don't know if any adjust it so automatically by default (although it would make a lot of sense).
It is, in actual practice, based on user preferences though, if you set your browser to display fonts bigger, 1rem will be bitter. 16px or pt... might not be? So hard to keep track, this stuff is such an accretion of workarounds on top of legacies on top of odd choices.
>they're not relative to some screen-size specific metric.
The fundamental problem here is that the browser can only adjust for device pixel density and not other variables that affect visibility (eg. the viewer's visual acuity or the viewing distance). That said, using absolute units is still the best choice for text size, considering the other relative units (eg. relative to viewport size) is worse.
>I've not studied the topic in any depth, but I believe that an adaptive ruleset would just use CSS media queries (use this font size when viewport width is more than something).
HN has this. See the /* mobile device */ section in news.css.
