Re: [csswg-drafts] [css-inline-3] make `text` of `leading-trim` interoperable? (#3978)

The CSS Working Group just discussed ``make `text` of `leading-trim` interoperable?``.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: make `text` of `leading-trim` interoperable?<br>
&lt;fantasai> I think the issue was https://github.com/w3c/csswg-drafts/issues/674#issuecomment-333541595<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3978<br>
&lt;dael> astearns: This is F2F leftover<br>
&lt;dael> koji: The leading-trim has text repesenting text-topa nd text-bottom. text-top and -bottom isn't browser interop or even on same browser across OSs. prop is to define. One prop is to use specific asender and descender. Another is em height. This isn't defined in CSS but algo is from geck<br>
&lt;dael> koji: Seems to do a good job for non-tall scripts<br>
&lt;dael> fantasai: I don't think I agree with a platform text value for this metric. I think people looking to trima re looking for a particular value. Does make sense to have other two, ascent, descent and em height. If we want to define an existing keyword to do that or add a new I'm less sure<br>
&lt;dael> fantasai: Interesting question of these metrics which do we want<br>
&lt;dael> myles: Like to not parse tables myself. Likely look up the functions. not sure if that defetes purpose.<br>
&lt;dael> fantasai: It means you cant read the metrics?<br>
&lt;dael> myles: Can but takes a lot of code to get the table and figure out the values and convert<br>
&lt;dael> koji: If you call core text ascendant and descendant aren't interop<br>
&lt;fantasai> s/metrics/sTypo metrics/<br>
&lt;dael> myles: If there was a interop field we prop would jsut hook that field up to core text field which deferts purpose of interop field so that's unfortunate<br>
&lt;dael> koji: Clarify, the division of leading trim where authors use webfonts so it's the same bianary on all platforms and borwsers. If they use font-top they see different layout result. For this property I think having the same result for same font value is quite important<br>
&lt;fantasai> +1 to koji<br>
&lt;dael> astearns: Your last comment is that if for whatever reason web font is serving two values typo text won't be interop if metrics are different in font files. We're looking for interop if same font files is served.<br>
&lt;dael> astearns: I don't know if it's the case that if you  have the same font file that the different text rendering systems will us OS2 table data<br>
&lt;dael> chris: Probably not. Was the case that they all used different tables<br>
&lt;dael> astearns: So even if we do spec that you have to get data out of font file we'd still end up with bad interop due to different text rendering<br>
&lt;dael> koji: Could be differences of rounding. Most of difference in font metrics comes from open type fonts having 3 different metrics and each platform uses different of 3. If browsers use same metrics should be interop<br>
&lt;dael> astearns: I'm not sure browsers are using same metrics<br>
&lt;dael> koji: Blink we use same metric as one platofrm uses. Even if same web fonts blink uses different metrics depending on platform<br>
&lt;dael> koji: We rely on platform API to read metrics<br>
&lt;fantasai> And this drives authors crazy<br>
&lt;dael> myles: meta question- if we resolve on this to have interop do you expect to apply this to other css properties. Like we'd have to implement new type system to get interop or is this one-off<br>
&lt;dael> koji: At least for new things I'd like itneroperable ones. Some reasons we may need existing ones, legacy reasons or future platofrm behavior. in those cases I'm fine to provide options.<br>
&lt;fantasai> +1<br>
&lt;dael> astearns: Should we continue later since we're at time?<br>
&lt;dael> myles: Good idea<br>
&lt;dael> astearns: Let's continue in GH and we'll come back<br>
</details>


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

Received on Wednesday, 19 June 2019 17:01:09 UTC