[dextorious]

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]

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.

[ugh]

What’s the alternative? I know of no PPI-aware way of specifying font size.

[Thrymr]

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]

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]

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]

> 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.

[Chris_Newton]

CSS3 media queries can help with this:

http://www.w3.org/TR/css3-mediaqueries/

A realistic strategy today is to assume a typical desktop monitor by default, since not all popular desktop browsers implement media queries to a useful extent. Then you can add specific CSS sections for hardware with very different parameters, such as screens on mobile devices. Usually being both newer and more in need, mobile OSes and the browsers running on them typically support media queries better, so while not always ideal, this approach works fairly well in practice.

[dextorious]

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]

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]

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]

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]

My bad, I meant resize as in zoom-in out (Ctrl +-) of the page in general, not the $(window).resize().