- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Feb 2025 20:36:41 +0000
- To: public-css-archive@w3.org
> > * Every local font has to have an equivalent web-font URL > > ... > > * We can either mandate that those web-font alternatives are specified in the descriptor, or have some stock list of local->web font mapping > > Given that one of the important use-cases for local fonts is to allow users access to fonts that support uncommon languages and writing systems, including perhaps those that are under ongoing development, I don't think we can realistically handle this by just providing a predefined list of local->webfont mappings. Web authors and users need to be able to specify and use fonts that we as standards authors and browser developers have never heard of; that perhaps did not even exist at the time we created our "stock list". Agreed, but those uncommon fonts are also less likely to be useful for fingerprinting at scale. With the async approach to loading fonts, "trying" all the possible uncommon fonts on an invisible span is something that can be made to take a very long time, rendering this fingerprinting technique less compelling. > > So that suggests the "equivalent web-font" needs to be specified by the author. This is exactly what an author can already do using `src:local(...)` in an `@font-face` rule, followed by a fallback `src: url(...)` alternative; the only difference seems to be the proposal that access to the local font should be made asynchronous, with similar timing to what a cached webfont resource would have. We could use that "wrong" font as the local font next time for that origin, or do something like quickly download some of the metrics for the font to compare? Origins that use valid URLs for their font won't suffer from this. I'm sure we can come up with solutions to some of this. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11648#issuecomment-2635016121 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 4 February 2025 20:36:43 UTC