[css-border][css-viewport] Consider moving border-width pixel snapping from computed value to used value

[weinig]

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

1. Apply zoom
2. 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.

[Loirooriol]

Does this mean that pinch zoom would need to re-do layout?

[weinig]

Does this mean that pinch zoom would need to re-do layout?

I don't think this would have any effect on pinch zoom.

[astearns]

Given the resolution here, add outline-offset to the set of properties to consider.

[sb3nder]

Just wanted to say that in Chrome and Firefox, the computed value is circa something like:
snap(3px) = snap_dvpx(3px * effectiveZoom) / effectiveZoom, where effectiveZoom = displayPixelRatio * totalZoom,
and the used value is snap_dvpx(3px * effectiveZoom).
(snap_dvpx is basically floor in most cases.)
Demo: https://codepen.io/sb3nder/pen/zxoZYvx

[tabatkins]

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?