Though params refer to variable font grade, script changes font weight

Just noticed: the code that handles setting the variable grade in PR #25 uses the font-variation-settings with the "wght" flag:

textblock/src/textblock.js

Lines 52 to 53 in 934cf16

    
           fontVariationSettings: 
        
             '"wght" ' + scaleInRange(tb_ming, tb_maxg, width_ratio)

This is based on the current 0.9.9 code:

textblock/src/textblock.js

Line 56 in 567a0e3

var variableGradeSettings = '"wght" ' + gradeMath;

I'm new to variable fonts, but based on MDN's Variable Font Guide, it looks like font grade is specified not using the "wght" flag but rather the "GRAD" flag (capitalized because grade is a (less common) custom variation axis, unlike weight, which is a (more commonly used) registered axis).

The font used in demo.html, Source Sans Variable - Roman, contains only the weight variation axis. So perhaps the parameter names should be changed from min/maxWidthVariableGrade to min/maxWidthFontWeight? The Variable part could be dropped, since both variable and non-variable fonts' weights can be set using just the font-weight CSS property (non-variable fonts will just round to the nearest available weight); the font-variation-settings property that only works with variable fonts wouldn't need to be used.

The VariableGrade params could be retained in addition to FontWeight params, and the code could be updated accordingly, though a variable font with a grade axis should be used to demonstrate it.

Ah, I see now that the readme mentions simulating grades, so using the "wght" flag is intentional, but I wonder if the param names should still be changed to min/maxWidthFontWeight, since some variable fonts (e.g. Amstelvar) actually do have a 'grade' variation axis?

The issue is there aren't many variable fonts that actually have grades, yet. Maybe the answer is to support both, or maybe add in actual grade support as it becomes more prevalent?

Since so few fonts include variable grades, maybe for the sake of keeping the script as small as possible it would make sense to only support variable weight for now?

Even if you hold off on supporting grades, though, I think it would make sense to change the parameter names from min/maxWidthVariableGrade to min/maxWidthFontWeight, so that if you ever end up wanting to support actual grades you don't have a naming collision issue, and so that what the script is actually doing is more transparent -- especially since the scales for weights and grades aren't necessarily comparable (e.g. looks like Amstelvar's grade range is 25–150).

(I would keep the reference in the readme about using weights to simulate grades, though, to keep the design intent behind supporting variable font-weights clear.)

(The script could continue to support the legacy min/maxVariableGrade params for the time being, of course, for backwards compatibility.)

Hey @tinymachine, I know you have this in #36 but should we pull it out and apply it on its own?

Also note that grade axes aren't consistent; eg Roboto Flex and San Francisco both have grade but with different axis details

	fontVariationSettings:
	'"wght" ' + scaleInRange(tb_ming, tb_maxg, width_ratio)