[css-values] Proposal for add a device pixel unit

[cncuckoo]

The primary use case for device pixel is the mobile Web, where it is a very common need to render the real 1px width borders on high density screens. Here, the real 1px width means the device pixel width.

So far, Safari has supported 0.5px for the purpose, but that is still far from enough, and can not implement more precise control in some cases ( device-pixel-ratio > 2). Various hacks have emerged, for example

• https://codepen.io/foolkai/pen/QEgzLm
• https://juejin.im/entry/584e427361ff4b006cd22c7c (Chinese)

I suggest add a new CSS unit for this case, the unit name could be one of this following candidates:

• dpx: device pixel
• ppx: physical pixel
• rpx: retina/real pixel

Thanks.

[emilio]

What would such a unit compute to in a display: none iframe?

Also, just for background, Gecko used to support physical units (mozmm), but I removed them because of longstanding lack of interest from other implementors.

[cncuckoo]

@emilio thank you for your information.

Just as the MDN's explanation said:

This is rarely actually what you want, but may be useful in particular for mobile devices.
(https://developer.mozilla.org/en-US/docs/Web/CSS/length#mozmm)

In my opinion, mozmm has been absolutely a meaningful and valuable experiment, it is regrettable for it to be removed. I want this issue could draw more people's attention.

[tabatkins]

where it is a very common need to render the real 1px width borders on high density screens.

Can you describe why you want to do this? A line that is one device pixel thick can be very thin, and screens vary in how thin that is; a number of high-end phones are now ~3x resolution.

This is rarely actually what you want, but may be useful in particular for mobile devices.

That quote is referring to using mozmm to size buttons and other tap targets in physical units, so you can size something as, say, 40mozmm and have a reasonable guarantee it's actually 40mm wide, which is an appropriate touch-target size. It's not about making hairline borders.

[frivoal]

Note that even if we had this, updating layout during pinch-zoom is not acceptable, so it wouldn't actually be "1 device pixel", but rather "1 device pixel at the default zoom level". Similarly, transforms are paint-time operations, so 1device pixel would also not be 1device pixel if inside of a css transform.

Also, what's it supposed to do on devices that don't have a very clear sense of physical pixels, such as when printing to PDF or paper?

If the use case is "a very thin line", it seems that 0.5px or something similar actually is a pretty good answer, that will cope well with very high or very low density screen, far away screens as well as close ones, and various non pixel based media. Maybe we could introduce (via calc()?) some function that rounds a length to a physical number of pixels, to try and do some kind of pixel snapping, but I'm unconvinced it would help all that much.

[cncuckoo]

@tabatkins thanks for reply.

Can you describe why you want to do this? A line that is one device pixel thick can be very thin, and screens vary in how thin that is; a number of high-end phones are now ~3x resolution.

One device pixel (in any device) is just the most precise unit that current CSS spec lack of. If We had have this unit, whether use it to show 2dpx or 3pdx to the user is totally up to the designers.

For an example, please see this app UI shot on a high density screen, where the first horizontal line comes from Native app, and others defined by CSS through one of the hacks I mentioned above:

• https://p1.ssl.qhimg.com/t01be0b9919d7a996ff.png

We can see, although using hack, the 1px CSS borders still wider than the Native one. But this has already what we can do best until now.

That quote is referring to using mozmm to size buttons and other tap targets in physical units, so you can size something as, say, 40mozmm and have a reasonable guarantee it's actually 40mm wide, which is an appropriate touch-target size. It's not about making hairline borders.

Yes, I know the context for introducing nozmm is to display same size block to fit human's fingers.

[cncuckoo]

@frivoal thanks for reply.

I do argee your comment, but maybe the "1 device pixel at the default zoom level" is just I want. Because the use case I am concerned is about the mobile Web pages that are embed in the WebView of the Native Apps. In that cases, users are usually could not zoom the page due to the 'user-scalable=no' has set in the viewport meta tag.

As of other respects you have mentioned, please let me to think them for a while.

[frivoal]

Right. At the same time, when writing the page we don't know if the device will have a 2x density, or 3x, 5x or whatever. At a certain point, a single device pixel will be too small to be visible. 0.5 css pixel will always be "thin but visible". 1dpx could be that too, or it could be too thin to be seen.

[cncuckoo]

Well, 0.5 css pixel is a good choice. Expecting all the mobile browsers support it as soon as possible.

[Crissov]

@frivoal:

Maybe we could introduce (via calc()?) some function that rounds a length to a physical number of pixels, to try and do some kind of pixel snapping

I have proposed such a function in #2513, but for it to work with device pixels, they would need a dedicated unit in the first place, dot or d as established by dpi and dpcm.

PS: pixel would work for me as well.

[tabatkins]

Well, 0.5 css pixel is a good choice.

If you're okay with .5px, you can just write .5px. That's not 1 device pixel, tho, which is Florian's point - 1 device pixel might be 1px, or .5px, or .33px (or, since most phones resolutions are actually not a clean multiple, something like .48px).

It's very rare for someone to actually want a device pixel; they typically just want "a hairline-thin line, but rounded to the nearest device pixel", so yeah, something like dp-round(.5px), as Florian suggests, would do the job without exposing the footgun of actual device pixels.

[cncuckoo]

@tabatkins sure, compared with pushing the puzzle in front of designers, leaving the browsers to figure out how many device pixels 0.5px should occupy is obviously a better dispose.

they typically just want "a hairline-thin line, but rounded to the nearest device pixel"

Yeah, you are right. But I am still wondering that given the native app code and mobile web have different metric on how many device pixels "a hairline-thin line" should be used, how to make the same width lines on both side is another problem. And in the case, maybe both sides all have the device pixel unit in hands could resolve this problem.

[tabatkins]

If you know how large the device pixel is, relative to your normal measurement units of px, then you can do useful, meaningful things with a unit that exactly represents a device pixel. So, JS (or native app code) can be trusted with that information.

You just can't meaningfully use it in raw CSS, because you don't know how big it will be; anything you size in it will look "correct" on one device, but then will look different on another.

Note that even rounding to an integer number of device pixels isn't actually often useful, as you need to also ensure that it's positioned in device pixels, so that it lines up with the grid properly. This happens automatically for borders, as they're magically snapped to the device pixel grid, but not for anything else.

---

I'm gonna go ahead and close this issue as rejected; there's many reasons not to add a device pixel unit. However, I've opened #3720 to track the addition of a 'hairline' keyword specifically for borders, as that's the only use-case I've been able to extract from this. ^_^