One inch is not an inch
As a side note, currently browser/device/OS manufacturers can set their actual ideal viewport dimensions (in CSS pixels) to whatever they deem best in light of not only the physical screen size, but also their (estimated) viewing distance. If we now had a requirement that an inch actually be a physical inch, we’d immediately have an issue with things being designed specifically with a particular viewing distance in mind (think for instance a design which is designed for mobile, but is then displayed on a web-capable TV…where a 1"x1" control may be perfect on mobile, it’ll be ridiculously tiny on a 42" TV at the idealised 10’ viewing distance that’s normally bandied around). So, while it would open one door (being able to accurately design something in real-world sizes), it would immediately create new problems for responsive design that needs to work across different device classes (and no, i hope we’re not now moving to “we just need device-specific media query features”…)
(partly related, my musings on TV and ideal viewport, from aeons ago http://patrickhlauke.github.io/web-tv/ideal-viewport/)
I disagree. This is why we need to have access to pixel density and the screen size of the display so that we can make informed decisions. For example, if my app knows that the screen size is 30 inches by 40 inches and the pixel density is X, then my app would know it is running on a huge display, and it will adapt accordingly. My app therefore wouldn’t display a tiny 1-inch thing, but instead something bigger.
For those of us that wouldn’t want to take advantage of that luxury (you for example), the spec would need for browsers to behave as they do currently do by default. The only difference would be that someone like me (who does want this) would have the option to take advantage of such information.
In the current state of affairs, “1 inch” not being an inch is just plain wrong, IMHO.
Browsers would by default continue to behave like they currently do. This new feature I’m imagining would be opt-in, so that if people want to take advantage of it they can.
The “new problems” that you mention would only be there for people who opt-in, and I would be one of those people dealing with those new problems, but by default, you certainly wouldn’t have to.
Cheers and happy new year! :}
would only be there for people who opt-in
and those who just cargo-cult/copy paste from other projects without understanding the potential implications of this foot-gun
and I would be one of those people dealing with those new problems
as there’s no solution to it though (unless you make separate sites for mobile, desktop, TV and do browser/UA sniffing to try and redirect people to the correct one), it still sounds dangerous to me to add this particular component while the ways to deal with it correctly in different scenarios aren’t available.
That applies for anything in any programming language, so isn’t a good argument against this feature. It’s not the best idea to just paste anything all the time without knowing what it does.
As I mentioned, the default behavior would be the current behavior, and there’d need to be a way to opt-in. I personally don’t care if people who go pasting things blindly accidentally opt themselves in. That’s what they get for pasting blindly.
Idea: What about a set of new units like rin, rcm, etc, where the letter r prefixed in front of them stand for “real”, so “real inch”, “real centimeter”, etc. Those units would be real when the hardware supports, otherwise they fall back to current behavior. Simple!
After having that unit, it’d become possible to do all sorts of things like make an invisible box of 1x1 rin, calculate it’s pixel size, and then use that info to get screen density, etc. It would then be possible to pass numerical pixel values to other JavaScript libraries (for example canvas 2d or webgl drawing libraries) that work in pixels (assuming the pixel ratio of the canvas to the document is 1).
Please don’t use other threads to continue to push for your “get the hardware pixel density” proposal.
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?
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
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.
@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?
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.
“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.
Mobile Safari could do this easily since it’s run on so few different devices. It’s kind of telling that it doesn’t.
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.
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).
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).
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?