[css-fonts-4] [varfont] Values in font-variation-settings should be normalized 0.0 - 1.0

[typemytype]

As the draft is setup now the number value in font-variation-settings for each axis has to refer to the ranges declared in the font.

Somehow this feels contra productive. fe: Did some tests today with the Webkit nightly build and ended up with opening Skia with fontTools to know the range (the wdth axis has a range from 0.61998 to 1.2999). Web designers should not know about those values. Font foundries should not bother explaining those values to web designers, so they can set them correctly. The number value could represent a normalised value going from 0 to 1.

The draft also declares that the number values outside a range should be ignored. It seems better to declare extrapolations as an endless fixed value by limiting the value to the boundaries of a range. Similarly as what MutatorMath and fontTools.varLib does.

[svgeesus]

That seems to assume that each font covers the same range, though. If font A covers 0.6 to 1.3 and font B covers 0.5 to 0.8 then it would be weird to have both of those normalized to a 0 to 1 range which means different things for the two fonts.
Its the same as with weights - if font A covers 500 to 700 and font B covers 600 to 999 I don't want to see both hidden under "the font covers 0 to 1" and have to discover what weights that is exactly.
Lastly, designers will see these values exposed in things like Photoshop and InDesign. They should be able to use those same values in their CSS, not have to convert them to special CSS vales.

I agree about clipping rather than ignoring out of range values.

[typemytype]

True, but at the end they all act like a 'slider' going from one end to the other. The test app FontView does it nicely.

How would the value behave when its set as a percentage? (seems like that is not yet implemented in the nightly build)
I understand font-variation-settings is the most low level setting, closely mirroring what happens inside the font.
and I would not count of any app showing those ranges...

[litherum]

How would the value behave when its set as a percentage?

There is no proposal to set it as a percentage.

[litherum]

Font features (font-feature-settings) has this same problem.

See also: #520

[jpamental]

It seems like it's best to treat the number range as analogous to 'thinnest to thickest' or 'narrowest to widest'; i.e. if we used a 1-999 range (or whatever it is we choose), the midpoint should be whatever is the 'reference' shape of the glyph. That way the 'default' value would be 500, and 1 would correspond to the thinnest/narrowest/shortest/etc, 999 being the opposite end of the spectrum.

I'm curious if there's a notion of 'named deltas' to be able to call the 'Black' weight in the spec, and if so could we expose that and/or associate it in our css?

Thinking of something like:

font-family: variablefontname;
font-style: normal;
font-weight: heavy;
(instead of font-weight: 999)

[just saw that @litherum just opened up #574 related to this]

[litherum]

Are we talking about font-variation-settings here? Or the higher-level properties? The policy will likely be different for each of them.

font-variation-settings shouldn't scale or bias its arguments because it is meant to be an escape hatch for web authors who know exactly what they are doing. For everyone else, they should be using the high-level properties instead. Ultimately, the usage of font-variation-settings should be extremely small. (I only implemented it in WebKit because it's simple to implement and it has relatively few dependencies on the rest of the engine.)

[jpamental]

I think that understanding now how the higher-level properties will 'clamp' (or have the ability to supply a value like '999' instead of 'heavy'), then with proper explanation I think it matters less in font-variation-settings.

But it does raise the point about how anyone would know what the possible value ranges are short of opening up the font file. Would it always be some number between 0 and 2, with 1 being the 'norm'?

[typemytype]

The higher level properties have only support for the predefined axes and named instances. There is no support for any other axis, so font-variation-settings must be used.

If so, I guess web designers will build javascripts to normalise those range values, maybe this is a missed opportunity.

Features and axis could be promoted by type foundries, but the axis ranges are something different.

[Crissov]

font-feature-settings is indeed similar to font-variation-settings – both are so low-level and specific to a particular font format that they should be used by authors as little as possible, better not at all. font-feature-alternates has the ability (or requirement) to assign custom (hopefully semantic) keywords to opaque numbers. Even if the numbers in variations are less arbitrary than in stylesets, for instance, it makes sense to follow the example set by @font-feature-values.

[litherum]

Variation fonts already have a way of "assign[ing] custom (hopefully semantic) keywords to opaque numbers," which is being discussed in #539.

Because font-variation-settings's goal is to give web authors access to uncommon axes in the font, the font's exported interface should be mirrored in the values of this property.

This discussion has now veered off of the original topic of font-variation-settings. If we wish to discuss a new CSS mechanism of assigning semantics to numbers, it should be done in a new issue. Because we are no longer discussing the original topic, I will close this issue. If you believe this to be an error, please reopen the issue.