That includes me. Making a pixel not be a pixel is surely one of the great pooch-screws of modern standards. 'pt' existed to be resolution-independent.
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)?
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.
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.
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.