W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

Re: [csswg-drafts] [css-fonts-5] @font-face supports incremental (#6063)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Jul 2021 23:24:55 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-889522942-1627601094-sysbot+gh@w3.org>
The CSS Working Group just discussed `font-face supports incremental`, and agreed to the following:

* ``RESOLVED: add a `incremental` to the `font-technology` values production as described on the PR``
* `RESOLVED: Add this keyword in fonts-4 as well`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: font-face supports incremental<br>
&lt;emilio> myles: So the w3c has a web-fonts WG. For the past year or so it has been working in tech to make fonts progressive<br>
&lt;emilio> ... similar to how you load an image over a slow internet connection you get an image incrementally<br>
&lt;emilio> ... the goal is to be able to load the part of the font that's necessary to draw the relevant text, but be able to draw that text before the whole font is downloaded<br>
&lt;emilio> ... it wouldn't look blocky like images, it's more about slicing into glyph ranges etc<br>
&lt;emilio> ... it's not possible on fonts right now because you need data from all over the file, so we're solving that<br>
&lt;emilio> ... there's a behavior change for content, e.g., if you style a contenteditable div with these fonts typing might need to fall back to another font<br>
&lt;emilio> ... so we think it should be opt-in<br>
&lt;emilio> ... the best way I think would be via the supports keywords in @font-face<br>
&lt;fantasai> https://www.w3.org/TR/css-fonts-4/#font-face-src-parsing<br>
&lt;emilio> ... so the proposal is to add a new keyword to the `font-technology` production<br>
&lt;emilio> ... to say that it supports incremental<br>
&lt;emilio> q+<br>
&lt;emilio> florian: is it worth looking at the other possibilities?<br>
&lt;emilio> myles: the alternative would be "use a lot of js"<br>
&lt;fantasai> florian: nope<br>
&lt;TabAtkins> emilio: one thing you mentioned is it may depend on the content being styled<br>
&lt;fantasai> emilio: Mentioned this might depend on the content that you're styling<br>
&lt;TabAtkins> emilio: i don't see a great way to make it depend on the element<br>
&lt;TabAtkins> emilio: Maybe you want your contenteditable...<br>
&lt;TabAtkins> emilio: I don't ahve a better proposal<br>
&lt;TabAtkins> emilio: might be worth looking into this being allowed per element<br>
&lt;emilio> myles: so right now the strategy that we think makes the more sense is to annotate the font loads and not the elements<br>
&lt;emilio> ... it'd be cool if the browser knew whether there was going to be dynamic content or such<br>
&lt;TabAtkins> emilio: Isn't it like a will-change: content?<br>
&lt;TabAtkins> emilio: We have precedent for will-change:not-a-property<br>
&lt;TabAtkins> flackr: yes there is<br>
&lt;TabAtkins> myles: Do you think we shoudl only annotate the element, or *also* the font-face?<br>
&lt;TabAtkins> emilio: I think the font-face makes sense too<br>
&lt;TabAtkins> myles: ok so i think we can talk about these separately - could you open an issue?<br>
&lt;TabAtkins> emilio: sure<br>
&lt;astearns> ack emilio<br>
&lt;emilio> flackr: curious about how this interacts with font-display<br>
&lt;emilio> ... do we consider a partially-downloaded font ready for use?<br>
&lt;emilio> myles: I don't know the answer to that, do you think that's a blocker for this?<br>
&lt;emilio> TabAtkins: probably not<br>
&lt;emilio> RESOLVED: add a `incremental` to the `font-technology` values production as described on the PR<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: q, do we want to add this keywords to fonts-4 or fonts-5?<br>
&lt;emilio> ... none of the stuff in 4 is implemented is it?<br>
&lt;emilio> myles: the metrics override is in 4 I think?<br>
&lt;emilio> fantasai: the override metrics is in 5 but the supports keyword is in 4<br>
&lt;emilio> ... so I think we should move the new keyword to 4 or move the whole thing to 5<br>
&lt;emilio> myles: no strong opinion<br>
&lt;emilio> astearns: given we have a PR, maybe let it land in place, tweak later?<br>
&lt;emilio> fantasai: it's a commit, right?<br>
&lt;emilio> myles: yes<br>
&lt;emilio> myles: there's no argument against what you're saying so it's fine<br>
&lt;emilio> RESOLVED: Add this keyword in fonts-4 as well<br>
&lt;fantasai> s/whole thing to 5/whole supports thing to 5, since nobody implements any of the other values either it seems/<br>

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 23:24:57 UTC

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