You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if you write something like document.fonts.check("tpyo-font", "test text"), it'll return true, since the typo'd font doesn't exist (and thus doesn't need to be loaded), and the text text will be rendered in the browser fallback instead (which also doesn't need to be loaded). Similarly, if you specify the font names correctly, but the unicode-ranges on them are set up so that the test text will be rendered in the browser fallback anyway, it'll also return true.
These special cases are explicitly called out in the method's definition https://drafts.csswg.org/css-font-loading/#font-face-set-check, and they're correct for the use-case the method was designed for (checking if some text will cause a font to start downloading or not), but it's consistently been a minor source of confusion for authors.
It's reasonable to instead want a method that actually answers the question "can this text be rendered by these specific fonts", without letting browser fallback fonts mess around with the answer. See #6798 for an example use-case.
I suggest we add an option-bag final argument to the function, letting you change into this new behavior if desired.
Some details to iron out for the behavior:
Do we literally just take the existing method's behavior and remove browser fallbacks from consideration? That is, should it still return false if we'd require a currently-unloaded font from the list?
Or do we have it actually just check the unicode ranges, ignoring the loading status, so you can just tell if a given bit of text is possible to render in its entirety with a given font stack?
Currently, if you write something like
document.fonts.check("tpyo-font", "test text")
, it'll return true, since the typo'd font doesn't exist (and thus doesn't need to be loaded), and the text text will be rendered in the browser fallback instead (which also doesn't need to be loaded). Similarly, if you specify the font names correctly, but the unicode-ranges on them are set up so that the test text will be rendered in the browser fallback anyway, it'll also return true.These special cases are explicitly called out in the method's definition https://drafts.csswg.org/css-font-loading/#font-face-set-check, and they're correct for the use-case the method was designed for (checking if some text will cause a font to start downloading or not), but it's consistently been a minor source of confusion for authors.
It's reasonable to instead want a method that actually answers the question "can this text be rendered by these specific fonts", without letting browser fallback fonts mess around with the answer. See #6798 for an example use-case.
I suggest we add an option-bag final argument to the function, letting you change into this new behavior if desired.
Some details to iron out for the behavior:
The text was updated successfully, but these errors were encountered: