- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Feb 2021 15:43:04 +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> <gregwhitworth> Topic: Reduce layout shift via @font-face descriptor(s) overriding inline spacing<br> <chris> github: https://github.com/w3c/csswg-drafts/issues/5533<br> <gregwhitworth> xiaochengh: we'd like to introduce a new descriptor called advance-override<br> <gregwhitworth> xiaochengh: it's to multiply the advance-width<br> <gregwhitworth> xiaochengh: the intent is to use it to reduce layout shift when switching between fallback and webfonts<br> <gregwhitworth> xiaochengh: it's intended to wrap a fallback font with wrapper to use advanced-override<br> <gregwhitworth> xiaochengh: this is in the same group with ascent-override and line-gap override<br> <gregwhitworth> xiaochengh: there are some considerations with this proposal<br> <chris> advance width described here https://www.w3.org/TR/css-values-3/#ch<br> <gregwhitworth> xiaochengh: the first one is whether to use a property or a descriptor<br> <gregwhitworth> xiaochengh: our consideration is to make things easy to implement and we've confirmed as we've done this behind a flag in Chrome<br> <gregwhitworth> xiaochengh: we want to make it easy for web authors to use it too<br> <fantasai> +1 to making it a descriptor and not a property<br> <gregwhitworth> xiaochengh: a web font provider can provide these in a stylesheet they provide to authors<br> <gregwhitworth> xiaochengh: so we think our proposal achieves all of the goals<br> <gregwhitworth> xiaochengh: font-display cannot really reduce layout shift<br> <chris> q+ to note that advance-width should be advance measure (it is a width for horizontal writing)<br> <gregwhitworth> xiaochengh: the third issue is typography, when we use such override descriptors we expect the legibility of the fallback font to be worsened<br> <gregwhitworth> xiaochengh: we don't think this is unacceptable as it only occurs when a web font fails to load<br> <gregwhitworth> xiaochengh: if the actual fallback font gets unusable means that the fallback font and web font differ too much<br> <gregwhitworth> xiaochengh: there is a similarity between this and letter spacing but they're different things<br> <gregwhitworth> xiaochengh: this is working with the width of the glyphs themselves, so letter-spacing doesn't apply<br> <gregwhitworth> xiaochengh: also happy for name feedback<br> <astearns> ack chris<br> <Zakim> chris, you wanted to note that advance-width should be advance measure (it is a width for horizontal writing)<br> <gregwhitworth> chris: minor point<br> <gregwhitworth> chris: advanced-width is correct for horizontal writing<br> <gregwhitworth> chris: in the units spec, the advance-measure it can be vertical and horizontal<br> <gregwhitworth> fantasai: the problem with that is you may want different numbers with width and height<br> <chris> advance measure described here https://www.w3.org/TR/css-values-3/#ch<br> <gregwhitworth> fantasai: you may not want the same adjustments in both directions<br> <drott> q+<br> <gregwhitworth> fantasai: if you're typesetting correctly you'll need to ensure you're talking about width or height<br> <myles> q+<br> <gregwhitworth> chris: I agree with fantasai<br> <gregwhitworth> xiaochengh: this is just for the horizontal width<br> <astearns> ack fantasai<br> <gregwhitworth> xiaochengh: we're using others for vertical for ascent and descent<br> <gregwhitworth> fantasai: I don't think you understood my point as this doesn't have to do with ascent & descent<br> <gregwhitworth> fantasai: depending on how you're typesetting you'll need a different number vertically or horizontally<br> <fantasai> When typesetting horizontally or vertically sideways, need the same number<br> <gregwhitworth> xiaochengh: for the same font, when it's used horizontally & vertically<br> <gregwhitworth> florian: for upright fonts you should probably have two numbers<br> <fantasai> but for vertical writing typeset upright, you will want a different number<br> <gregwhitworth> florian: for that particular problem you should take 2 numbers and the second is optional<br> <astearns> ack drott<br> <fantasai> because that's the height of the glyph you're measuring, not the width of it<br> <gregwhitworth> Domenic: is that required for the specificity of src local for wrapping a web font?<br> <gregwhitworth> fantasai: imagine two fonts Verdana and Times Roman and imagine they look a bit more similar<br> <gregwhitworth> fantasai: you'll notice that Times is very narrow but they're very close in height<br> <gregwhitworth> fantasai: so if you're vertically setting then you're fine<br> <gregwhitworth> Domenic: I was thinking more CJK<br> <gregwhitworth> fantasai: if I'm typesetting vertically (eg: I rotate it) then I'll need to typeset it<br> <astearns> ack myles<br> <gregwhitworth> florian: also the same font may be used in different directions in the same document<br> <gregwhitworth> myles: we've gotten a similar request for similar features that we should be thinking about<br> <gregwhitworth> myles: we're thinking about this in the time of loading to ensure that the fallback looks like the webfont<br> <gregwhitworth> myles: we've looked at this for when a font doesn't support glyphs that the page is asking for and we want to ensure that the fonts look alike<br> <chris> The next topic https://github.com/w3c/csswg-drafts/issues/126<br> <fantasai> s/need to typeset it/need a different multiplier<br> <gregwhitworth> myles: doing this requires more than just the advance of the font<br> <gregwhitworth> myles: I think it would be good to solve both of these at the same time with the same feature<br> <gregwhitworth> astearns: I agree they're similar<br> <gregwhitworth> astearns: matching the fallback with the webfont you don't know which font will match that font<br> <gregwhitworth> myles: yes each person that has asked for this is willing to spend the time to craft their page to get as close as possible<br> <florian> q+<br> <myles> https://github.com/w3c/csswg-drafts/issues/126#issuecomment-245708960<br> <fantasai> s/page/@font-face rules with local/<br> <astearns> ack florian<br> <drott> florian, https://www.fauxfoundry.com/?<br> <chris> q+<br> <gregwhitworth> florian: reminds me of a project a while back, something like full greek but you were trying to match the style of greek font even if you only had latin fonts but they used variable fonts to adjust that. Not sure how we apply that idea to this use case<br> <jfkthame> q+<br> <gregwhitworth> florian: rather than just changing widths<br> <astearns> ack chris<br> <gregwhitworth> chris: yeah, the difference between that and they're changing the glyph outlines to produce a parametized fonts, this proposal is not changing glyphs at all just ensuring the spacing is correct<br> <gregwhitworth> fantasai: this won't work for cursive then<br> <astearns> ack jfkthame<br> <gregwhitworth> chris: I agree, won't work for Mongolian and Arabic<br> <gregwhitworth> jonathan: Seems like what panos was trying to do what Myles was wanting to do<br> <gregwhitworth> jonathan: when fallback happens based on meta attributes it can search for fallback that looks for attributes of the web font<br> <chris> https://www.w3.org/Fonts/Panose/pan2.html<br> <gregwhitworth> jonathan: that's rather different than using a fallback as a given font and behave as much like a particular font<br> <gregwhitworth> myles: yes, what you said is correct<br> <florian> [The project I mentioned earlier is https://www.fauxfoundry.com/ ]<br> <gregwhitworth> myles: the requests we've gotten is not trying to add serifs, like the example florian gave, but the examples are trying to adjust letter-spacing, font-weight (5 props) in the fallback font. And if you're going to use the fallback then bump up the weight<br> <myles> font-weight<br> <myles> font-size<br> <myles> letter-spacing<br> <myles> word-spacing<br> <myles> line-height<br> <chris> Faux Greek foundry https://www.fauxfoundry.com/<br> <gregwhitworth> myles: the direction I was going there, one possible way - we should solve this problem in multiple ways. We can have a descriptor or we can extend the properties to be fallback aware<br> <leaverou> q+ to say this is starting to sound a lot like the next topic and maybe they should be discussed together?<br> <gregwhitworth> fantasai: I think using font-face is way better given you're describing the font<br> <gregwhitworth> jonathan: very much agree with fantasai on that<br> <chris> by Irene Vlachou & Laurence Penney<br> <fantasai> s/font-face/font-face to tie values to particular font faces/<br> <gregwhitworth> myles: I'm surprised to hear it although I understand it partly<br> <gregwhitworth> myles: the benefit of the properties is that you get selectors<br> <gregwhitworth> florian: why would you want to select against the element and not the font<br> <gregwhitworth> myles: only request is to consider them both<br> <gregwhitworth> leaverou: I'm hearing a lot of items from the next issue<br> <drott> q+<br> <gregwhitworth> astearns: I'm thinking of "Yes we should solve this but let's solve all the issues together"<br> <astearns> ack leaverou<br> <Zakim> leaverou, you wanted to say this is starting to sound a lot like the next topic and maybe they should be discussed together?<br> <astearns> ack drott<br> <gregwhitworth> drott: in solving this - do we want to distinguish between another font or what's available locally<br> <gregwhitworth> drott: that's a fast fallback solution or we load a foundry for variable fonts used for fallback that's completely different<br> <gregwhitworth> drott: and it would be required for load<br> <gregwhitworth> astearns: I'd want 1 way to define the override<br> <gregwhitworth> drott: there are two use cases, the more flexible way is a bit wider in scope.<br> <gregwhitworth> fantasai: so they're cursive, you can't letter space them so how do you ensure they're rendered properly if an author sets this<br> <gregwhitworth> myles: would it be the same as the scenario when you use letter-spacing<br> <gregwhitworth> myles: we have a request to ignore letter-spacing when an Arabic font is used<br> <drott> q+<br> <fantasai> fantasai: that's in the spec<br> <chris> Some arabic fonts do have a spacing axis (variable fonts again)<br> <gregwhitworth> fantasai: that's what we define already for letter-spacing<br> <gregwhitworth> xiaochengh: we tried it on Arabic and we see the width of the characters change and the shaping doesn't look bad<br> <TabAtkins> Lol, Chrome *does* apply letter-spacing to Arabic currently, it just... puts space between teh characters.<br> <TabAtkins> They're still shaped properly for their place in the word.<br> <florian> q+<br> <TabAtkins> Like kashida-ing without the kashida<br> <chrishtr> q+<br> <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/8903<br> <gregwhitworth> fantasai: I don't think you used a large enough value, in order to avoid rendering at joins they have a small amount of overlap built in<br> <florian> q-<br> <gregwhitworth> fantasai: so to see if it is working or not you'd need a larger range than that tolerance<br> <gregwhitworth> drott: a little bit of adjustment doesn't break them apart<br> <drott> q-<br> <gregwhitworth> chrishtr: if letter-spacing then it seems logical to do the same with this descriptor<br> <chris> q+<br> <astearns> ack chrishtr<br> <gregwhitworth> chrishtr: the other thought I had was the only other concern would be to apply a different override in each direction<br> <fantasai> s/direction/axis<br> <gregwhitworth> astearns: that was brought up earlier you'll need one for inline and block<br> <gregwhitworth> TabAtkins: no it's inline in both times, just depends on the writing mode<br> <gregwhitworth> fantasai: it will be width/height to the font<br> <astearns> ack chris<br> <myles> https://en.wikipedia.org/wiki/Kashida<br> <gregwhitworth> chris: it's not true to say that those scripts don't have letter-spacing it's that you need to use them to use a longer connection but most fonts don't do that<br> <gregwhitworth> fantasai: it's more complicated than that<br> <gregwhitworth> fantasai: we would say that you don't do this for Mongolian or Arabic and some fonts may do it but most won't<br> <fantasai> s/would//<br> <chris> Arabic text alignment & justification https://www.w3.org/TR/alreq/#h_justification<br> <fantasai> This is specced in css-text-3<br> <gregwhitworth> astearns: I think we should close off with a general yes, we want to have this advance-override but move to the next issue about how to define it<br> <gregwhitworth> myles: is it going to be a length?<br> <gregwhitworth> xiaochengh: it's a percentage<br> <gregwhitworth> chris: it's a multiplier<br> <gregwhitworth> TabAtkins: it's going to be the best overall solution that works the most consistently<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-776033970 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 15:43:07 UTC