- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Apr 2021 23:08:03 +0000
- To: public-css-archive@w3.org
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 'em' size` <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: [fill-stroke-3] Should % stroke widths be relative to the viewport for CSS?<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6116<br> <dlibby_> smfr: noticed that % stroke-width are relative to viewport, this seems unexpected that it would change when resize window<br> <dlibby_> smfr: i would expect it to map to line-height or something more local<br> <dlibby_> Rossen_: didn't we have something in the SVG spec that was disambiguating properties that derive from SVG viewport, what happens in CSS<br> <dlibby_> smfr: i don't recall<br> <miriam> q+<br> <dlibby_> heycam: transform-box has all the keywords and how they map in non-SVG contexts. we can probably use the same mapping<br> <dlibby_> Rossen_: in most cases resolving to containing box<br> <dlibby_> heycam: that's right<br> <dlibby_> Rossen_: may or may not be expected here<br> <fantasai> heycam, https://www.w3.org/TR/css-box-3/#keywords ?<br> <dlibby_> smfr: context: filed when noticing some odd webkit code, not high priority<br> <heycam> fantasai: that's it<br> <dlibby_> Rossen_: I'd like to align behaviors that is coming from SVG, and how to map the concepts when they come to CSS<br> <heycam> so 'border-box' according to that definition<br> <dlibby_> Rossen_: continue to use the escape hatch for weirdness in the future<br> <Rossen_> ack miriam<br> <dlibby_> miriam: consistent translation from SVG makes sense. i associated with text-decoration-thickness which resolves against em<br> <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<br> <Rossen_> ack fantasai<br> <dlibby_> fantasai: re: diverging from SVG behavior, would be beneficial for conceptual clarity rather than trying to stay consistent in an unclear manner<br> <dlibby_> fantasai: not sure if %'s on stroke-width on text in SVG is common, maybe we can switch SVG as well?<br> <heycam> q+<br> <dlibby_> fantasai: more compat concerns but can't imagine that authors were intentionally using is as it is currently spec'd<br> <dlibby_> Rossen_: worth getting data<br> <dlibby_> fantasai: agreed for SVG, we should probably just do it for CSS<br> <dlibby_> heycam: you can use stroke-width on non-text<br> <Rossen_> ack heycam<br> <dlibby_> heycam: hopefully we can do it across SVG<br> <dlibby_> fantasai: might be more risk, not sure we can change all the behavior<br> <dlibby_> fantasai: we should have percentages resolve against 'em' since it provides a pixel value<br> <fantasai> s/'em' since it provides a pixel value/'font-size', and inherit as a percentage, as it does for text decoration/<br> <dlibby_> Rossen_: proposed resolution - for CSS stroke-width on text will resolve percentages against 'em' size<br> <fantasai> s/em/computed font-size/<br> <dlibby_> RESOLVED: CSS stroke-width on text will resolve percentages against 'em' size<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6116#issuecomment-816291036 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 April 2021 23:08:05 UTC