-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-values] Proposal for add a device pixel unit #3715
Comments
What would such a unit compute to in a Also, just for background, Gecko used to support physical units ( |
@emilio thank you for your information. Just as the MDN's explanation said:
In my opinion, |
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.
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. |
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 |
@tabatkins thanks for reply.
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 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: 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.
Yes, I know the context for introducing |
@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. |
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. |
Well, 0.5 css pixel is a good choice. Expecting all the mobile browsers support it as soon as possible. |
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, PS: |
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 |
@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.
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. |
If you know how large the device pixel is, relative to your normal measurement units of 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. ^_^ |
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
I suggest add a new CSS unit for this case, the unit name could be one of this following candidates:
Thanks.
The text was updated successfully, but these errors were encountered: