[css-borders] Add a 'hairline' border-width value #3720
Comments
|
I think this is a good compromise to the issue, especially if there is spec text recommending that browsers consider accessibility when defining the "hairline" thickness. E.g., if I'm browsing the web with 400% zoom level, I probably don't want lines that are only one retina-screen-pixel thick! For the more general case of "snapping" lines to an even number of device pixels, the SVG |
|
Yes, the spec should definitely state that the hairline-ness should be taken at "normal" zoom levels; zooming in shouldn't keep them hairline! |
|
It seems like at some point these borders might become thinner than the user of this keyword expects. For example, when printing, or as devices get even-higher-resolution. Also... with Gecko's border rounding behavior (round down in device pixels, except round values between 0 and 1 device pixels up to 1) you can effectively do this today without facing that problem. For example, a border with width `0.25px' will be one device pixel, unless there are 8 or more device pixels per CSS pixel. I think there was some movement of other browsers towards that behavior, but I'm not sure if things have converged. |
|
@dbaron Did you miss this part (quoted below), or is your comment asserting that something about it would still be problematic?
Hm, interesting. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6749 tests this behavior. In Chrome, on my 1x desktop monitor, I get a 1px border for everything down to .05px; the .01px border disappears. That might be an internal rounding issue? There's an additional weirdness in Chrome, tho - despite the border displaying the same size in all of them, the internals of the box itself lays out as different heights, despite the only thing giving it a height being a It looks like Firefox correctly renders a 4px padding box on each of them, so I assume this is a Chrome bug in the timing of our border-width snapping vs other layout calculations. |
|
(Confirmed with @atotic, this is a Chrome bug that'll be fixed when they get around to rewriting the relevant chunk of our layout code into the new LayoutNG form.) |
|
I did miss that "Right now" part -- although I think the proposal needs to define that behavior today, for printing. |
|
When I don't want a keyline to effect geometry, I've used |
Right, sorry for not being clear, it is absolutely intended that the spec will explicitly say that UAs should choose an appropriate small width, and recommend that it probably be no smaller than 1/3 or 1/2 of a px. |
Hm, maybe. Tho at this point dbaron's statement about just relying on rounding behavior (and specifying that you must always round away from zero) is starting to sound really good. I had a chat with @bfgeek about this tho, and he has some reservations about it. He could elaborate on this more; I don't fully understand the problems he was alluding to. |
|
I do think the supporting for fractional order As on mobile Apps, Android can use For the web pages that is embed in mobile apps, I wish, one day, we can use |
The
|
There's nothing stopping you from using a fractional px value for border width in CSS — it's just not guaranteed to snap to an even number of device pixels, and will therefore look bad on a screen with a different resolution than you designed it for. If this is really important, however, you could use media queries to check for the screen resolution. The benefit of the keyword is that the browser would figure out the exact value required to get a crisp line. |
I think it should. If it was only a 1x screen, then use opacity to simulate the thinner line, like is typically done for antialiasing scaled images. So a 0.5px line is rendered with 1px at half the opacity of what it normally would be. On a 3x screen, it would use 2 device pixels, at 0.75 opacity. |
It actually is guaranteed to do that. CSS itself doesn't guarantee it, but all browsers snap borders to whole device pixels, precisely because they otherwise look bad. (And do some fancy rounding to make sure all borders of a given width round in the same direction.) |
|
@tabatkins I thought Chrome and Safari (and maybe others) snapped to the whole px, not to the device pixel smaller than 1px. Is that no longer true? |
|
At least for border widths, I mean. Things like centering might be on device pixel space. |
|
No, they definitely do device pixel snapping. Confirmed by looking at http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6749 on my high-dpi phone; the first box ( |
|
Hmm. You're right. But they all (except 1px as and 0px) seem to be rounded to the same value on my iPhone X. Looks like maybe 0.25px. Maybe we can standardize and improve this then? It seems better than 'hairline' to me. But maybe both are useful. |
|
On my retina desktop display (Mac), in Chrome for Mac, the 0.05px to 1px borders all look the same (1px), and the last 2 are rounded down to zero. |
@AmeliaBR Yes, I could. But when I viewed http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6749 on Chrome/Safari/Firefox/Opera Mini on my iPhone XS Max, as @bradkemper has pointed, all values that less than 1px are rounded to 0.25/0.3px (maybe 1 device pixel). Based on this, I think using media queries to check the screen resolution is also not useful. Because it seems |
|
It seems that different properties are snapped to device pixels by different rules. Can anybody shed some light on the general logic behind this, please? |
|
My two cents here, maybe we should instead have a That way, the layout doesn't become unstable when you zoom in, only the rendering can change. |
|
I'm personally mostly concerned about layout changing as you zoom, this could have unintended consequences. |
|
@FremyCompany zooming should still scale it, along with everything else. |
|
@bradkemper Wait, so when you zoom, the "hairline" stops being an hairline, did I get that right? Because for instance if you had specified 1hairline, landed on 1dpx, then zoom 1.5x then the new border size won't be a round number of pixels (1.5dpx in this case) and won't be an hairline. I guess that this is an option, but that doesn't sound great to me. My proposal would have been to have the border be 1px all the time (which might be 1.5dpx, whatever), but then draw only 1dpx/2dpx around the content at painting time, and stick to either 1dpx (or 2dpx etc...) as you zoom while continue to scale the 1px value normally. |
|
Yes, Tab replied to Amelia’s comment with this:
I take zooming to be like looking through a magnifying glass, where a hair (or hairline) looks bigger and thicker as a result. |
That’s no worse than zooming in 1.5x on 1px line when 1dpx = 1px (non-retina display), is it? |
Fair point. |
|
For what it's worth, the hairline concept will translate very easily when printing. A line width of 0 in PDF means "as thin as the output device can manage". When viewing the PDF on screen they're expected to remain as thin as possible regardless of zoom level. |
SebastianZ
changed the title
|
I think this can easily be done with fractional pixels in all browsers these days, right? If it's not specified, it should be. Probably what @dbaron dbaron said above plus a lower limit of 0.3 CSS pixels or whatever.
|
|
See https://drafts.csswg.org/css-values-4/#snap-a-length-as-a-border-width (#5210) 0.5px will result in 1 device pixel when the resolution is less than 4dppx, 2 device pixels between 4ddpx and 6dppx, etc. If you want 1 device pixel regardless of the resolution, you can go smaller like |
|
This sounds great as long as there's also a new unit called "hair" I can use to match size and/or positioning of hairline-bordered things. Something like this: .thing-with-border
{
width: 32px;
border: hairline solid magenta;
position: relative;
}
.thing-without-border
{
/* Match the width of thing-with-border */
width: calc(32px + 2hair);
}
.thing-inside-thing-with-border {
position: absolute;
/* Position just inside the border */
top: 1hair;
right: 1hair;
} |
|
So right now you can get In #10819 I presented a use-case that isn't quite covered by this, because I actually want to use it to something like a shadow. I think the solution proposed there (previously proposed independently in #5986, cc @Crissov) of just a single environment variable is a good compromise between not making this too easy to use, yet still providing reasonable value for when you do need this. Thoughts @tabatkins? |
|
Do we want to expose the resolution, or just expose the width of a hairline? Are there enough good uses for the resolution that we actually want it, versus just adding a |
|
Sorry, hit submit too early. I'm still loathe to expose resolution directly, because a hairline isn't necessarily 1 device pixel. In a hypothetical super-display with 100 device pixels per 1px length, a hairline definitely shouldn't be .01px. (And this also argues against just relying on border-width rounding away from zero to the nearest device pixel, in favor of a |
|
So how do you solve the problem of displaying borders larger than |
I think exposing the resolution is the least implementation complexity, and the most flexible, since it's property agnostic... E.g., I might want to use padding in order to reserve space for a box-shadow
Sure, though this behavior is unlikely to be changeable? It's fairly long-standing in some way or another... |
What should it be?
But it's not just a matter of knowing the resolution, in order to avoid blurriness authors would also need the ability to align things correctly with the device pixels? |
Something in the 0.3px to 0.5px range probably. Maybe a bit lower, but not a lot lower. 0.01px, on a device that has pixels small enough to do it accurately, would be too thin to be visible. |
|
Also, while the layout size of a hairline probably needs to be fixed to avoid weird unstable layouts, the painted line within that size should probably be rounded / snapped to an integer number of pixels, taking position into account, in order to avoid blurriness. Although, if the physical pixels are small enough, that may not even be necessary. |
Sure, we could allow hairlines there.
Sure, we could even make hairline just an absolute length unit, like
Yeah, not saying we should get rid of the behavior, just that we might not want to rely on it for the hairlining, for several reasons. (And we might want to clamp it to the actual hairline width, rather than "nearest device pixel", so future screens don't round up to a nearly-invisible width.)
Like Florian said, around half or a third of a px, probably. That's a question for designers and a11y folks - whatever the minimal visible width of a "hairline" that's appropriate. My point is that a "hairline border" is a meaningful concept that has no connection to device pixels, except insofar as the device pixels on many screens are currently approximately the right width for a hairline.
Right, rounding the width to device pixels is important for usability, so just exposing a resolution directly doesn't actually solve the problem, afaict.
Border snapping already handles that for us, luckily. |
This was my only concern as I was catching up on this discussion. Can we specify as part of the definition of Though that might cause counterintuitive results if we also allow for multiples of |
Do you mean that with 2dppx, a hairline border would be sized as 1px but then only 0.5px would be painted and the other 0.5px would be transparent? I don't think that authors will like getting these gaps when trying to line up elements correctly. |
|
I guess my question is, how do we ensure predictable layout if we don't define the space taken up by a hairline border? Suppose we don't do that, and an author using a 2dppx display writes: .container {
width: 500px;
}
.tile {
display: inline-block;
width: 99px;
height: 99px;
border: hairline solid black;
}
<div class="container">
<div class="tile"></div>
<div class="tile"></div>
<div class="tile"></div>
<div class="tile"></div>
<div class="tile"></div>
</div>On their 2dppx display, the border-box width of each tile is 100px, and the five tiles fit exactly within the container. But for a user on a 1dppx display, the border-box width of each tile is 101px, and the last tile wraps to a new line, thus breaking the intended layout. That seems worse to me than having small transparent gaps between the tiles on a high-res display. Or am I misunderstanding how these hairlines work? |
|
That'd be how they work, and what you're describing right now is how browsers behave if you |
|
Chatted with Kevin in person, and I appreciate their idea more fully now. The idea is that a hairline border is 1px wide, geometrically, but we paint it using smaller device pixels if possible (UA-defined). The device pixels are chosen to be an "inner" border, so the padding box remains the specified size and we can make the outer device pixels transparent. (Possibly we could offer a choice here, but we'd need to define what to paint on the inner device pixels if it's painted into the "outer" ones. Probably not needed; I'd definitely say avoid it until it's asked for with a good example.) This should definitely apply in the other border-like properties, like column-rule, but there we should define it as choosing a centered set of device pixels (as centered as possible, at least). The benefit of this is that the layout size of a hairline border is predictable across devices. We already know from the historical example of trying to allow the physical lengths to be true (with a varying ratio with
My argument that hairlines are only There's also probably a reasonable accessibility argument that UAs might want to offer the ability to force "thick" hairlines (maybe tied into other options that are about vision issues). So offering this ability at the low level of authors just supplying a tiny length makes that more difficult, but Kevin's idea makes it pretty trivial. Authors already should be allowing for the possibility of a 1px "hairline", given the continuing existence of 96dpi devices, but I give good odds on most authors assuming that hairlines are necessarily thinner than 1px because they look that way on all their devices. |
People regularly ask for the ability to size things in device pixels (#3715 is the latest). This is virtually always intended for the use-case of sizing borders, to create "hairline" borders or separators.
Since adding an actual device pixel unit is out of the question, we should still address this use-case directly, and add a
hairlinekeyword to 'border-width', representing "the thinnest width that the UA believes is recognizable, snapped to the nearest whole number of device pixels". Right now, that'll be 1 device pixel, but if screens get significantly higher-res, it'll probably resolve to whatever number of device pixels gives you a value between 1/3 and 1/2 of a CSS px.Why can't we add a device pixel unit, so you could just say
border-width: 1dp?Because device pixels are unpredictable in size. If you try to size anything bigger than a hairline with device pixels, the size will, today, vary by more than 300%, as there are devices that have 1dp==1px, and devices with 3dp=1px, and I think some devices are pushing higher than that. As display technology gets better, this gulf will continue to grow, as there will likely always be 1dp==1px devices in use.
We already know from past experience that authors can't generally handle units with an unpredictable "sliding scale" ratio; the CSS2 spec used to have
inandpxdecoupled, so thatinwas as close to an actual inch as the browser could get, andpxwas the nearest whole number of device pixels approximating the visual angle of a device pixel on a 96dpi monitor. However, so many authors used the physical units (pt/in/cm/mm) to size their pages while assuming 96px=1in that browsers implementing the spec got broken pages on devices whose in-px ratio was different. And that was a ratio that could differ whose min and max could differ by, at most, 50%! (Handling an unpredictable ratio is a fundamentally very difficult problem! We have better, less fragile layout tools to help with that these days, but it's still virtually guaranteed to result in problems if we expose this.)Plus, the notion of a "device pixel" is screen-specific; when printing, the analogue to "device pixel" is the "dot", the smallest drop of ink that can be placed at a particular location. Printers not only have much smaller dots than screens have pixels, and in a larger range (consumer printers can vary from 300dpi to more than 1000dpi), they also vary based on color; black-and-white dpi is often much higher than color dpi. Sizing anything based on "device pixels" will either be wildly unpredictable on printers, or else it'll be a "virtual device pixel" that doesn't correspond to anything physical anyway.
And all this isn't even getting into screens that simply more exotic than the "rectilinear grid of hardware pixels" design that this sort of feature assumes. Some screens layer their pixels in a non-square grid. Some have differently-sized pixels, layered in separate rectilinear grids. Some have different grids for each subpixel color. All in all, the notion of a "device pixel" as something you can naively size things in is already nonsensical for many output devices, and the situation is likely to only get worse as time goes on.
Why not a device-pixel rounding function?
In #3715 @florian and I talk about a function that rounds a length to the nearest number of device pixels, as a compromise that delivers many of the benefits of device-pixel sizing without as many of the downsides. On further consideration, I don't think we want this either.
For the case of hairline borders, a device-rounding function achieves basically the same thing as a 'hairline' value, just in a slightly more complicated way. Users have to know to write
border-width: dp-round(.5px)or what-have-you, rather thanborder-width: hairline;. The only theoretical benefit ofdp-round()overhairlineis that it lets you distinguish between whether you really want .33px or .5px, when that distinction might matter for visibility, but in practice that's a wash anyway, since a 3x screen will still probably choose .33px over .67px if you saydp-round(.5px), and a 2x screen will still use .5px if you saydp-round(.33px), and many devices will end up still choosing 1px anyway, so the theoretical gain in precision is lost in practice. In a theoretical future with super high-res screens, it might become relevant; we can revisit the question at that point. ^_^For any other case, rounding to the device pixel doesn't do anything meaningful unless you're also rounding the position. Otherwise it's possible that the box is exactly 200dp tall, but it's offset 150.2dp from the top of the screen, so it's still fuzzy. And unless we offer position-rounding as some sort of separate property switch, you have to instead use dp-round() on your ancestors, too, all the way up to the root. (And depending on how you're being laid out, that still might not be enough; flexbox alignment has no way to force a rounding on the gap between flex items, for example.)
So, dp-round() is overkill complexity for hairlines, and doesn't do anything useful for most non-hairline cases.
The text was updated successfully, but these errors were encountered: