Re: [csswg-drafts] [css-fonts] extend font-size-adjust to take a pair of values: <metric> <number> (#6160)

The CSS Working Group just discussed `[css-fonts] extend font-size-adjust to take a pair of values: <metric> <number>`, and agreed to the following:

* `RESOLVED: Start with ex cap ic and ch`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  [css-fonts] extend font-size-adjust to take a pair of values: &lt;metric> &lt;number><br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/6160<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/6160<br>
&lt;dael> fantasai: I think we can conclude on key parts. Added ability for font-size-adjust to take metric name and then target ratio. Question is what are initial keywords<br>
&lt;dael> fantasai: Propose add xcap ic and ch<br>
&lt;dael> fantasai: Jonathan Kew ageed. Wanted to discuss ascent and descent. I would suggest for now adopt the initial set and if we want to discuss additional do so in separate issue<br>
&lt;fantasai> s/xcap/ex, cap/<br>
&lt;dael> astearns: Suggesting the short names?<br>
&lt;dael> fantasai: Yeah, to match units. And b/c operate in correct axis which may be height or width depending on writing mode<br>
&lt;dael> fantasai: If we want independwnt of writing mode would need to add variants. We can start with this set<br>
&lt;dael> myles: Feel like we should add acsent to the set. Cases where it might give you confusing results. If someone applies more likely to do good. Valuable to have<br>
&lt;dael> fantasai: I think cap will be better in most cases<br>
&lt;dael> fantasai: ascent and descent metrics are pretty wild when fonts are outside of latin. This applies to fallback and system fonts. You'd get something that works well until it really doesn't. I think that's a serious concern we don't have a way to address. Can keep talking. I think this is a good intial set<br>
&lt;dael> astearns: Given that are you okay to start with these 4 myles?<br>
&lt;dael> myles: fantasai are you saying you think ascent is harmful?<br>
&lt;dael> fantasai: Yes. Someone will use it expecting reasonable and it will fallback to a system font on someone's machine that is very different<br>
&lt;dael> florian: Arial and MSUnicode are wildly different, to give an example<br>
&lt;dael> fantasai: Slide 23 on the deck in the issue show and example of wildly different<br>
&lt;fantasai> i/fantasai/fantasai: You'll end up with a font that's much too small/<br>
&lt;dael> myles: I think it will be good in more cases then bad. For metrics that don't have units I think we should use longer names. Value of shortnames is porpotional to number of times typed. For the lengths type a lot, but without it's only this one property. Longer names to make it clear is valuable<br>
&lt;dael> fantasai: ic and ch they should respond to writing more and text orientation so they could be width or height. WE can't use a longer name for those. If ic and ch have shortnames it makes sense for ex and cap to also match shortnames<br>
&lt;dael> myles: Point I was making about metrics that don't have units that match<br>
&lt;dael> fantasai: We don't have those yet<br>
&lt;dael> myles: With ascent we would<br>
&lt;dael> fantasai: Yes. But for ones with a unit; 2 have to match b/c can't add height or width. Others might as well b/c why be different<br>
&lt;dael> astearns: Prop: Add these four to start with. After that we can add more<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: Start with ex cap ic and ch<br>
&lt;dael> astearns: myles can I ask you to add a new issue for ascent and poss decent?<br>
&lt;dael> myles: You could<br>
</details>


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


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

Received on Thursday, 6 May 2021 00:02:53 UTC