Closed jfkthame closed 5 years ago
It would be unfortunate if descriptor defaults prevented variable fonts from being used in a simple and natural way without adding descriptors. Unfortunately the initial value for the font-weight
descriptor has always been normal
i.e. 400, so we can't change the initial value.
Other ways to address this:
@font-face {
font-family: MyVariableFont;
src: url(fonts/MyVar.ttf);
font-weight: 1 999;
}
allows any defined weight to be used (might have to be used with font-synthesis to prevent synthetic weights outside the range of weights supported by the variable font). Having to always specify the 1 999 is a pain though.
Another option, assuming the designer has examined the font and knows the supported range (or indeed, the range they wish to have used, which may not be the same):
@font-face {
font-family: MyVariableFont;
src: url(fonts/MyVar.ttf);
font-weight: 65 490;
}
and lastly, adding an auto
value which (for non-variable fonts) is the same as the initial value, and (for variable fonts) is the same as the range supported by the relevant axis for that font. So:
@font-face {
font-family: MyVariableFont;
src: url(fonts/MyVar.ttf);
font-weight: auto;
}
Could we change the initial value of the descriptor to the auto
value and make it mean normal
for non-variable fonts?
Oh and I guess another option is just to redefine what the initial value is, for variable fonts, so that the descriptors are only used when the designer wants to further restrict the range (kind of like unicode-range is used to further restrict the charmap).
@dbaron I believe we were having the same thoughts at the same time :)
This suggestion:
adding an auto value which (for non-variable fonts) is the same as the initial value, and (for variable fonts) is the same as the range supported by the relevant axis for that font. So:
@font-face {
font-family: MyVariableFont;
src: url(fonts/MyVar.ttf);
font-weight: auto;
}
seems problematic to me, because if auto
means "the range supported by the 'wght' axis in the font", then the browser has to download and parse the resource before it can run the font matching algorithm and thus determine whether this face is needed at all.
I've created a testcase for behavior of the font-weight
descriptor at https://jfkthame.github.io/variation-fonts/gingham.html, with screenshots (at the bottom of the page) to show how it renders in Safari, Chrome, and Edge.
AFAICS, none of the three renders as the spec currently requires, though Chrome comes nearest.
Your page suggests that Edge ignores font-weight descriptor. It is not ignored, it used for font matching. You can see WPT tests we submitted for relevant test cases. Thing that we don't do is clamping.
Descriptor play double purpose (font matching and clamping) and use cases may contradict each other. Font mapping looks more important to me than clamping. And proposed 'auto' value doesn't help here.
Clamping is fine detail of restricting actual allowed axis range. I can't imagine it used widely (on purpose)and preferred over font matching logic.
One more argument for me in favor of not doing clamping automatically is that following same logic of clamping values will prohibit browsers from applying bold or italic simulation it tons of existing pages. This looks like important breaking change to me.
If clamping scenario is considered important enough, it may deserve separate descriptor similar to font-synthesis.
Your page suggests that Edge ignores font-weight descriptor. It is not ignored, it used for font matching. You can see WPT tests we submitted for relevant test cases. Thing that we don't do is clamping.
Right; I should have explicitly noted that this testcase is specifically about clamping the used value of the property. I've clarified the note on the page.
As for whether clamping is important, and whether it should be handled by a separate descriptor rather than as the spec currently says, that all sounds like material for WG discussion. As things stand, there's a glaring lack of interoperability between the shipping implementations, which is not a good situation.
As an author, the behaviour I expected when no font-weight
descriptor is supplied is for the variable font to be rendered at different weights when font-weight
is applied, not for it to be clamped to font-weight:auto
. The implication is that if no font-weight
property is specified for the element, then the default weight should be treated as if normal (400) had been specified. (As per Safari's rendering in jfkthame's test).
Conversely if a font-weight
descriptor is supplied, then I would expect clamping to be applied. At this point in time, I'm particularly thinking about this in terms of @font-face
rules which could include fallbacks for non-variable fonts. Clamping weights when the font-weight
descriptor is supplied provides a kind of consistency between variable and non-variable fonts in that regard.
I would expect the same logic to be applied to other descriptors too: authors include a descriptor in order to clamp (and for backwards compatibility with non-variable fonts). No descriptor, no clamping, and inherited properties are applied.
Yeah, @SergeyMalkin’s explanation is totally correct. For the purpose of font selection, a missing descriptor will be used as if its default value was specified. However, once a font has been selected, and it’s time for the browser to apply variation values, a missing descriptor means “don’t clamp.” You’re right that the spec didn’t describe this, and the reason I implemented it this way is because of @svgeesus’s comment about omission of descriptors disabling variations (and that it’s unfortunate).
This is almost certainly what authors want (as @clagnut describes) and is easy to implement and spec.
Just in case I'm way off, I thought it worthwhile showing how I would go about providing fallback for non-variable fonts as it stands:
@font-face {
font-family: 'SourceSans';
src: url('source-sans-variable.woff2') format("woff2" requires variations),
url('source-sans-regular.woff2') format('woff2');
font-weight: 400;
}
@font-face {
font-family: 'SourceSans';
src: url('source-sans-variable.woff2') format("woff2" requires variations),
url('source-sans-black.woff2') format('woff2');
font-weight: 900;
}
So in the above example the variable font should be clamped to 400 and 900 weights. But what should happen if I were to append the following rule?
@font-face {
font-family: 'SourceSans';
src: url('source-sans-variable.woff2') format("woff2" requires variations);
}
I think I would expect it to release the clamps. But then if I prepended that rule instead, I think I'd expect the clamps to apply. It's possible I'm missing something about how @font-face rules cascade and override each other.
So in the above example the variable font should be clamped to 400 and 900 weights.
What exactly do you mean by this? As I understand it, in your example the variable font will be used only at weights 400 and 900, providing two distinct faces that correspond to the non-variable Regular and Black; it will not be used at intermediate weights. So you have two faces, each of which is "clamped" to a single weight. Was that your intention?
If you wanted the variable font's rendering to provide a range of weights from 400 to 900, you should use something like
@font-face {
font-family: 'SourceSans';
src: url('source-sans-variable.woff2') format("woff2" requires variations);
font-weight: 400 900;
}
Adding your no-weight-descriptor rule provides a face that (in the Apple/Microsoft interpretation) is considered to have weight 400 for font-selection purposes, but for rendering will use whatever range of weights the variable font actually supports. (But in the Chrome interpretation -- a more precise reading of the current spec text, AIUI -- this rule is equivalent to the one with font-weight: 400
.)
(Oh, and this "requires variations"... something like that has been discussed, I know, but it's not spec'd yet, is it? According to the current text, it's format("woff2-variations")
.)
So you have two faces, each of which is "clamped" to a single weight. Was that your intention?
Correct, although the two faces are actually the same font file for a browser supporting font variations.
"requires variations"... something like that has been discussed, I know, but it's not spec'd yet, is it?
No, not yet, but seems to be the prevailing thinking which is why I used it in the example.
The Working Group just discussed font property descriptors for variable fonts
, and agreed to the following resolutions:
RESOLVED: Add an auto keyword to the appropriate font descriptors that has the effect of the following: 1) for font selection purposes the font is selected as if the appropriate initial value is chosen. 2) for variation axis clamping, clamping does not occur
There's also the point that we want the spec to provide authoring advice that suggests authors put the real range and not use auto
. (And never explicit auto
.)
"appropriate" in that resolution means these three descriptors: weight, style, stretch
There's also the point that we want the spec to provide authoring advice that suggests authors put the real range and not use auto. (And never explicit auto.)
Just wondering, why "never explicit auto
"? And if that should never be used, do we actually need an auto
keyword here at all, when this case can just be represented by the absence of the descriptor?
Your comment, @jfkthame, is the logic I had when implementing this. It’s what I argued for during the discussing in the CSSWG.
authoring advice that suggests authors put the real range
I'm unclear what the purpose or advantage of this would be (I'm happy to learn what I've missed - undesirable synthesis perhaps?).
They way I'd think as an author is that if I wanted the whole weight axis to be available I'd probably just stick in font-weight: 1 999
and be done with it (or leave the descriptor out altogether). This would save me trying to find out that the range in the font is actually 234-845. Yes there's sites such as Axis-Praxis which expose this info easily, and maybe font documentation too, but I'm fundamentally lazy so if I don't need to do it...
@jfkthame does https://github.com/w3c/csswg-drafts/commit/9a6e7049b9f096a2551af0ee546241da28433c99 satisfy your comment, or it there more to add?
I think we also want to change the initial values of these descriptors from 'normal' to 'auto', don't we?
On 22/10/2018 10:57, Chris Lilley wrote:
@jfkthame https://github.com/jfkthame does 9a6e704 https://github.com/w3c/csswg-drafts/commit/9a6e7049b9f096a2551af0ee546241da28433c99 satisfy your comment, or it there more to add?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/csswg-drafts/issues/2485#issuecomment-431781444, or mute the thread https://github.com/notifications/unsubscribe-auth/ABoKA4cBx4OrLqP5QexioKVfKWJSfUHIks5unZaRgaJpZM4TAr4G.
I remember that we discussed doing so, I wasn't sure if we had agreed to it. But re-reading this issue yes, we do so I have more edits to do.
Re: https://drafts.csswg.org/css-fonts-4/#font-prop-desc
According to my reading of the current spec text, in particular:
it seems that a "naïve"
@font-face
rule such as:will result in a face that has a font-weight/stretch/style of
normal
, and will not use variations to implement rendering for other values of these properties. (It might use synthetic bolding and/or obliquing, just like any other non-variable font face.)This is what Chrome currently implements, AFAICT.
However, it's not what Safari implements; if MyVar.ttf in the above declaration has a 'wght' axis, my understanding (from a colleague's testing) is that Safari will use this to render arbitrary values of the font-weight property. Only if the
@font-face
rule includes an explicitfont-weight
descriptor will it clamp the variation values applied by thefont-weight
property to that range.ISTM that the Safari behavior is perhaps more author-friendly, but it conflicts with the spec text as it currently stands, and I'm not sure if it makes the interaction of
@font-face
descriptors with font selection (as opposed to rendering) trickier to understand/define?So should this be considered a Safari bug (and will it be fixed to conform to the spec?), or should the spec be revised?
A further question: where the spec says
does this clamping apply to values specified with
font-feature-settings
, or only to values specified in the higher-level properties that correspond to these descriptors? On the face of it, I would understand the spec text to mean that all variation values for the axis corresponding to such a descriptor are clamped (regardless of whether they're specified infont-feature-settings
or as a higher-level property likefont-weight
); but that does not appear to be the behavior of any current browser (and I'm not sure it would actually be desirable).