Re: [csswg-drafts] [css-inline-3] handling the line gap metric (#8068)

The CSS Working Group just discussed `[css-inline-3] handling the line gap metric`.

<details><summary>The full IRC log of that discussion</summary>
&lt;ntim> scribenick +ntim<br>
&lt;dbaron> Scribe+ ntim<br>
&lt;dbaron> ScribeNick: ntim<br>
&lt;dbaron> s/Scribe+ ntim//<br>
&lt;ntim> fantasai: there are inconsistencies with whether line-break: normal on whether it includes the line gap metric<br>
&lt;dbaron> s/break/height/<br>
&lt;ntim> fantasai: I don't know if we can get interop on it<br>
&lt;ntim> fantasai: but I'd like to get input from implementers<br>
&lt;ntim> fantasai: one thing we can do is to not include the metric except for the root line box<br>
&lt;ntim> myles: does any browser do that?<br>
&lt;ntim> fantasai: no I don't believe so<br>
&lt;ntim> fantasai: but it would reduce problems with the line shifting around<br>
&lt;ntim> dbaron: if the compat space is such that some browsers do it and some browsers don't, then fantasai's proposal seems reasonable if compatible<br>
&lt;ntim> myles: if my memory is correct, we include the gap metric on all line boxes when line height is normal<br>
&lt;dbaron> https://searchfox.org/mozilla-central/rev/b741ddde6c678ca7025858952202d20664491555/layout/generic/ReflowInput.cpp#2719-2734<br>
&lt;miriam> q?<br>
&lt;khush> q+<br>
&lt;miriam> ack khush<br>
&lt;ntim> khush: what other input goes into the font line gap metric?<br>
&lt;fantasai> s/into the font line gap metric/into normal line height besides font line gap metric, and is that consistent between browsers/<br>
&lt;ntim> fantasai: different browsers use different metrics, browsers have different ascent/descent metrics that are not entirely consistent<br>
&lt;myles> q+<br>
&lt;dbaron> https://searchfox.org/mozilla-central/rev/b741ddde6c678ca7025858952202d20664491555/gfx/thebes/gfxFont.cpp<br>
&lt;fantasai> s/browsers have/fonts have/<br>
&lt;ntim> khush: is there any motivation?<br>
&lt;dbaron> s/motivation/motivation if it's still not going to make things interoperable/<br>
&lt;ntim> fantasai: yes because it makes it less bad<br>
&lt;miriam> ack myles<br>
&lt;ntim> myles: Yeah, I'll repeat:<br>
&lt;ntim> myles: I'm scared of changing the look of text on all of the web<br>
&lt;ntim> myles: it's somewhat important, that text on the web looks consistent with native text<br>
&lt;ntim> myles: it's not a deal breaker , but i want to bring up the concern<br>
&lt;nicole_> +1 to myles<br>
&lt;ntim> myles: to make progress, we need an implementer willing to try it<br>
&lt;ntim> myles: not willing to try it though<br>
&lt;astearns> nicole: I can ask, but I am skeptical<br>
&lt;ntim> dbaron: blink / gecko seems to both include the metric<br>
&lt;ntim> dbaron: what implementation doesn't?<br>
&lt;ntim> fantasai: I think one of them doesn't<br>
&lt;ntim> myles: what is the motivation?<br>
&lt;ntim> fantasai: the spec says you may or may not<br>
&lt;ntim> fantasai: if all the browsers do a single thing, we should be able to spec that<br>
&lt;ntim> myles: sounds like the next step is research<br>
&lt;miriam> ack dbaron<br>
&lt;ntim> astearns: a single WPT test and looking at results<br>
&lt;fantasai> s/one of them doesn't/when I was looking into it, one of them didn't; might no longer be true/<br>
&lt;ntim> astearns: could be a tentative test<br>
&lt;dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/style/computed_style.cc;l=2189;drc=31fb07c05718d671d96c227855bfe97af9e3fb20;bpv=1;bpt=1<br>
&lt;dbaron> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/fonts/simple_font_data.h;l=187;drc=31fb07c05718d671d96c227855bfe97af9e3fb20<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8068#issuecomment-1720998898 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 September 2023 09:53:04 UTC