I'm not a web designer. Can you explain to me why it's important to be able to position/size something to exactly N pixels, rather than to exactly kN pixels (where k is some integer decided by the browser implementor)?

The biggest reason is that most css properties ignore fractional px values—you can't draw a .5px border, for instance.

Which is absurd, because antialiasing exists for that very reason. I should be able to render a single-pixel-thick vertical line between two columns of display pixels, and get two columns of display pixels at 50% (apparent) brightness. Subpixel rendering would be even better.

This is only true in some UAs.

Gecko has supported fractional pixel values for years in general, though for borders in particular the width is clamped to integer _device_ (not CSS) pixels.

WebKit has been rounding them at parse time (even in cases when 1 CSS px is multiple device pixels) for a while, but they're about to fix that.

I believe that IE also supports subpixel layout. Not sure about Opera, offhand.

Images and <canvas> and <embed> use actual pixels. It's hard to make things look right when you don't have the same unit in CSS.

Maybe I'm misunderstanding, but I don't think this is correct; the browser should scale everything. See http://joubert.posterous.com/crisp-html-5-canvas-text-on-mob... for example.

If they had set 1 px = 1 pixel, almost all Web pages would be unreadably small. AFAIK, Web designers don't use pt.

And people would have quickly learned to not use "pixel" unless they really mean "pixel".

You never really mean pixel, so I guess you're arguing for the removal of the px unit completely. (bzbarsky explained this better: http://news.ycombinator.com/item?id=3697227 ) Then designers would start asking for a unit that is resolution-independent but always an integer multiple of pixels — essentially px under a different name. The px unit is really useful, but maybe it should have had a different name; it's too late to argue about it now.

On the rare occasions where I say "px" rather than some scalable unit, I really do mean pixel. For example, I might use px to specify the width of an element that needs to have exactly the same width as an img tag.

On devices where 1px != 1 device pixel, images should be scaled by the same proportion as the px unit. So, if you set an img to 150px wide, and a div below it to 150px wide, they will be the same width, even if 150px == 300 pixels. I'd be happy to learn of any browsers where that is not the case.

HTML is a text markup language, not a device interface language. CSS is a page layout language. HTML and CSS are designed for optimum user control as well as designer flexibility. You assume you're designing for one type of device. Designers before you have assumed 96dpi for web pages. The W3C realize these assumptions, realize that the user may want to use a different type of device, and thus define px in terms of DPI.

As others have mentioned, if a user prints a web page on a 1200dpi printer, your 960px fixed layout is 4/5ths of an inch wide. Your users would not be pleased. Under the device-centric interpretation of px, you'd have to provide a medium-specific style sheet for every possible type of output device. Designers would not be pleased.

Maybe you're trying to use HTML+CSS as a rendering target for a general purpose widget library like Gtk+. In that case, I can understand your frustration.