Hm, I spent quite a bit of time trying to pass the loaded font-weight in as an argument to the success callback, but I don’t think that’s going to work. It’s trivial to do with the CSS Font Loading API but not with the fallback behavior. I’m open to ideas!
Consider the scenarios:
Load a 400 weight and expect a 400 weight: OK.
Load a 400 weight and expect a 600 weight: Error-ish—browsers exhibit a faux bolding that will incorrectly report that a 600 weight has been loaded. This may be OK enough for our purposes.
Load a 600 weight and expect a 400 weight: Error—using @font-face with a font-weight: 600 and using the test element <div style="font-family:MyCustom; font-weight: 400"> will still use the new font family. It thinks 400 has loaded but it’s actually using 600.
Load a 600 weight and expect a 600 weight: OK.
So, in the font-weight branch, I’ve included a version of the script that runs through the font-weights and tests how many have unique dimensions. If you’re loading 9 weights and there are 9 unique dimensions, it will trigger a success callback. You get one callback when all your weights have loaded.
Of note, this does not work around faux bolding. I think this is OK-ish. Open to suggestions, of course.
I haven’t decided yet if this is worth merging into master (it’s about a 20% growth in GZIP file size), but it’s available for use in that branch.
Yea, this is a known problem. The Web Font Loader has the same issue. I think the only work-around is font-synthesis or renaming the font while loading it and renaming it back afterwards (but browser support for that is iffy --- at least if you want to do it without re-parsing the font).
demo headdemo loads two fonts with the same name but different font-weights.
The script doesn't check if both are loaded, confirmed by @zachleat in this tweet.
The text was updated successfully, but these errors were encountered: