whilst the detachment of 'px' and screen pixels is a no brainer in the modern world with its proliferation of pixel densities and viewing distances on different devices, the CSS standard could probably do a better job of explaining this.
Is it really the place of the CSS standard to define it? Is that even remotely necessary?
I mean, every device is different. You don't want a "px" on your phone to be the same as a "px" on your desktop, which also shouldn't be the same as a "px" on your projector.
A "px", right now, is whatever the device+OS combo wants it to be, but that works, because they all try to make things the "right size" given the device size, resolution, and distance from your eye.
And it works fine. Just accept that "px" is device-defined, and it all works, just like it does now in practice.
Nope! "px" is defined by the CSS spec. The physical pixels are device-defined as is the exact anti-aliasing algorithm but the spec dictates the dimensions of a logical ("px") pixel in the real world. Devices are not free to make "px" whatever they want it to be, because "px" is a logical pixel not a physical one. (Though it is a physical length).
A classic example of why this matters is that Windows treats the screen as 96dpi but OS X treats it as 72dpi. If the CSS spec did not dictate the size of a "px" then all web pages on OS X would look 26% smaller than on Windows.
I just added a 960px <hr> to this web page. On my monitor, attached to a MBP running OS 10.6, it measures about 9.5 inches (by holding up a ruler to the screen). That would indicate OS X treats my screen as about 100 dpi.
The monitor is 30" diagonal, 2560x1600. So, calculating the dpi:
Yep, that's because it's 960px in CSS pixels, which are at 96dpi. Your monitor also has it's own physical dpi so you can't just measure the length of a line on the screen to infer the OS's dpi.
> The way the CSS authors handled this problem (again, sensibly, IMO), was to allow the user agent (ie. the browser) to choose a useful precise size for the “px” unit and then size all the other units relative to that “px” unit.
So I'm a little confused about what you mean when you say, "Nope! "px" is defined by the CSS spec."
According to the article, it's defined as an integer number of pixels approximating 0.265mm (SI). So the size will vary but this is a long way from "whatever the device+OS combo wants it to be."
These are both correct. The CSS 2.1 spec actually defines a CSS pixel ("px") as "the whole number of device pixels that best approximates the reference pixel". It's to allow a little leeway for devices with low-resolution screens. On a high-resolution screen a CSS pixel should be = the reference pixel.
The whole point of HTML/CSS is that you don't get to design pixel-perfect layouts (use something like PDF for that). The device is free to reflow pages and layouts as it sees fit. If OSX users prefer to see web pages as smaller than windows users, why not just let them?
That's not the case here because we're talking about CSS pixels and not physical pixels. A CSS pixel is 0.75in and an inch on Windows is 96 physical pixels but on Mac OS it is only 72 physical pixels.
Accept that your site will only render correctly on devices with square pixels, and that {old TVs, mis-calibrated CRTs, fun-house mirrors} will not render your document correctly.
But pixels are not perfectly square, and not visible on >300 ppi devices? I think we should accept that you can't rely on pixels anymore, and it's a good thing, which will let us move on to better display technologies and better, vector, graphics. When you do that, and if you want, make vector squares, you can let the rendering layer 'snap to grid' for rendering your pseudo-pixels.
Vectors have to be rasterized at some point, which requires detailed knowledge of device pixels.
Furthermore, some graphics are always going to be bitmaps, such as photos. Tasks like "center this image square, but don't make it blurry" requires pixel-perfect positioning.
That's exactly my point. Only the mobile OS knows the detailed knowledge of device pixels, not a web developer. Raster graphics can utilize GPU accelerated filtering. Sharp graphics should be vector with blocky or any other kind of 'hinting' that you might want.
Given two displays with identical dimensions, where one has twice the DPI of the other, then a square specified to be "width: 400px" should be physically half the size on the higher-DPI screen.
Designers who want to render at a particular size (e.g. for buttons that a user will push) should specify sizes in physical dimensions, such as inches or cm.
What about the fact that we have dpi's going from 250 to 450, everywhere in between? We have color temperature problems, we have totally different screen aspects sizes. Between all the things we can't control, why is it still a good idea to render with pixel accuracy?
The rationale in the article was perfectly reasonable to me. A px should be a physical pixel or whatever integer multiple makes for comfortable viewing, with all the other measurements allowed to be non-integer. Anything sized in px would then be both sensibly sized and scaled with good fidelity.
HTML was never intended to let you draw with that level of precision. It should still do something more sensible than arbitrary scaling if every link in the chain implements things as intended.
