Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Introduce Font and FontVariationDescription #105
Ready to deploy. This pull request is an internal rewrite of how font (family) names and font variation descriptions are passed around. Currently this is done using a pair of font family names and an object containing font family names and descriptions. This pull request introduces a Font class that contains FontVariationDescription instances. This will reduce the number of parameters passed around, makes type annotations easier to read and creates a central place to manipulate fonts and font variations.
@bramstein Ah crap, I just realized something when looking at the Typekit side of these changes. I believe this branch changes the arguments that are passed back and forth between third-party code (like Typekit's own kit JS) and the core webfont.js library (in the
This doesn't seem like an OK change to make, as it will cause older third-party JS (like older Typekit kits) not to work with the newer versions of webfont.js (and vice-versa), since the different versions will be expecting different argument numbers and types.
Also, passing anything back and forth between third-party codebases (like Typekit kit JS) and webfont.js other than simple JS types (like boolean, number, string, array, object used as key/value hash) isn't a good idea. Passing instances of classes back and forth gets complicated, since the method names of that class that are shared between them must be ensured to match and never change (through exports) so that the code can interoperate. Basic JS types are much more future proof, and we also don't have to worry about compilation renaming throwing a wrench in the works.
I think you should make a change so that the arguments that are passed back and forth between the non-webfontloader code and the webfontloader module code doesn't change at all. That will ensure that we don't have backward-incompatibility problems.
@bramstein Sorry for the previous false alarm. After looking at this more closely, I realize that it's only changing what webfont.js is passing around internally between the modules and the core code, but it doesn't change any data that 3rd-party JS would be passing back and forth with webfont.js.
I added some notes about naming, one potential issue with the Google module, and a lack of tests for some of the functionality of the Ascender module. Otherwise, this looks good.
For the naming, I just think we should switch to using "fonts" wherever we have an array of font objects (in all of the module code and the core code) instead of continuing to call the variables "fontFamilies" or similar when the items within don't actually represent families. It will just make the code easier to read in the future.