Repository navigation
[css-border][css-viewport] Consider moving border-width pixel snapping from computed value to used value #13350
Description
Currently, the computed value for border-width properties is defined to "absolute length, snapped as a border width".
This has an unfortunate interaction with the zoom property, where pixel snapping will not be preserved for most values of zoom (as zoom is applied after computed value).
If instead, we move the application of "snapped as a border width" to the used value, I believe this would be resolved.
I say I think, because I am not exactly sure when zoom gets applied, the spec says:
"the used value of a CSS property (including values inside of path() strings) is pre-multiplied (before any other steps in the used value stage) by the used value of zoom for the element".
The goal here would be for the order to be
- Apply
zoom - Apply "snapped as a border width".
The only other user visible change here would be when explicitly inheriting border-widths by a child with a different zoom value, as the non-pixel snapped value will now be inherited, which I think would be preferable anyway.
Activity
Loirooriol commentedon Jan 24, 2026
Does this mean that pinch zoom would need to re-do layout?
weinig commentedon Jan 24, 2026
I don't think this would have any effect on pinch zoom.
astearns commentedon Feb 25, 2026
Given the resolution here, add outline-offset to the set of properties to consider.
sb3nder commentedon May 18, 2026
Just wanted to say that in Chrome and Firefox, the computed value is circa something like:
snap(3px) = snap_dvpx(3px * effectiveZoom) / effectiveZoom, whereeffectiveZoom = displayPixelRatio * totalZoom,and the used value is
snap_dvpx(3px * effectiveZoom).(
snap_dvpxis basicallyfloorin most cases.)Demo: https://codepen.io/sb3nder/pen/zxoZYvx
tabatkins commentedon May 19, 2026
Is the use-case here solely based on the interactions with 'zoom'? Do we actually care enough about 'zoom' to change things around like this to accommodate it?