W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [css-fonts] Reduce layout shift via @font-face descriptor(s) overriding inline spacing (#5533)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Oct 2020 16:13:58 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-714601877-1603383236-sysbot+gh@w3.org>
The CSS Working Group just discussed `Reduce layout shift via @font-face descriptor(s) overriding inline spacing`.

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: Reduce layout shift via @font-face descriptor(s) overriding inline spacing<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5533<br>
&lt;chris> q+ to say something that only really works on monospace is kinda suspect<br>
&lt;fremy> TabAtkins: we talked about this in the past, we have some updates<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack chris<br>
&lt;Zakim> chris, you wanted to say something that only really works on monospace is kinda suspect<br>
&lt;fremy> chris: the idea was that to avoid layout shift, you would put values that would update the advance value of the font<br>
&lt;fremy> chris: that shift however only works if you have a monospace font<br>
&lt;xiaochengh> q+<br>
&lt;jfkthame> q+<br>
&lt;fremy> chris: a multiplier would work<br>
&lt;fremy> chris: but that would not work visually<br>
&lt;fremy> chris: because the glyphs will overlap each other<br>
&lt;fremy> chris: so my thought is that we should instead scale the glyphs<br>
&lt;Rossen_> ack xiaochengh<br>
&lt;fremy> xiaochengh: there are 3 proposals in the issue<br>
&lt;fremy> xiaochengh: 1 add fixed value to the advance<br>
&lt;fremy> xiaochengh: 2 scale the advances<br>
&lt;jfkthame> q-<br>
&lt;fremy> xiaochengh: 3 scale the font-size by some percentage<br>
&lt;fremy> xiaochengh: I tested all the 3<br>
&lt;fremy> xiaochengh: and I don't have a strong opinion<br>
&lt;fantasai> +1 to everything jfkthame said in the thread<br>
&lt;fremy> xiaochengh: I think 3 > 2 >> 1<br>
&lt;fremy> florian: is this meant to be tied to font-display?<br>
&lt;fremy> florian: so this only applies after the fallback resolves?<br>
&lt;fremy> xiaochengh: we put that in the font descriptor<br>
&lt;TabAtkins> q+<br>
&lt;myles> See also: https://github.com/w3c/csswg-drafts/issues/450<br>
&lt;fremy> xiaochengh: so if we fail to load the web font, we use the distorted version of the fallback font<br>
&lt;Rossen_> q?<br>
&lt;myles> q+<br>
&lt;fremy> TabAtkins: based on JonathanNeal comments<br>
&lt;myles> specifically: https://github.com/w3c/csswg-drafts/issues/450#issuecomment-245485065<br>
&lt;fremy> (issue with audio)<br>
&lt;fantasai> s/JonathanNeal/jfkthame/<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;fremy> TabAtkins: based on the comment scaling the whole thing is similar to the font-size change<br>
&lt;fremy> TabAtkins: what was things comment?<br>
&lt;fremy> florian: I think that was its preferred option<br>
&lt;fantasai> Clearly nobody tried this with Arabic. Doing anything other than scaling that would be seriously broken<br>
&lt;fremy> TabAtkins: yeah, then let's agree with his preferred outcome<br>
&lt;florian> xiaocheng did try arabic<br>
&lt;fremy> TabAtkins: especially since we have similar things already<br>
&lt;fremy> xiaochengh: I agree with that<br>
&lt;Rossen_> ack myles<br>
&lt;fremy> myles: there is an issue I linked to<br>
&lt;fremy> myles: and there is one comment in it which I think is useful<br>
&lt;fremy> jason list 5 adjustments he would be interested in making<br>
&lt;fantasai> myles is referencing https://github.com/w3c/csswg-drafts/issues/450#issuecomment-245485065 I think<br>
&lt;fremy> myles: most of properties not descriptors<br>
&lt;fremy> myles: so I think the correct solution would not include a descriptor<br>
&lt;Rossen_> q?<br>
&lt;fremy> myles: so this is one quick fix, but a proper solution would be different I think<br>
&lt;fremy> myles: and interact with the 5 properties he mentioned<br>
&lt;fremy> myles: and since we probably don't want 2 ways of fixing this<br>
&lt;Rossen_> ack fantasai<br>
&lt;fremy> myles: I would rather not add this as a stop-gap switch<br>
&lt;fremy> fantasai: there are other use cases for this descriptor though<br>
&lt;fremy> fantasai: so we could look into this as well<br>
&lt;fremy> Rossen_: do you think adding this fix is a step in the wrong direction?<br>
&lt;fremy> myles: I think the answer is yes<br>
&lt;fremy> myles: because this problem is not urgent<br>
&lt;fantasai> s/though/though: because glyphs are often drawn at different actual sizes for the same nominal size, a scale factor could be useful in other cases/<br>
&lt;fremy> myles: so given that, the value of solving one little part is greater than the cost of having two competing solutions in the long term<br>
&lt;fremy> Rossen_: so, back to the folks who opened this<br>
&lt;fremy> Rossen_: any comment?<br>
&lt;myles> s/greater/less/<br>
&lt;fremy> chris: I agree with myles I think<br>
&lt;chris> btw we have been trying to solve this since 1997<br>
&lt;fremy> myles: but I want to encourage xiaochengh to look into this more<br>
&lt;chris> https://www.w3.org/TR/WD-font-970721#widths<br>
&lt;fremy> myles: there is a solution here, but it's not yet there<br>
&lt;fremy> xiaochengh: ok, I think I agree with myles<br>
&lt;fremy> chris: we had stuff in 1997 about this<br>
&lt;fremy> chris: I pated the link in the chat<br>
&lt;fremy> jfkthame: we could use the font data and use a data url as the source ^_^<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 October 2020 16:14:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:20 UTC