Exposing hardware pixel density and other screen metrics via window.screen

Hello everyone,

It’d be great to have screen metrics that include the hardware pixel densities of the screen (average, horizontal, and vertical), along with the ability to explicitly use native hardware pixels instead of “CSS pixels”.

Please take a look at my proposed community group on w3c, The Hardware Pixel Community Group:

http://www.w3.org/community/blog/2014/12/05/proposed-group-the-hardware-pixel-community-group/

Please share any thoughts or ideas about this. Thanks!

Explicitly working on hardware pixels is hard, and it should be hard (though, I agree, it should not be impossible). There are, like, maybe two types of application that legitimately need to address screen pixels, and these types of application should be forced to implement some kind of abstraction inverter to calculate how to do that given only a slight amount of information.

The web should be future-proof, and that’s what resolution independence is for. By making CSS pixels resolution-independent, every site that declared a size in pixels is getting resolution independence for free. If addressing hardware pixels were made easy, we’d just end up in the same mess as we did when everybody assumed a pixel to mean 1/96 of an inch: UIs that are short-sightedly designed for a class of screen that will go obsolete in 5 years, leaving the entire UI broken and miniscule.

If you want to propose something for CSSOM View, I suggest sending an email to www-style with [cssom-view] in the subject line or filing a bug in W3C bugzilla. No need to create a community group.

The only use case I can find is “For example, suppose I want to make a push menu that is always 1 physical inch wide.”. But you have not explained why you want to do that. Please elaborate on this.

Apps that want to flash stuck pixels can benefit from addressing actual screen pixels. This is essentially the only legitimate use for direct-pixel addressing I know of.

True. That is why I think the default should be that it behaves like it does now, but that advanced developers can tap into the details and take advantage of it.

I’m needing this info so that I can develop more device-independently than the current CSS standards allow, so I’d be a user who would benefit from this and not shoot himself in the foot like what you described.

I legitimately believe that if I had ultimate control of pixels in DOM (we already do in WebGL), along with knowing hardware pixel density, that I’d be able to make amazingly device-independent things.

For example, with a CSS pixel to hardware pixel ratio of 1, along with knowing pixel density, I’d know the exact size of the screen in the real world, the world that the user lives in. Then I could decide how big things to be on screen. For example, if I detect a device that’s like 2.5" by 4.5" or something, I can appropriately fit a sliding menu on the side that is 2" wide, and be confident that it will look the same on all devices where that menu fits (and by “look the same” I mean "be the same exact real-world dimensions in the real world of each user (we all exist in one real world, and the UI would exist in that real world too, not scaled behind some virtual glass)).

Because I want complete control of how my app looks and feels. That’s something simple that I can already do in “native” frameworks. Why not in the web?

Addressing actual screen pixels is only half the problem, which we can already do in browsers. The missing part is we need to know the hardware pixel density to do anything meaningful with the pixels (for example, making something exactly 2 real-world inches wide no matter what device it is rendered on).

If you need two real-world inches, use 2in. That’s what it’s there for. You’re not going to get any more accurate size from the reported device hardware pixel density.

Remember: all CSS units, including px, are defined in terms of real-world units in the first place. Hence what I said above about device-pixel-addressing not being a meaningful addition.

Of course, browsers are allowed/required to make the in unit (and all the other physicals) slightly deviate from true, either for perf/rendering reasons (ensuring that the CSS px unit, which is 1/96th of the in unit, lines up with hardware pixel boundaries) or due to lack of information (no way to know how big a projector will project to; monitors often give incomplete or incorrect sizing information; etc).

But yeah, other than that, 2in is as close to 2 inches as you’ll be able to get on the machine. The sole use-case that’s ever been presented for needing something more exact is to render a ruler on the screen, and that’s sufficiently small that we don’t consider it to counterbalance the other issues.

And yeah, due to the factors @tabatkins mentioned, if rendering real-world sizes is truly important to your use case, your best bet is to have the user calibrate your display scale by holding an object of known size (eg. a credit card) directly up to the display and having the user make adjustments until it is exactly covered.

My usecases for exposing physical pixels in CSS:

decided to move to a new thread as related to CSS rather than JS.

From experience, rending a DIV that has width and height of CSS 2in doesn’t actually render at that size. It varies across devices, which to me, indicates that browsers haven’t taken proper care to use EDID properly (because I can do it manually in native frameworks and get the expected results, so I know that it can be done).

Those are valid points, but in most cases, the device has a hardware display (f.e. most phones, and most of them (at least the quality ones) have EDID). When a phone has EDID and a physical display, it should simply be easy to use such info. I don’t really see why it should be hidden from web app authors.

That’s a completely valid use case, and should be easily doable. Why not? It’s easy to do if you know the code paths in the browser, so why not just add it? I like native frameworks, like Qt, because in those frameworks I can make things render exactly how I want when I want (if the information is available).

Why not let the web be as powerful?

That’s one way, but unnecessary if the display has proper EDID info. This method you describe can be used as a double-check. “Hey, user, double check these dimensions are correct” and then they wont have to make adjustments if the EDID info is already accurate.

Why not just include the info, and let web developers have more power, while defaulting to the defaults we have now for those developers that don’t care?

I’d like to add that with false pixels (i.e. CSS pixels) we lose the power to position things precisely (like we can in “native”). For example, left:1px positions something at 2 actual pixels if the devicePixelRatio is 2. That limits our precision. As an alternative, we can position things with CSS translation, which accepts floating point values, but we cannot have a 1-hardware-pixel wide border, etc, with devicePixelRatio as 2.

Another downside to the non-real units/pixels is that events like touchmove, mousemove, etc, are limited to a lower resolution grid when the devicePixelRatio is greater than one. Movement events will fire only after passing over two hardware pixels if devicePixelRatio is two. Animations could be twice as precise (smoother, better, less janky) with events based on hardware pixels, when it comes to dragging/moving.

isn’t this a completely separate issue (about allowing fractional / floating point values in CSS)?

and for events like touchmove etc, note that some browsers already do return fractional values (Chrome for certain, there’s movement on doing that in Webkit https://bugs.webkit.org/show_bug.cgi?id=133180 … others, not checked)

Could be! fractional values would help if they fire on at least the 0.5 of a pixel. I’m not sure if it’s a separate issue, but I know that overall these things combine together and would allow some precision like what we’ve always had in native.