One inch is not an inch


#21

Instead of having us calculate real pixel density or physical screen dimensions based on a hidden DOM element, we could also be given some simple global to look at, containing float values:

window.screen.pixelDensity // in dots per inch? Different windows could have different densities depending on which display they are placed on.
window.screen.verticalPixelDensity // yes, the vertical density
window.screen.horizontalPixelDensity // could be different from the horizontal density.

The value of window.devicePixelRatio could also be configurable, using the viewport <meta> tag in the <head>.

// somewhere in the head
<meta viewport="name" content="device-pixel-ratio=1"/>

This would happen in the meta tag in the head so that it applies before rendering takes place. Now the content of the window would be rendered using the pixels of the device (in most cases, this matches one-to-one with the actual pixels of the device).

Additionally, there may be situation when a device pixel ratio of 1 doesn’t necessarily mean that the content is actually rendered one-to-one with the hardware pixels. It would be important to let these cases be more important, so that for example someone who tweaks defaults and wants everything scaled bigger or smaller on purpose won’t be disappointed. There should be a way to detect if this is the case or not, for example

if (window.devicePixelRatio == 1 && window.screen.matchesHardware) {
  // We know we have one-to-one drawing abilities with the display pixels.
}
else {
  // We know we don't.
  // Perhaps in this case there are other properties exposed like `permanentRatio` that can be used to handle certain cases.
  // Many developers will probably not have code here, but some of us would love to.
}

Alternatively, perhaps the spec could require window.devicePixelRatio to always be correct, even if the user zooms, or has some other OS-dependeny scaling, etc. This is totally possible to implement.

Those are just ideas, and would probably need to be refined, but essentially, I think have that control would be great. I can do it in native frameworks (Qt for example).

So, why not in the web?


#22

I’d like to add that in Mozilla’s document describing the <meta> tag, in the section called A Pixel is not a Pixel, they mention themselves that

Peter-Paul Koch wrote about this problem in A pixel is not a pixel.

Acknowledging in general that this whole thing with pixels not being pixels… is a problem!


Media feature for viewing distance
#23

This is about CSS physical units not always perfectly corresponding to the real physical units. It has nothing to do with physical pixels, and getting access to physical pixels will not help any use-case presented here in any way.

Seriously, stop.


#24

@tabatkins I don’t feel I’m doing anything wrong by expressing the features that I’d like to have and/or opinions about those wanted features. Your attitude is not appreciated.

Since you’re a moderator, I’d expect you to be one of the last people here to have such an attitude, especially if you wish to welcome new discussion and ideas to the forum in general.

You don’t like the idea, but that’s not reason to tell me “Seriously, stop”. What do these forums exist for then?


#25

Tab, haven’t you confused these (supposed to be) community-driven forums with a W3C mailing list? Have you read WICG best practices?

Substantively, physical inch is univocally related to physical pixel through physical PPI (pixels per inch) resolution.


#26

“Hardward pixels” is unrelated to the OP. Threads exist for a reason, to segment topics. You’re right that I don’t like that particular idea, but that’s not why I’m objecting, it’s because it’s off-topic - in your first reply you attempt to shift the topic to pixel density, with a scenario that has nothing to do with the discrepancy between 1in and 1 inch; in a later reply you’re more explicit about proposing some API for pixel density, with the original topic nowhere to be seen.

If you’d like to continue discussing hardware pixel density, you already started a thread on it; that’s an appropriate place to continue, or you can start a new thread if you feel like it’s sufficiently different to justify that. But please stop injecting this topic into unrelated threads.


#27

Mobile Safari could do this easily since it’s run on so few different devices. It’s kind of telling that it doesn’t.


#28

Aren’t CSS units officially defined in terms of fractions of the user’s expected view angle?

Anyway, as I put it a while back on Twitter, the nomenclature of CSS units is like the naming of the units in the US Imperial system: there’s about as much point in complaining about px or cm not being an actual pixel or centimeter on your screen as there is in complaining that the feet in your shoes are shorter than twelve inches.


#29

There is nothing wrong with current px not being equal to physical pixels. There should just be a way to use physical pixels when needed — be it with a CSS property that changes meaning of the px unit for specific element or a separate dedicated unit like dvpx (DeVice PiXel) or rpx (Real PiXel).


#30
document.documentElement.style.transform = 'scale(' + (1/devicePixelRatio) + ')'

#31

That’s a dirty pure-script (i. e. unavailable in CSS) workaround that is not even enough under Android that has an extra pinch-zoom factor that we are forced to unreliably calculate with something like window.outerWidth / window.innerWidth (fwiw, like in my SmartUpscale extension for Firefox that needs to deal with physical pixels according to its very purpose).


#32

There are workarounds to using native pixels (which I can live with), but there is not any workaround to using actual physical units (inches, centimeters) because there’s currently no way to get the device’s physical dimensions.

“Native” programs all have this luxury, and it would be simple to add to the web!

Maybe we just needs to PR a spec change?