- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 15:08:48 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] font-size-adjust with missing metrics`, and agreed to the following: * `RESOLVED: In cases where the specified metric is not in the first available font, we fall back to using the same thing we do for other typographical units` <details><summary>The full IRC log of that discussion</summary> <astearns> ack ChrisL<br> <emeyer> ChrisL: Problem is we have a thing that says from font, and what happens if the first available font doesn't have that metric, what to do?<br> <emeyer> …1. You just say it doesn't have it<br> <emeyer> …2. You look for a font that does have it, with knock-on that you may get different fonts<br> <schenney> q+<br> <schenney> Text decoration says: If the font file includes information about a preferred thickness, use that value. If the font file doesn't include this information, behave as if auto was set, with the browser choosing an appropriate thickness.<br> <emeyer> …3. You use heuristics, but some people think that would make it better and some that it would make things worse<br> <emeyer> …Let's just talk about the rendering rather than the comptued value<br> <schenney> q-<br> <emeyer> …My feeling is that if the number isn't there, you don't do anything<br> <emeyer> jfkthame: My view is that if font-size-adjust is used, the author is asking for some sort of harmonization across fallbacks, and we shouldn't disable that<br> <fantasai> schenney, I think the case for text-decoration is different than font-size-adjust<br> <emeyer> …Therefore, if the metric is missing, we should use the same heuristics we use for units for ex or cap when the metrics aren't available<br> <fantasai> +1 to jfkthame<br> <emeyer> …We should do the same here for predictability<br> <kizu> +1 would be nice to be consistent with the cap unit<br> <emeyer> iank_: I see Dominic's comment onthe issue; what was his opinion?<br> <emeyer> ChrisL: He thought there should be no adjustment<br> <emeyer> …One reason was related to leaking information from fonts, but that wasn't the main reason<br> <ChrisL> https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-2098488244<br> <emeyer> …Looks like he was also concerned about testing because the language is handwavy<br> <astearns> ack fantasai<br> <emeyer> …It's hard to get reliable WPT tests that way<br> <emeyer> fantasai: I think jfkthame's point is good and would make things somewhat testable<br> <fantasai> s/point/point about matching the font-relative units/<br> <emeyer> jfkthame: I did respond to Dominic's points, and he's right, but taking that approach means CSS units like cap are hard because they're also handwavy<br> <astearns> ack dbaron<br> <emeyer> …We would need to address those as well<br> <emeyer> dbaron: Some of my thoughts depend on the answer to a question I have<br> <emeyer> …Once you've kicked the value of font-size-adjust, if a font doesn't have the metrics, does it get adjusted?<br> <emeyer> …I don't kow that we have an answer to that<br> <emeyer> …There might be better and worse answers to that and I don't know the state<br> <emeyer> …One of the cases that might be interesting here is that sometimes people stick an emjoi font or a font for a few glyphs at the front of the font stack<br> <emeyer> …It seems weird not to be able to adjust for that<br> <emeyer> …Makes me think that if you don't have metrics for the first font, you go down the list until you find a metric, but that works only if you don't adjust for font's that don't have metrics<br> <emeyer> …I think I find synthesizing the metrics weird, but I don't know<br> <dbaron> s/kicked/picked/<br> <ChrisL> q+<br> <astearns> ack ChrisL<br> <emeyer> ChrisL: The thing that concerns me is that if the first available font depends on which property is using it, that means it has different values for different properties<br> <emeyer> …That seems weird to me, since we have a notion of what the first available font is<br> <emeyer> astearns: I agree with you from a spec purity perspective, but it might be the case that different properties can use different evaluations of the first available font<br> <astearns> ack dbaron<br> <emeyer> dbaron: I also feel like it's okay if this doesn't use the same first available font definition used in other places<br> <emeyer> …Particularly if the thing I said about applying the size is also true<br> <emeyer> astearns: I think I've heard equal support for each of the three options, so how do we come to a conclusion?<br> <emeyer> (silence)<br> <dbaron> s/equal//<br> <emeyer> ChrisL: One other point from the disucssion is that some fonts are fully constructed and should have metrics but don't<br> <emeyer> astearns: I think I've heard that adjusting the metric when it isn't there is perfectly valid<br> <emeyer> jfkthame: I suggest that making something up might be worse, but probably at least as likely or more likely to be better<br> <emeyer> …That makes it more likely to get to author intent<br> <emeyer> …We may be overfixating on this, since use of these metrics in combination with fonts that don't have the metrics, it's probably not very common<br> <emeyer> ChrisL: If it's in a CMS and you toss in a bunch of styles and then you pick a font that doesn't fit, that can also happen<br> <emeyer> jfkthame: I would still suggest applying the cap heuristic as we do for the cap unit isn't going to be worse than not doing it<br> <emeyer> ChrisL: I tend to agree more with jfkthame now<br> <emeyer> astearns: In cases where the specified metric is not in the first available font, we fall back to using the same thing we do for other typographical units<br> <ChrisL> In that case can we quickly cover the related https://github.com/w3c/csswg-drafts/issues/10292 as well<br> <emeyer> …(but put into precise spec language)<br> <emeyer> RESOLVED: In cases where the specified metric is not in the first available font, we fall back to using the same thing we do for other typographical units<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6384#issuecomment-2163284492 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 15:08:49 UTC