11 ms·

Am I missing something? The physical size of a 16px font will surely vary based on resolution and screen size. So claims such as '16px is the same as most boo

by Simon_M 15y ago

Am I missing something? The physical size of a 16px font will surely vary based on resolution and screen size. So claims such as '16px is the same as most books' are clearly nonsense.

ugh 15y ago
* for common pixel densities.
larrik 15y ago
Note that the author means "fonts/sizes that are 16 pixels tall" NOT "16 point fonts" (which is what you get when you pick 16 in MS Word or whatever). The difference in terminology is subtle to look at, but huge in practice.
dextorious 15y ago
He means "for the most common monitor DPIs", duh. The problem is: due to the need to mix and align with bitmap graphics, web design is most convenient when specifying font sizes in pixels (except for simple pages, like HN and such, fluid designs cannot cover most cases in a mainstream enough fashion). So, given that, he had to mention a specific pixel setting. But he took into account most common DPIs. For the majority of users they do not vary that much, around 100-120 dpi. (Btw, have you read the article? He is aware of that, and he even gives examples of 16px in different DPI screens).
- Thrymr 15y ago
  Can we get over specifying text size by pixels already? You don't know what DPI monitor I will have when I look at your pages.
  - dextorious 15y ago
    Unfortunately we can't. Maybe for copy text it's ok, but not for other page elements, ones that we want to align in a specific way to bitmap images, no. The page-zoom style resizing is our best bet --it's the "resolution independent" way to have your pixels and eat them too. Now, if we could provide bitmap assets that could be zoomed in the same way, instead of just showing bigger but more pixelated (as we can in application icons in OS X), we would be done.
    - wladimir 15y ago
      Now, if we could provide bitmap assets that could be zoomed in the same way The most common way (used for icons) is to provide multiple bitmaps and load the right one depending on screen DPI. You can do this on your site too. And there's of course vector graphics (SVG), if you don't mind some extra processing on the client for rendering...
      - dextorious 15y ago
        Yes, you could provide multiple bitmaps in a website now, but in a convoluted way (with some custom javascript checking for resize events etc). In the icons case, it happens automatically. As for SVG, client rendering time would be insignificant for most case (for a desktop machine at least, they have CPU to spare). But currently used IE version (> 6) for one don't support SVG. And the main problem are bitmap assets such as photographs. Those cannot be done as vectors.
        wladimir 15y ago
        Sure... I didn't say that it would happen automatically, just that it could be done. Everything done on the web is convoluted. Btw: why would you have to watch resize events? Changing the size of the browser window (even rotating the screen/phone) doesn't change the DPI.
        dextorious 15y ago
        My bad, I meant resize as in zoom-in out (Ctrl +-) of the page in general, not the $(window).resize().
  - ugh 15y ago
    What’s the alternative? I know of no PPI-aware way of specifying font size.
    - Thrymr 15y ago
      Display PostScript - circa 1987 (thanks, Steve Jobs). I know there isn't a good current alternative in the web world, but shouldn't it be a goal to not have to specify pixels anymore? Obviously mobile browsers already largely ignore/change pixel font sizes.
      - ugh 15y ago
        It’s a valuable goal but just that. A goal. It’s necessary to be pragmatic in the meantime. No point in dreaming. (If you didn’t notice, we are talking about the web here.)
        Thrymr 15y ago
        I understand the difference between pragmatism and dreaming. In the short term, that pragmatism should include web devs not trying to lay everything out pixel-perfect so it breaks if the user hits "zoom". The diversity of screen sizes and browsers and DPIs is greater than it has ever been, and will only increase.
        Chris_Newton 15y ago
        > The diversity of screen sizes and browsers and DPIs is greater than it has ever been, and will only increase. That may be true, but beyond a certain point, it doesn't matter. In terms of physical size, it makes sense to have a single-column layout for small devices, where layout techniques like using multiple columns are never going to be very useful no matter how high the resolution gets. You might prioritise some content more highly and reduce or eliminate less valuable material to go with this. It also makes sense to allow for layouts that do have wider areas and/or multiple columns if the content can benefit and the display medium can support it. I doubt anyone is going to want to render most web pages with dozens of columns any time soon, though, no matter what physical size a screen might reach. Most content isn't going to benefit from that, because the human eye and brain can only take in so much at once anyway. So the big question here is how many discrete layouts are useful in practice, with a whole load of secondary questions about the balance between showing more content at once vs. allowing user interaction to navigate content in different ways. In terms of resolution, the consideration is different, but there is still a general case. At low resolutions, it is worth having specific, pixel-perfect designs. At somewhat higher resolutions, it is worth having different pixel-perfect designs, to give sharper results at a similar physical size. Sometimes it is best if pixel-based designs don't try to copy all the detail of the "true" designs as they get smaller, but present simpler, cleaner versions of the same basic idea instead. At some point, your resolution gets high enough that scaling vectors representing the "true" designs by default and using techniques like antialiasing and font hinting becomes a viable alternative. Somewhere beyond that, vectors alone would be sufficient, as the eye isn't powerful enough to see any more detail anyway. The big questions are where on this scale you change from one pixel-perfect format to another, and how many such formats you produce before you switch to using scalable vectors. In the real world, of course, these two ideas interact at times, and there is a cost/benefit trade-off as well. Perhaps you would prefer to have three sizes of pixel-perfect versions of all your custom graphics plus a vector, but in reality you might have only one or two and accept that content will appear at significantly different physical sizes on different devices. Perhaps you would like to have a responsive design with four different layouts, but in reality a mobile-friendly version and a regular site will do. You'll still be able to cater well to many different devices with only a small number of combinations if they are well thought-out, though.

by Simon_M 15y ago

Am I missing something? The physical size of a 16px font will surely vary based on resolution and screen size. So claims such as '16px is the same as most books' are clearly nonsense.

ugh 15y ago

* for common pixel densities.

larrik 15y ago

Note that the author means "fonts/sizes that are 16 pixels tall" NOT "16 point fonts" (which is what you get when you pick 16 in MS Word or whatever). The difference in terminology is subtle to look at, but huge in practice.

dextorious 15y ago

He means "for the most common monitor DPIs", duh. The problem is: due to the need to mix and align with bitmap graphics, web design is most convenient when specifying font sizes in pixels (except for simple pages, like HN and such, fluid designs cannot cover most cases in a mainstream enough fashion). So, given that, he had to mention a specific pixel setting. But he took into account most common DPIs. For the majority of users they do not vary that much, around 100-120 dpi. (Btw, have you read the article? He is aware of that, and he even gives examples of 16px in different DPI screens).

Thrymr 15y ago
Can we get over specifying text size by pixels already? You don't know what DPI monitor I will have when I look at your pages.
- dextorious 15y ago
  Unfortunately we can't. Maybe for copy text it's ok, but not for other page elements, ones that we want to align in a specific way to bitmap images, no. The page-zoom style resizing is our best bet --it's the "resolution independent" way to have your pixels and eat them too. Now, if we could provide bitmap assets that could be zoomed in the same way, instead of just showing bigger but more pixelated (as we can in application icons in OS X), we would be done.
  - wladimir 15y ago
    Now, if we could provide bitmap assets that could be zoomed in the same way The most common way (used for icons) is to provide multiple bitmaps and load the right one depending on screen DPI. You can do this on your site too. And there's of course vector graphics (SVG), if you don't mind some extra processing on the client for rendering...
    - dextorious 15y ago
      Yes, you could provide multiple bitmaps in a website now, but in a convoluted way (with some custom javascript checking for resize events etc). In the icons case, it happens automatically. As for SVG, client rendering time would be insignificant for most case (for a desktop machine at least, they have CPU to spare). But currently used IE version (> 6) for one don't support SVG. And the main problem are bitmap assets such as photographs. Those cannot be done as vectors.
      - wladimir 15y ago
        Sure... I didn't say that it would happen automatically, just that it could be done. Everything done on the web is convoluted. Btw: why would you have to watch resize events? Changing the size of the browser window (even rotating the screen/phone) doesn't change the DPI.
        dextorious 15y ago
        My bad, I meant resize as in zoom-in out (Ctrl +-) of the page in general, not the $(window).resize().
- ugh 15y ago
  What’s the alternative? I know of no PPI-aware way of specifying font size.
  - Thrymr 15y ago
    Display PostScript - circa 1987 (thanks, Steve Jobs). I know there isn't a good current alternative in the web world, but shouldn't it be a goal to not have to specify pixels anymore? Obviously mobile browsers already largely ignore/change pixel font sizes.
    - ugh 15y ago
      It’s a valuable goal but just that. A goal. It’s necessary to be pragmatic in the meantime. No point in dreaming. (If you didn’t notice, we are talking about the web here.)
      - Thrymr 15y ago
        I understand the difference between pragmatism and dreaming. In the short term, that pragmatism should include web devs not trying to lay everything out pixel-perfect so it breaks if the user hits "zoom". The diversity of screen sizes and browsers and DPIs is greater than it has ever been, and will only increase.
        Chris_Newton 15y ago
        > The diversity of screen sizes and browsers and DPIs is greater than it has ever been, and will only increase. That may be true, but beyond a certain point, it doesn't matter. In terms of physical size, it makes sense to have a single-column layout for small devices, where layout techniques like using multiple columns are never going to be very useful no matter how high the resolution gets. You might prioritise some content more highly and reduce or eliminate less valuable material to go with this. It also makes sense to allow for layouts that do have wider areas and/or multiple columns if the content can benefit and the display medium can support it. I doubt anyone is going to want to render most web pages with dozens of columns any time soon, though, no matter what physical size a screen might reach. Most content isn't going to benefit from that, because the human eye and brain can only take in so much at once anyway. So the big question here is how many discrete layouts are useful in practice, with a whole load of secondary questions about the balance between showing more content at once vs. allowing user interaction to navigate content in different ways. In terms of resolution, the consideration is different, but there is still a general case. At low resolutions, it is worth having specific, pixel-perfect designs. At somewhat higher resolutions, it is worth having different pixel-perfect designs, to give sharper results at a similar physical size. Sometimes it is best if pixel-based designs don't try to copy all the detail of the "true" designs as they get smaller, but present simpler, cleaner versions of the same basic idea instead. At some point, your resolution gets high enough that scaling vectors representing the "true" designs by default and using techniques like antialiasing and font hinting becomes a viable alternative. Somewhere beyond that, vectors alone would be sufficient, as the eye isn't powerful enough to see any more detail anyway. The big questions are where on this scale you change from one pixel-perfect format to another, and how many such formats you produce before you switch to using scalable vectors. In the real world, of course, these two ideas interact at times, and there is a cost/benefit trade-off as well. Perhaps you would prefer to have three sizes of pixel-perfect versions of all your custom graphics plus a vector, but in reality you might have only one or two and accept that content will appear at significantly different physical sizes on different devices. Perhaps you would like to have a responsive design with four different layouts, but in reality a mobile-friendly version and a regular site will do. You'll still be able to cater well to many different devices with only a small number of combinations if they are well thought-out, though.