[css-ui] Proposal: change `outline-offset` initial value to `auto`

[sb3nder]

Problem

When outline-style: auto is used in combination with outline-offset,
Chrome currently subtracts around 1px from the used value of outline-offset to help keep focus outlines visible in overflow scenarios not handled by authors.

Unfortunately, when the author wants to handle the offset themselves, this makes outline-offset very hard to use in a predictable way in Chrome and in an interoperable way across browsers.

In other UAs, outline-offset currently behaves normally with outline-style: auto, but I don’t think this interaction is clearly specified, so I’m not sure there is a guarantee that this behavior would not change in the future, for example due to UA stylistic or accessibility changes.

---

Maybe changing the initial value of outline-offset to auto could give UAs enough flexibility to choose their own default offset, while making numeric values specified by authors behave normally.

[sb3nder]

Some follow-up questions:

• Does the change make sense?

• How web-compatible would it be, given current UA differences?

• In WebKit, the offset can be controlled via outline-width, is that behavior here to stay?

  

  • Is it intended that the width does not scale with zoom?

    

  • Can the width be adjusted via system settings?

Any thoughts or guidance would be appreciated.

[sb3nder]

Update regarding WebKit (as of today, build 310633@main):
for outline-style: auto:

• outline-width is no longer taken into consideration.
• outline-offset: 0px has an effective offset of 0px, and any other value also reflects the effective offset.
• The rendered width should scale with zoom (I don't see this fixed in my build, but I guess it's fixed in Safari).

Fix outline: auto in user agent style sheets WebKit#1740
Enable zooming outline: auto WebKit#61077
Ignore outline-width when outline-style is auto WebKit#61497

Super happy with these changes.

[sb3nder]

Additionally, WebKit is proposing outline-offset: inset #13765, but I'm still unsure if it's the right approach as currently proposed.

[sb3nder]

I gave a look at Chrome code... it's effective offset is basically:
(All lengths are in device pixels)

// specifiedSnappedOffset = ...
// minBorderWidth = ...
// effectiveZoom = devicePixelRatio * totalZoom;

let offset = specifiedSnappedOffset;

const maxInsideBorderWidth = Math.max(Math.floor(1 * effectiveZoom), 1);
if (minBorderWidth >= maxInsideBorderWidth)
	offset -= maxInsideBorderWidth;

const halfInnerStrokeWidth = Math.max(Math.floor(3 * effectiveZoom), 3) / 3;
// const innerStrokeWidth = halfInnerStrokeWidth * 2;
offset -= halfInnerStrokeWidth;

// InnerStrokeWidth is not always an integer. If effectiveZoom is between N + 0.3333... and N + 1
// then Chrome renders blurry outlines for these values.

// this offset includes the blurry part
flooredOffset = Math.floor(offset);