Re: [csswg-drafts] [css-borders] Add a 'hairline' border-width value (#3720)

Summarizing the proposal again:

* Add a 'hairline' keyword to 'border-width' (and possibly 'column-rule-width'/'row-rule-width', does it make sense anywhere else?)
* This is equivalent to a 1px size, but *paints* differently - for borders it paints a "hairline" (likely device-pixel aligned) along the outer edge of the border region, with the rest of the border region being transparent (showing the background-color underneath, as normal).  (Equivalent to `border-color: stripes(transparent 1fr, currentcolor 1devicepixel)` or so.) For column rules it paints a hairline in the center of the 1px region.

Benefit of this is that the layout size is predictable (always 1px). It also doesn't require any special handling in other properties to keep things aligned; hairlines are 1px wide. And if a user has low-vision needs, a UA could offer to paint `hairline` thicker (up to `1px`), without potentially triggering layout issues in the page.

Downside of this is that it can still look odd for background *images* (they don't paint under borders, so you'll see a <1px stripe of background-color around the image). It also doesn't actually make the element smaller, in case that matters.

There's also a question of what to do for collapsed table borders. Reading Tables 3 and looking at Blink's behavior (and assuming, probably wrongly, that they match), I think the right answer is that the hairline should be center-aligned in this case. This is pretty obviously the only right answer for border *between* cells, and it lines up with the sizing and positioning of cell backgrounds (in Blink, at least), which only extend halfway into the border area. It means the borders won't be on the outside of the table grid, possibly revealing background bleed there, but, uh, backgrounds on tables seem pretty messed up anyway from what i can see.

-------

The alternative behavior suggested is to rely on border-width rounding, which always rounds away from 0:

* encourage authors to simply write a "small" border-width value, like `border-width: .1px`
* define [border rounding](https://drafts.csswg.org/css-values/#snap-a-length-as-a-border-width) to clamp to the "hairline" width, rather than to device pixels 
* add a `border-round(<length>)` function that exposes this rounding behavior directly, so other properties can lean on it and get the same size.

Benefit of this is that you get "real" sizing of the border area, and don't have to worry about it being transparent in some areas and potentially showing something confusing thru. You can also align other things to that size, if needed.

Downside is that it's an unpredictable size, which we know from experience can trip authors up when they don't test on different devices, tho to be fair it's only *slightly* unpredictable (smaller than the historical "px vs pt" sliding differences that browsers had to abandon). It also relies on author *guessing* at a border size which is small enough to round up to hairline, but not *so* small that it gets truncated to zero (especially a concern since browsers seem to all use some notion of "layout units" for sizing borders/etc, which are fixpoint and can't be smaller than .01px or so). I think it would be safe for the spec to recommend .1px for this, but it's still a little fraught. We could also still just add a 'hairline' keyword to represent this size directly, so no guessing involved.

-------

@emilio, you had more of an opinion towards the "use border-width rounding" option. Is that still your preference? Do you have other reasons, not listed, to prefer it?

@smfr, you also seemed to lean towards using border-width rounding. Is that accurate?

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-2657270744 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 February 2025 17:21:19 UTC