[fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?

[smfr]

fill-stroke-3 says that stroke-width is relative to scaled viewport size without a normative reference for what that means in CSS.

Perhaps, if we want to use viewport size, it should use the same dimensions that are used for viewport units?

Alternatively, perhaps in CSS % in stroke-width should be relative to something else?

[fantasai]

Added note: smfr suggested making it relative to font-size (as we're doing in letter-spacing etc.) since that might actually be useful.

[tabatkins]

Note that "in CSS" isn't the discriminator here; SVG already defines what %s mean in CSS (and you can't use %s in the attributes anyway).

We could have a different definition for it in non-SVG elements, or we could just try and change the definition wholesale (since % sizing on stroke-width properties is probably rarely-used?).

[css-meeting-bot]

The CSS Working Group just discussed [fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?, and agreed to the following:

• RESOLVED: CSS stroke-width on text will resolve percentages against computed font-size

The full IRC log of that discussion

<Rossen_> Topic: [fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?
<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6116
<dlibby_> smfr: noticed that % stroke-width are relative to viewport, this seems unexpected that it would change when resize window
<dlibby_> smfr: i would expect it to map to line-height or something more local
<dlibby_> Rossen_: didn't we have something in the SVG spec that was disambiguating properties that derive from SVG viewport, what happens in CSS
<dlibby_> smfr: i don't recall
<miriam> q+
<dlibby_> heycam: transform-box has all the keywords and how they map in non-SVG contexts. we can probably use the same mapping
<dlibby_> Rossen_: in most cases resolving to containing box
<dlibby_> heycam: that's right
<dlibby_> Rossen_: may or may not be expected here
<fantasai> heycam, https://www.w3.org/TR/css-box-3/#keywords ?
<dlibby_> smfr: context: filed when noticing some odd webkit code, not high priority
<heycam> fantasai: that's it
<dlibby_> Rossen_: I'd like to align behaviors that is coming from SVG, and how to map the concepts when they come to CSS
<heycam> so 'border-box' according to that definition
<dlibby_> Rossen_: continue to use the escape hatch for weirdness in the future
<Rossen_> ack miriam
<dlibby_> miriam: consistent translation from SVG makes sense. i associated with text-decoration-thickness which resolves against em
<dlibby_> fantasai: there's not a good reason for text stroke width to reference contaning box, but resolving against font metrics makes sense, and we should do what is useful if there are no webcompat concerns
<Rossen_> ack fantasai
<dlibby_> fantasai: re: diverging from SVG behavior, would be beneficial for conceptual clarity rather than trying to stay consistent in an unclear manner
<dlibby_> fantasai: not sure if %'s on stroke-width on text in SVG is common, maybe we can switch SVG as well?
<heycam> q+
<dlibby_> fantasai: more compat concerns but can't imagine that authors were intentionally using is as it is currently spec'd
<dlibby_> Rossen_: worth getting data
<dlibby_> fantasai: agreed for SVG, we should probably just do it for CSS
<dlibby_> heycam: you can use stroke-width on non-text
<Rossen_> ack heycam
<dlibby_> heycam: hopefully we can do it across SVG
<dlibby_> fantasai: might be more risk, not sure we can change all the behavior
<dlibby_> fantasai: we should have percentages resolve against 'em' since it provides a pixel value
<fantasai> s/'em' since it provides a pixel value/'font-size', and inherit as a percentage, as it does for text decoration/
<dlibby_> Rossen_: proposed resolution - for CSS stroke-width on text will resolve percentages against 'em' size
<fantasai> s/em/computed font-size/
<dlibby_> RESOLVED: CSS stroke-width on text will resolve percentages against 'em' size

[fantasai]

We also decided to investigate whether this can be extended to SVG. Marking Needs Data for that.

[emilio]

https://bugzilla.mozilla.org/show_bug.cgi?id=1703987