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