Re: [csswg-drafts] @font-face overrides for superscript/subscript metrics (#5518)

The CSS Working Group just discussed `@font-face overrides for superscript/subscript metrics`, and agreed to the following:

* `RESOLVED: Add super and subscript descriptors using normal % and from-font values`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic:  @font-face overrides for superscript/subscript metrics<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5518<br>
&lt;tantek> regrets+<br>
&lt;dael> fantasai: There's a proposal to add super and subscript overrides like asc and desc overrides. That's the proposal, was some confusion. Maybe that's resolved from the list<br>
&lt;dael> myles: I wrote a long essay, but summary is probably it's a thumbs up<br>
&lt;dael> florian: I would be in favor. Wondering if we need to allow-list one by one all vertical metrics of fonts or is there a clear way to subset which metrics should be overridable? All vertical things seem plausible in this model. Block direction<br>
&lt;dael> myles: To get a cart blance solution someone needs to list metrics<br>
&lt;dael> fantasai: We pick the ones authors would like to override for some reason. It's not all. Let's do one by one.<br>
&lt;dael> florian: And model can scale so fine.<br>
&lt;dael> myles: Another thing koji mentioned worth discussion<br>
&lt;heycam> q+<br>
&lt;dael> myles: If allow css authors to override currently fonts have values but browsers don't use them. Should we add for these descriptors a new value to say use what's in the font?<br>
&lt;dael> fantasai: Makes sense to me<br>
&lt;dael> astearns: If you know what's in the font, why not repeat the value?<br>
&lt;dael> fantasai: I think you want it to be trust the font. If you change font it's still correct.<br>
&lt;dael> astearns: I was thinking just for ease of impl<br>
&lt;astearns> ack heycam<br>
&lt;dael> heycam: Wondering if these overrides would work if font-face declaration has a local font in source. Esp if this is from fonts keyword which is relying on locally installed fonts. Gets different results in different pages<br>
&lt;dael> myles: I have had an external request from outside big tech who thinks it's important for local fonts<br>
&lt;dael> fantasai: If author put local font using that is fine. These are not things that will be mark or break on well designed webpage.<br>
&lt;Rossen_> q?<br>
&lt;dael> myles: As for the different on different browsers that's what we have today so not worse<br>
&lt;dael> heycam: Okay, although typing in numbers might be much more different<br>
&lt;dael> myles: Someone uses it on their browser, it's good, and then breaks on other browsers<br>
&lt;dael> heycam: Yes, if they're using it at source level<br>
&lt;dael> myles: No strong opinion, will defer if you think it's important<br>
&lt;dael> heycam: Don't feel strong, wanted to mention<br>
&lt;dael> fantasai: We can disallow later if broken. Should bias toward allowing since if you're spec that level it'll work well<br>
&lt;dael> florian: You said you wanted to allow browser to delegate to a font library not in browser. How does that pay in here?<br>
&lt;dael> myles: Coretext exposes this information<br>
&lt;dael> astearns: I think I'm hearing probably concensus for adding suped and subscript descriptors using % and from-font values<br>
&lt;dael> astearns: Is this what we're agreeing on?<br>
&lt;dael> florian: Think so<br>
&lt;dael> astearns: Also normal as a value<br>
&lt;dael> astearns: That's the proposal. Objections?<br>
&lt;dael> RESOLVED: Add super and subscript descriptors using normal % and from-font values<br>
</details>


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


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

Received on Wednesday, 7 October 2020 23:42:14 UTC