- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Aug 2021 19:16:12 +0000
- To: public-css-archive@w3.org
In addition to the potential for unexpected behavior if the "preferred" rule does not precisely shadow the fallback, Myles's example above (repeated here for ease of reference):
```
@font-face {
font-family: jewel;
font-weight: 400;
src: url(jewel-fallback.woff2) format("woff2");
}
@supports font-technology(color-COLRv1) {
@font-face {
font-family: jewel;
font-weight: 400;
src: url(jewel-v1.woff2) format("woff2");
}
}
```
also conceals a performance footgun.
Consider the case of a browser that *does* implement COLRv1, so it is expected to use the jewel-v1.woff2 font. That seems fine.
What is perhaps not obvious to the author is what happens if the content styled with `font-family: jewel` includes a character that is not supported by `jewel-v1.woff2`. Because the `jewel` family contains two faces with identical style descriptors, when the browser finds a character missing from one of them, it will be expected to fall back to the other.
It's likely, of course, that the two `jewel` faces have the same character coverage, and falling back from `jewel-v1.woff2` to `jewel-fallback.woff2` is pointless, but the browser will nevertheless have to download the fallback resource and check its character coverage.
This could be avoided by careful use of `unicode-range`, so that any character that is not covered by the v1 font is known to be excluded from the fallback face as well, but this is an added burden for authors, and seems unlikely to be done with any consistency.
--
GitHub Notification of comment by jfkthame
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-905805384 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 August 2021 19:16:13 UTC