- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 16:27:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `ch and font downloads`. <details><summary>The full IRC log of that discussion</summary> <emilio> topic: ch and font downloads<br> <emilio> github: https://github.com/w3c/csswg-drafts/issues/3135<br> <emilio> florian: we have multiple viewpoints represented, but are they enough?<br> <emilio> TabAtkins: initial issue is that currently ch uses the advance of the 0 glyph, which means that if your first font doesn't have a 0 glyph you go down the list and trigger a download for the next font on the list<br> <emilio> ... so I agree that that's unfortunate<br> <emilio> ... one objection is that if zero is defined _and_ being used, might as well use it<br> <emilio> ... this brings in potentially stateful behavior. Whether or not the ch uses it depends on whether the dom contains a 0, or a user types it, etc<br> <emilio> ... so options are: (1) no change, ch triggers downloads<br> <emilio> ... (2) always rely on first available font<br> <emilio> ... (3) look at 0 if there, and accept it's a stateful behavior<br> <emilio> chris: I think there's a (4), which is switch from the 0 glyph for .notdef<br> <emilio> TabAtkins: does .notdef has a reasonable char?<br> <emilio> chris: it's the tofu<br> <emilio> fantasai: we chose 0 because in monospace we want the size of the font, and in a proportional font digits are usually monospace<br> <dbaron> (or with font-variant-numeric: tabular-nums)<br> <emilio> ... so it fullfills all our these requirements<br> <emilio> fantasai: switching to .notdef would be a degradation for most uses of ch<br> <jfkthame_> fantasai++<br> <emilio> ... so I think it's a bad idea<br> <florian> q+<br> <emilio> ... relying on only first available font is problematic because often there's a stack where you're mixing latin/cjk fonts, so I don't think it's a good idea either<br> <emilio> ... I have no problem with (3) because I think it's going to be very unusual<br> <emilio> ... to have a font that doesn't have a 0, and some stack font has a zero and doesn't get loaded until later<br> <emilio> ... european digits are used in pretty much every writing system<br> <emilio> ... and chances are the font that has the zero is going to load<br> <emilio> ... so I think the concerns that jfkthame has about triggering a reflow when someone types will be rare<br> <astearns> ack fantasai<br> <astearns> ack florian<br> <emilio> ... and the other options degrade the ch units<br> <fantasai> s/rare/very rare/<br> <emilio> florian: I think where the fonts at the top of the stack doesn't have 0 is reasonably typical<br> <emilio> ... and you want the font with the actual zero<br> <emilio> ... stack with latin first, japanese there, without the digits seems really unusual<br> <emilio> ... one way you could workaround it is using the first avail font is that first avail font is dependent on the space glyph<br> <emilio> ... so you could remove the space from the first font down the list<br> <emilio> q+<br> <astearns> ack dbaron<br> <emilio> ... I don't think using the first avail font will buy us anything<br> <emilio> dbaron: I wonder if the argument that (3) is not a big deal is because it happens really rarely doesn't apply to (1)<br> <emilio> astearns: yeah, the lack of the glyph is really rare, and having a font that hasn't downloaded yet would be even more rare<br> <emilio> iank_: can you clarify?<br> <emilio> astearns: the most common case for lacking of 0 glyph is subsetting, and you do that so that you can use that font and the rest of the stack to render content<br> <emilio> ... so it's common for that font to be used by the content<br> <emilio> dbaron: other thought is about impl complexity<br> <emilio> ... and that depends on what the rules for (1) and (3) actually are<br> <emilio> ... I think (3) requires that if you _do_ download the font you update the ch units<br> <emilio> ... which also applies to (1) because ch units is what triggered the download<br> <emilio> ... so I think the only difference in implementation between (1) and (3) is whether the download is actually triggered<br> <astearns> ack emilio<br> <emilio> TabAtkins: that's correct<br> <fantasai> emilio: Even though 3 is very rare, I think I'd rather do 1<br> <iank_> don't we have the complexity that fonts can be partially downloaded in the future?<br> <fantasai> emilio: when it happens, it's just terrible, if you have anything sized with ch it shifts when you type a character, that's terrible<br> <fantasai> emilio: I'd much rather do 1, I think<br> <fantasai> emilio: 2 I wouldn't be opposed to, but I think fantasai's arguments are compelling<br> <dbaron> I agree that (1) (current behavior) is the correct thing.<br> <fantasai> TabAtkins: if we're trying to go for 1, I wouldn't be comfortable resolving without Myles around, since he was opposed<br> <fantasai> florian: this is not unique to ch, we have same problem with ex units<br> <emilio> ... if you want ex that depends on x height of the first avail font which is the first one that contains the space<br> <emilio> ... so if the first one doesn't contain the space you do need to trigger the download<br> <emilio> ... unless we want to redefine all font units to not depend on fonts...<br> <emilio> ... I think we can't escape this problem entirely anyways<br> <emilio> ... and giving up on font units doesn't sound like a good idea<br> <dbaron> dbaron: not the em unit, but ex, ch, ic, etc.<br> <emilio> ... so we need one more person to resolve on (1)<br> <emilio> iank_: isn't there a feature to allow fonts to be partially downloaded?<br> <astearns> q?<br> <emilio> astearns: yeah so that would make it more common not to have a 0<br> <emilio> chris: related, is there anything on CSS that assumes that fonts are completely downloaded?<br> <emilio> TabAtkins: yeah, css-font-loaded has a boolean loaded<br> <emilio> chris: yeah, we need to talk about that<br> <emilio> fantasai: tristate?<br> <emilio> dbaron: I think I have memories of working with jdagget on the font downloading code when ex units are used<br> <emilio> astearns: seems on this issue we're at an impasse?<br> <emilio> florian: it seems like consensus is towards (1)<br> <emilio> chris: though myles doesn't like it<br> <emilio> astearns: I think I agree with myles<br> <TabAtkins> s/font-loaded/font-loading/<br> <emilio> ... I want to avoid the case where someone has set up their fonts so that multiple downloads are triggered just to find a character where we could return another value<br> <emilio> ... and update when the download occurs<br> <emilio> florian: how's different with ex units and space?<br> <emilio> astearns: agreed that it's not specific to ch but ch is more common and this is more likely to happen<br> <emilio> jfkthame_: and arguably it can be avoided by changing the font to contain a 0<br> <emilio> astearns: I think this should be an exceedingly rare case but I think we should avoid the download<br> <emilio> jfkthame_: because of the rarity I think we should have the correct behavior. Having an emoji font at the beginning of the font list is not that rare but not getting the ch unit right there seems very unfortunate<br> <florian> q+<br> <TabAtkins> And thus, that rules out #2<br> <emilio> dbaron: one counterpoint here is that part of what makes this condition extra rare is the "and the font doesn't get downloaded for anything else". If the ch unit triggers the download, it's likely the first thing to download the font<br> <emilio> ... and it might be that the benefit that we get from downloading the font earlier is bigger than the issue of triggering an unlikely download<br> <emilio> astearns: say you have a font stacks that has a "my ampersand font", "my emoji font" (unused), and "my content font"<br> <emilio> ... and the emoji font does have a 0<br> <emilio> ... so you download the emoji font _and_ your ch unit doesn't match what your content actually uses<br> <fantasai> emilio: Point dbaron was making was if we do 3, then emoji gets used, and your ch unit changes<br> <emilio> dbaron: but if we do (3) then emoji gets used and your ch unit changes<br> <emilio> astearns: in the scenario of (3) the content font would use the right ch unit (from the content font, when it loads content), but then if you use emoji or a 0 your ch unit changes<br> <emilio> fantasai: I don't think that's going to be a common case<br> <emilio> astearns: yeah this are all really uncommon things<br> <emilio> ... but I agree with myles that prioritizing reducing downloads over layout changes is the right call<br> <emilio> fantasai: we can also make it up to the UA<br> <emilio> ... make triggering downloads not required<br> <fantasai> emilio: but this wouldn't change to half an em<br> <astearns> q?<br> <fantasai> emilio: it would switch to a font lower in the stack<br> <florian> q-<br> <emilio> florian (before ^): we already have the language "if not practical, use half an em"<br> <astearns> ack dbaron<br> <fantasai> emilio: I don't think that the cases that Alan and Myles argued for, I'm with dbaron that actually triggering the download for ch unit is more likely to help performance than cause problems<br> <fantasai> emilio: because by the time you get to layout the text, the font may already be there<br> <fantasai> emilio: otherwise you need to do more layout work, takes up all the ch units<br> <fantasai> emilio: and likely also trigger the download by the time you et to the content of the websiet<br> <fantasai> emilio: so I think doing 1 is the right thing<br> <fantasai> emilio: and also the more sensible thing<br> <emilio> fantasai: so... strawpoll?<br> <emilio> TabAtkins: pick up in two weeks with myles on the call<br> <emilio> ... myles was very strongly against (1)<br> <emilio> ... so don't want to resolve without him<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3135#issuecomment-1204193554 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 16:27:17 UTC