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

[bzbarsky]

Yeah, I agree that saying "use 16px font-size" without mentioning at least the font family is completely useless.