Hacker News Reader

Comment by jmillikin | Hacker News Reader

This response is taking issue with the words used, rather than the underlying claim of the original article. In fact, this response contains a whole section and a diagram which are effectively supporting evidence for the original!

The most important thing to take away from the original is that the css unit "px" has no relationship to the actual size of a pixel on the screen, and all the physical units (inch, cm, pt) are defined in terms of the csspixel. So marking a button as "width: 1cm" will almost never render something over 1cm of the screen geometry.

Incidentally, this is why designers like device models with only a few geometries, such as the iPhone. They can do the math themselves to work out how many iphone-pixels are in a cm, and write their styles accordingly.

View on HN

Hi, I wrote this article (the response, not the original). though I didn't post it here - I just noticed the pingback email.

I am indeed responding mainly to the wording, and you'll see at the start and end of the article statements that I think the original author does at least kind of understand what is going on (though I don't think his understanding is very solid).

Your statement that 'the css unit "px" has no relationship to the actual size of a pixel on the screen' exemplifies why I am concerned about the wording and thought it necessary to write a response. This statement is just not true!

The CSS px unit was carefully designed to embody as closely as possible the intuitive concept of a "monitor pixel", while retaining sufficient flexibility to allow implementors to accommodate a wide range of devices. The whole concept of unit anchoring was invented to support this. To pretend the px unit has no relationship to actual pixels is to waste all of this work.(*)

I would suggest people aim for one of two levels of understanding:

1. Really understand the rules. Read the standard, and/or a proper CSS book like "Cascading Style Sheets: The Definitive Guide" by Eric Meyer. Be an expert and design with confidence.

2. Altenatively, just think of 1px as a monitor pixel. The standards authors put a lot of effort in to allow people to do so.

For people that are currently in state 2 and are uneasy about retina displays, printers and the rest, my advice would be that they are going to need to go to state 1. It's not that hard. Just getting a vague idea (as many people are) that "px" is angular, or worse that it's in some way "unreliable", is not going to help anyone.

[PS. Here's an ironic aside about the lengths people have gone to to make 1px correspond as closely as possible to a real pixel: As you say, 'marking a button as "width: 1cm" will almost never render something over 1cm of the screen geometry'. But why exactly is this? It's because the whole system of units has been anchored to the screen pixel size (or a simple multiple or fraction of it). On a printer, where there is no "pixel" worth anchoring to, the units are typically anchored to physical units, and width: 1cm really does mean 1cm. The reason that on your monitor screen 1cm is not 1 real cm is because your browser is resizing everything - it's bending over backwards to make 1px match the screen pixel size! (or a simple multiple or fraction yadda yadda yadda...)]

Can you give us a real world example of how this technical mis-understanding would affect my day-to-day design process? Specifically, I haven't ever encountered or designed for a screen yet that extends beyond my peripheral vision. I'm sure they are coming soon though!

It might not, TBH, but why carry around an incorrect technical notion that gives you no benefit, even if it doesn't cause you any problems in practice? Maybe my view on this is skewed by the fact that I'm a developer, not a designer...

That said, there are problems that could occur. The main reason to need pixel sizes for things (NOT fonts) is to avoid aliasing effects. For example, 1px is the smallest width you can reasonably make a border. Any smaller and on some devices you may find your border sometimes disappears entirely (aliasing) or is displayed faintly (antialiasing). Any larger and your border may be fatter than it needs to be. If you spurn px entirely (as some people appear to do) how are you going to get this magic length? By saying "0.265mm", perhaps? But that's just another way of saying "1px"!

>If you spurn px entirely (as some people appear to do) how are you going to get this magic length?

You use a high-resolution screen such that 1 pixel is too small to make a line, and on lines thick enough to be visible the effects of antialiasing are subtle enough to ignore.

This assumes that you get to choose the resolution of the screen, which is a luxury web designers don't generally have!

Well there's not really any other way to ensure crisp rendering. A user with a low resolution screen, even if 1px equates to an actual pixel on their device, might have web pages zoomed in by 15% or out by 10%, breaking all attempts to avoid antialiasing.

This happens when a developer and designer start talking about pixel sizes... ;)

I'm a developer, so: yes, zoom will break things. but the users (usually) notice this and (sometimes) know how to correct it.

Thank you for the wonderfully well-written and thoughtfully considered article. It was a pleasure to read!

  > The CSS px unit was carefully designed to embody as
  > closely as possible the intuitive concept of a "monitor
  > pixel", while retaining sufficient flexibility to allow
  > implementors to accommodate a wide range of devices.

The closest match to the concept of a "monitor pixel" is a unit which represents one pixel. In other words, an element styled as "width: 100px" would be 100px wide regardless of the size of each individual pixel.

The issue with declaring that one csspixel is a monitor pixel is that it's only true for a very narrow range of monitors. It's not true for my phone, or my tablet, or my laptop, or my desktop. There is not a single machine I own for which 1 css pixel is 1 monitor pixel, and that situation is unlikely to change unless I decide to start building my machines with ancient 96-DPI LCDs.

  > On a printer, where there is no "pixel" worth anchoring
  > to, the units are typically anchored to physical units,
  > and width: 1cm really does mean 1cm. The reason that on
  > your monitor screen 1cm is not 1 real cm is because
  > your browser is resizing everything - it's bending over
  > backwards to make 1px match the screen pixel size!

No, it's not. My browser is bending to make "width: 1px" match some arbitrary size defined in the CSS spec, which is nowhere near the size of a pixel on my machine.

The browser is entirely capable of rendering css pixels as screen pixels, obviously. It's also capable of rendering with real-world sizes, by querying the physical size of the display from the OS and dividing by the current display resolution. But it doesn't do any of those things, because someone on the CSS committee wrote the equivalent of "pi = 3".

HTML+CSS is designed to make things as device-independent as possible. If the definition of "width: 100px" were to be vastly different on different devices this goal would be unobtainable. As long as the definition of px is some integer multiple of device pixels I think it's a useful compromise. If you really need precision at the level of device pixels you should be writing a native app.

It's a useful compromise for the OS to make, but does not belong in CSS. If I'm running on a non-native resolution, I expect the image containers to scale on websites to fit the images, which they won't if the browser overrides my 1.4 pixel pixels.

Whatever did happen to screen pixels, anyway? Did non-native resolutions die with CRT screens? It's nice to have a unit for 0.27 mm-ish, but I'd really have more use for a pixel.

It doesn't seem like you've actually read the article in its entirety, then (I can't blame you, it was very long but also very well written).

The author addresses 1) the counter-argument 2) an explanation for the "angle" wording (the section with the diagrams) which did a much better job of explaining the purpose of the angle than the "px is a non-linear angular unit" article, and 3) a line-by-line reasoning for why that other article was confusing (or outright wrong).

All of these sections made more sense than the other article, and in fact established why the points made by the two articles are very different and why it would make no sense for the px unit to be either "angular" or "non-linear".

How many px is 180 degrees then? or even 75 degrees? Obviously it doesn't work because degrees aren't linear and px are linear. That's the point of the article - confusing angles and px is a very bad move that might appear to work until it doesn't.

What do you mean, degrees are not linear? I'm a mathematician, and I think they are inarguably linear, so I'm assuming we're using different definitions of "degrees" or of "linear".

Edit: By any chance, do you mean "the projection of an angle measured in degrees on a straight line measured in {cm/m/whatever} is not linear"?

That is exactly what he means. I guess it might have been explained better in the comment, but that's the whole point the article is making: that the "reference pixel" for a given display is calculated by taking a certain visual angle (based on a specified DPI/distance) and projecting it onto a perpendicular surface at the expected viewing distance.

If the reference pixel is the viewing angle then multi-pixel measurements don't map linearly to on-screen sizes unless the screen they're designed for is the concave face of a sphere centred on the user's eye

As I understand this article (and my long-past reading of the spec), the only thing in the spec that talks about visual angle is the part about defining the size of one reference pixel. That's a very small angle, and at those sizes angular size is essentially linear even when projected onto a flat screen.

Nothing that I've seen in the spec ever remotely suggests using angular measurements for more than one pixel at a time, let alone enough of them for 90 or 180 degrees of the visual field.

That's all completely true, but the article that this linked article is a response to didn't draw that same conclusion from the spec, and that's what started this whole mess

>and at those sizes angular size is essentially linear even when projected onto a flat screen.

But not quite, and summed over many pixels, it will result in a noticeable discrepancy (which is still of no practical consequence). I wonder how it would feel to use a computer that used head tracking to dynamically transform the screen's contents so that pixels were mapped to equal angular size (from the point between the user's eyes).

> The most important thing to take away from the original is that the css unit "px" has no relationship to the actual size of a pixel on the screen

Did you read this article?

Did you make it to this part?

    I’ll just finish by going through a few of the explicit
    claims made in that article and correcting them:

    [...]

    2. The first sentence: “The “px” unit in CSS doesn’t really
    have anything to do with screen pixels, despite the poorly
    chosen name.” – this is obviously complete nonsense. The
    standards authors went out of their way to give browser
    authors a way to match the “px” unit up to the real-world
    device pixel

> and all the physical units (inch, cm, pt) are defined in terms of the csspixel.

Not for print and other high-res devices (like a Retina display). Did you read this excerpt quoted from the CSS spec?

    For print media and similar high-resolution devices, the
    anchor unit should be one of the standard physical units
    (inches, centimeters, etc). For lower-resolution devices,
    and devices with unusual viewing distances, it is
    recommended instead that the anchor unit be the pixel unit.

The article also mentions that on some devices, the anchor unit is cm and not px. So on those devices setting something to 1cm should render the item at an actual cm in size.

Agreed. Everyone sees the term pixel and thinks it will match a device pixel. This isn't true. The CSS pixel is sized to take up a certain amount of the visual field due to that diagram with a reference screen, distance, and density. The person writing about angular stuff is dead on target explaining to people the difference.

The author of the linked article is just nit picking word choice and confusing the issue. No one was applying this past that to then come to the claim the pixel size changed at different degrees, which is the implication that the author of this article seems so upset about. Everyone knows the CSS pixel stays the same size across the entire screen, we don't need to discuss that. We certainly don't need enormous articles like this written to correct a problem no one had.

Although overall the spec is really the offender since they never should have called this a pixel.

> No one was applying this past that to then come to the claim the pixel size changed at different degrees, which is the implication that the author of this article seems so upset about. Everyone knows the CSS pixel stays the same size across the entire screen, we don't need to discuss that. We certainly don't need enormous articles like this written to correct a problem no one had.

Actually I think this article was (re?)posted in response to another article[1] that made the front page today[2] which did claim that pixels were angular measurements. So certainly some people have had that problem

To be honest, since this article is from January this year and the other is (seemingly) from 2009 I'm not sure why it's come up today, but that's the Internet for you!

[1]: http://inamidst.com/stuff/notes/csspx [2]: https://news.ycombinator.com/item?id=6668395

Reply on news.ycombinator.com