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