[Chris_Newton]

This is an important issue to consider, but talking about "pixels" alone doesn't get us far in this context.

For one thing, different fonts have different design characteristics. In particular, the x-height of one sensible body font at a nominal 16px could easily be 50% more than the x-height of another. Sadly, while CSS lets us specify a stack of fonts to try, it doesn't yet let us specify a different size to go with each one so we can achieve a similar optical result. (CSS3's font-size-adjust might be intended to help here, but seems overcomplicated and underpowered to me.)

For another thing, these days pixel densities can vary by at least a factor of 3 between devices. The latest iThings sometimes do better than the 300dpi that used to the be benchmark for a laser printer. For a classic CRT or cheap and cheerful TFT, something more like 96dpi is common. At least you can detect this to some extent in CSS, because the new devices with very high densities also tend to support media queries so you can present larger text (in pixel terms) and higher resolution graphics accordingly.

If we're going to improve the way we present text (and graphics) on the web for people whose vision isn't perfect, it's going to take a much more flexible styling system for the web and probably a lot more real world experience of what works and what doesn't as well. As much as I respect people taking a stand on behalf of those who can't see as well as some, I'm not sure advocating a fairly arbitrary 16px guideline is helping.

[blahedo]

> For another thing, these days pixel densities can vary by at least a factor of 3 between devices.

It pains me to point this out, but the solution to this particular problem is that CSS has redefined what "pixel" means, or rather, they've made "px" stand for something slightly different. Specifically, the "px" specifier now is a scaled length unit, and corresponds to whatever length subtends the same arc in a user's field-of-view as would a single pixel on a typical desktop display at about two feet away. So technically, in order to know how many pixels a px is, you need to know the resolution of the display, the size of the display, and the distance from it that the user will be sitting.

(Argh)

[Chris_Newton]

Yes, CSS has an unhelpful definition of pixels, which AFAICS is almost universally ignored. No doubt it was well-intentioned, but in the real world, pixels have fixed sizes and display devices do not have infinite resolutions. The difference between professional quality web design and an amateurish mess can be as simple as paying attention to the real pixel grid that your beautiful vector icon/font/whatever will be drawn on and shifting/hinting/whatever accordingly.

Given that CSS also recognises length units such as pt, which make far more sense if you really want to specify a physical size for something like a font, distorting the meaning of "pixel" doesn't seem very useful. It's a little like idealised fluid layouts, which quickly gave way to the practical benefits of more controlled layouts and more recently to responsive designs that are specifically tailored to the strengths and weaknesses of different browsing environments. Good design often requires an element of precision, which you simply can't specify if browsers keep moving the goalposts.

[bzbarsky]

> which AFAICS is almost universally ignored.

Safari on iPhone uses that definition (that's the whole "resolution doubling" thing, in a nutshell).

Gecko uses that definition, including on mobile devices.

In fact, that definition is almost universally _used_ in cases where it matters (i.e. high-dpi displays).

> Given that CSS also recognises length units such as pt

Which are nowadays defined in terms of CSS px, because otherwise sites break. So 1pt == 1.3333px in CSS in most modern browsers.

[Chris_Newton]

> Safari on iPhone uses that definition (that's the whole "resolution doubling" thing, in a nutshell).

That's my point, though: no-one is really implementing CSS-px. What they're doing is implementing approximations, like doubling everything up on a high-dpi screen because the pixel pitch is roughly twice what you get on a typical desktop monitor, which is close enough to be workable.

If browsers implemented CSS-px as specified, then on all the monitors in front of me, the text on most pages I have open right now would look the same size in Firefox, and not noticeably smaller on some monitors than others. Also, all those beautiful, crisp n-pixel borders on mobile-friendly sites would look terrible (because they would be rendered with different degrees of fuzziness due to the antialiasing on different mobile devices) and everyone's photographs on Facebook would be blurry. Of course, that's a silly idea, and no browser actually does it (other than when zooming).

Most of the major mobile browsers (possibly all by now) support restricting the viewport and zoom so you can match your site to real, physical screen properties instead of whatever virtual viewport size they pretend to have by default. IME, a fairly high proportion of mobile-specific and responsive pages now start by switching this on. No-one's going to change this functionality any time soon, because vast numbers of mobile-optimised sites would immediately break. Fortunately, that means we can go into real-physical-dimensions modes and then use media queries to select an appropriate layout (including text sizes) for smaller, high-dpi devices as part of a design, without sacrificing precision in cases where the time and money is there to work on the fine details for best results on that kind of device.

[bzbarsky]

> What they're doing is implementing approximations

The definition of CSS-px (for low-res devices, which includes all the mobile stuff so far; high-res in this context is print) is:

  it is recommended that the pixel unit refer to the whole
  number of device pixels that best approximates the
  reference pixel

and the reference pixel is defined as:

  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.

See http://www.w3.org/TR/CSS2/syndata.html#length-units

So the whole point is to approximate the reference pixel by doubling your device pixels (or tripling, or whatever).

I think you may be thinking of a different definition of CSS pixel that used to exist a number of years ago (when "px" and reference pixels were the same thing). That definition is no longer in the spec, and hasn't been in a while. And that's precisely because of the antialiasing issues you mention.

[Chris_Newton]

Yes, the official W3C recommendation changed to CSS2.1 earlier this year, and they did effectively redefine a CSS pixel at that stage. I'm not sure this did more than swap one problem for another, though: as I read the (current) wording, we shouldn't get fractional physical pixels any more and basic arithmetic still works on pixel lengths, but now you can only scale up by a factor of 2x, 3x, etc.

Given that the point we're debating here is the merits of setting a minimum 16px body text size, that would mean the next alternative was 32 physical pixels on a display of roughly 200dpi resolution. While that might be useful, you could still find that depending on the physical properties of your devices, 16px text needed to render at say 24 physical pixels to look the same size to the reader.

When you've got that kind of uncertainty to work with, I stand by my earlier comments that an arbitrary 16px size without reference to either the specific font or the physical properties of the device isn't a particularly useful guideline. The design considerations for devices with such different physical properties are too complicated to dismiss with a simple scale factor.

[Corrado]

I agree completely! When I started using my 27" Apple Cinema Display I was in heaven, except for having to squint to see stuff. The monitor is really great but it has a insane resolution that tends to make text much smaller.

BTW: Different fonts do work better at different sizes, and the article specifically mentions that fact.