[css-fonts-4] Should the OpenType spec dictate the acceptable values for variable font CSS properties?

[drott]

In the "Matching Font Styles algorithm", for style matching, the algorithm is defined to perform this first step:

If the matching set includes faces with italic values containing the mapped value of italic, faces, then faces with italic values which do not include the desired italic mapped value are removed from the matching set.

What does

mapped value of italic

mean in this case?

Then the algorithm talks about searching along the italic axis:

Otherwise, italic values above the desired italic value are checked in ascending order followed by italic values below the desired italic value, until 0 is hit. Only positive values of italic values are checked in this stage.

However, as far as I read it, the font-style property, as well as the font-style property descriptor do not allow specifying an italic axis range, or an arbitrary italic value between 0 and 1 on the italic axis.

The grammar for the font-style property descriptor is

normal | italic | oblique [ <angle> | <angle> <angle> ] ?

And if I interpret the grammar right, something like
font-style: italic 0.5 0.7;
would be invalid.

In order to define italic ranges, shouldn't this be:

normal | italic [ <italic_amount> | <italic_amount> <italic_amount> ]? | oblique [ <angle> | <angle> <angle> ]?

Similarly, currently the font-style property's grammar is:

normal | italic | oblique <angle>?

But shouldn't this be:

normal | italic <italic_amount>? | oblique <angle>?

to be consistent with the stretch matching part of the algorithm?

CC @litherum, @PeterCon

[litherum]

There are many questions here. I will try to separate my answers for each piece.

mapped value of italic

font-style: italic always maps to an italic value of 1.

Preinstalled fonts may define that they support the ital axis from 1.2 - 1.5, or from 0.3 - 0.54, which means the search for 1 still needs to occur. This is not describable with @font-face, and so will only occur with preinstalled fonts.

We discussed (in a GitHub issue) the idea about allowing "italic" to accept a number, but I can't find the conversation where we decided against it. The general feeling was that none of us has currently encountered any fonts which have a meaningful concept of "half italics" or "150% italics", so the syntax should be kept simple for now. We can extend it later if there ever is a desire to generalize.

[svgeesus]

Yeah, a face is either in an italic style or it isn't. But oblique faces of a variable font could easily use an oblique angle axis.

[drott]

There are many questions here. I will try to separate my answers for each piece.

Myles, thanks for taking a look and your explanations.

mapped value of italic

font-style: italic always maps to an italic value of 1.

Okay.

Preinstalled fonts may define that they support the ital axis from 1.2 - 1.5, or from 0.3 - 0.54, which means the search for 1 still needs to occur. This is not describable with @font-face, and so will only occur with preinstalled fonts.

It may be a bit of a theoretical exploration, since we haven't yet seen fonts which scale on the 'ital' axis, but the OpenType fvar section at least describes the ital axis to scale between 0 and 1.

According to the registered 'ital' axis definition their axis values must be in the range of 0 to 1, so I believe only the 0.3 - 0.54 example may appear, the 1.2-1.5 should/must not according to OpenType and font with axis range starting from below zero or extending above 1 would violate the ital axis range definition. So I suggest we drop the part of searching the ital axis above 1 in ascending order, or simplify how this is phrased. But I may have missed an earlier discussion on why the search outside the valid range is added here.

So

2. Otherwise, italic values above the desired italic value are checked in ascending order followed by italic values below the desired italic value, until 0 is hit. Only positive values of italic values are checked in this stage.

would become

2. Otherwise, italic values below the desired italic value are checked in descending until 0 is hit.

and

3. If no match is found, oblique values greater than or equal to 20deg are checked in ascending order followed by oblique values below 20deg in descending order, until 0 is hit. Only positive values of oblique values are checked in this stage.

would become

3. If no match is found, oblique values greater than or equal to 20deg are checked in ascending order followed by oblique values below 20deg in descending order.

plus dropping steps 4. and 5. What do you and others think?

Perhaps it would help to add a note explaining what you explained here: That the search along the ital axis only is only performed among the preinstalled fonts, and is currently not applicable to @font-face defined fonts.

Again, thanks for your explanations.

[litherum]

I don't think we should limit the search range due to what is listed in the OpenType spec, because variation fonts don't have to be OpenType fonts. AAT fonts support variations.

[PeterConstable]

I wouldn't want to see AAT vs OT font wars as history tells us that competing font formats only hinders adoption. The AAT spec for variations has been defined for a long time, but never took off. A key goal for OT variations was cross-platform implementation and interoperability, which will help foster development of fonts. If we start accommodating non-OT variable fonts, that will only lead to lack of interoperability and confusion.

[litherum]

But the spec already accommodates non-OT variable fonts. In fact, my initial implementation in WebKit only worked with AAT variable fonts.

[PeterConstable]

Prior to the extensions added in CSS Fonts Level 4, in what way did the CSS Fonts spec accommodate non-OT variable fonts? (I can't think of any way.) Your initial implementation isn't a prior precedent.

[PeterConstable]

Note that the axis ranges of AAT variable fonts are undefined and hence non-interoperable. That was the reason for this significant change when adding variations in OT.

For example, suppose I want to use Skia in a font-family chain, but also want to specify a particular weight:

font-family: "Avenir Next Variable", Skia;
font-weight: 550;

What am I going to get if Skia gets used? Maybe Safari has a deterministic answer, but no other browser has a way of knowing what that would be, and may have a different answer. Hence, it's completely unpredictable from a user POV.

Axis ranges in AAT variable fonts have no interoperability story. They can only be treated like custom (non-registered) axes, in spite of the fact that AAT recognizes some of the registered axis. The only way I can see to make AAT variable fonts work with CSS would be to specify in the spec that, given a non-OT variable font (recognizable by presence of 'fvar' but without a 'STAT' table), all axes must be treated like custom axes, meaning that the can be set using font-variation-settings but cannot be associated with the font-weight, font-stretch and font-style properties, and so cannot be referenced in font selection.

[fantasai]

Just to chime in on the OT vs AAT bit... the CSS specs try to be format-neutral insofar as possible, to define things in a way that's general enough that other font formats can be accommodated. We often have more information on how to work with OT fonts, so they are somewhat better described in the specs, but when possible the specs are written generally enough to accommodate other formats.

[PeterCon]

I get that point. But a primary goal for Web technologies is also interoperability. In other respects, AAT fonts work the same as OT fonts. But this is a specific point on which AAT fonts are non-interoperable.

Please explain what is expected in the example I gave above, given that the weight range for Skia goes from 0.5 to 3.2? Or another AAT font that might have a weight range from -100 to +17.5?