Re: [csswg-drafts] 'line-height: normal' definition should reflect reality of determining based on fonts (#1254)

The CSS Working Group just discussed `line-height: normal' definition should reflect reality of determining based on fonts`, and agreed to the following:

* `RESOLVED: publish updated working draft of CSS-Inline`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: line-height: normal' definition should reflect reality of determining based on fonts<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/1254<br>
&lt;dauwhe> fantasai: lots of talk about what line-height: normal does<br>
&lt;dauwhe> ... I went through the minutes, and incorporated into the spec<br>
&lt;dauwhe> ... one question: how fonts own line gap metrics are handled<br>
&lt;dauwhe> ... when they are there, we split the gap so half above and half below<br>
&lt;dauwhe> ... I think it only affects the height of the line box<br>
&lt;florian> q+<br>
&lt;dauwhe> .... so I put that in the spec<br>
&lt;dauwhe> ... I wanted to confirm that with the WG<br>
&lt;dauwhe> ... that what is now in the spec is acceptable<br>
&lt;dauwhe> myles: is this a question of researching of what browsers do? Make fonts with varying line gaps and see what happens?<br>
&lt;dauwhe> florian: at least start with finding what it is<br>
&lt;dauwhe> dbaron: my memory is that gecko's choice of whether to use the line gap metric is complex<br>
&lt;dauwhe> florian: I agree that line gap does not affect height of content box<br>
&lt;dauwhe> ... I didn't test vertical align<br>
&lt;florian> q-<br>
&lt;dauwhe> myles: rather than asking us to remember what our browsers do, better to test the browsers?<br>
&lt;dauwhe> ... I'm happy to make a bunch of fonts to help<br>
&lt;dbaron> s/complex/complex, and that what it affects is what number line-height: normal means/<br>
&lt;dauwhe> florian: we can split it up. we'll make fonts and test<br>
&lt;dauwhe> Rossen_: how shall we resolve? try to match reality of current implementations?<br>
&lt;dauwhe> fantasai: we can leave the issue open until we have definitive test results<br>
&lt;dauwhe> ... I'll make sure that what dbaron said is allowed<br>
&lt;dauwhe> ... the rest is already in the spec<br>
&lt;dauwhe> ... if people want to review, that would be great<br>
&lt;dauwhe> ... and I'll ask if I should publish a new WD?<br>
&lt;myles> q+ to talk about 90 minute meetings<br>
&lt;dauwhe> Rossen_: a new WD would include edits with today's resolutions?<br>
&lt;dbaron> I don't think I mentioned using the line gap metric of a different font...<br>
&lt;dauwhe> fantasai: yes, I'll make those edits before I publish<br>
&lt;dauwhe> Rossen_: any thoughts?<br>
&lt;dauwhe> q?<br>
&lt;dauwhe> Rossen_: hearing no pushback<br>
&lt;dauwhe> RESOLVED: publish updated working draft of CSS-Inline<br>
&lt;dauwhe> myles: 90 minutes is too long for m<br>
&lt;dauwhe> ...e<br>
&lt;dauwhe> ... we made good progress<br>
&lt;dauwhe> ... don't we usually just let the agenda overflow<br>
&lt;dauwhe> ... I'd rather have lots of topics for the future<br>
&lt;dauwhe> fantasai: I had things lined up this week, which was why<br>
&lt;fantasai> s/things lined up/deadlines/<br>
&lt;dauwhe> Rossen_: most people had similar sentiments, Myles<br>
&lt;dauwhe> ... maybe we don't repeat this, unless at F2F<br>
&lt;dauwhe> ... there's a thread on Private ML about upcoming F2F planning<br>
&lt;dauwhe> ... thanks everyone<br>
&lt;fantasai> I also figured that the line sizing topic would take awhile and wanted to make sure we had the time to dig into it rather than skimming over it over the course a few calls<br>
&lt;dauwhe> I think this helped<br>
</details>


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

Received on Wednesday, 17 June 2020 17:34:41 UTC