Hacker News Reader

Comment by gmjoe | Hacker News Reader

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.

View on HN

> Just accept that "px" is device-defined

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.

The px would look larger on a screen with the lower dpi

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.

No, you said: "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"

My point is that they would look larger on OS X (lower dpi == larger pixels)

>but OS X treats it as 72dpi

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:

    irb(main):010:0* ratio = 1600/2560.0
    => 0.625
    irb(main):011:0> width = 30.0/Math.sqrt(1 + ratio*ratio)
    => 25.4399491201526
    irb(main):012:0> dpi = 2560.0/width
    => 100.62913207527

One of these days, I'm going to get around to buying a new Retina MBP. Then, I'll try that exercise again.

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 article says,

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

To the best of my knowledge, on iOS, 1 CSS px has been 2 device pixels for a while. Might even be 4 device pixels on Retina devices.

Right, so a CSS pixel is equal to the reference pixel in size.

What would be wrong with that?

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?

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

Of course you do. How will you get pixel-correct rendering when the browser is reinterpreting the meaning of a pixel?

how do you get pixel correct rendering when you dont know the pixel aspect ratio?

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.

Then what about high-DPI devices? Should they just render it really tiny? Should your content look 25% the size on a retina MBP?

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?

Defining dimensions in inches, cm or points for screen use is a big bag of hurt that should be avoided at all costs.

> specify sizes in physical dimensions, such as inches or cm.

So a one inch square button on my two inch wide phone will also be one inch wide on my 10 foot projector?

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.

maybe it doesn't have to, but it does and does a poor job at it

Reply on news.ycombinator.com