Closed faceless2 closed 11 months ago
I definitely agree that one of the underlying issues you raise here -- that font-variant-position
is hard to use if some engines support synthesis, some don't, and support for synthesis isn't detectable -- is a serious one. It came up in the Chromium intent to ship font-variant-position
. Adding something like font-synthesis: super
does seem like one possible way to fix that.
Calling it font-synthesis-position
seems to fit better with font-variant-position
.
So, just sketching out what this might look like:
Name: | font-synthesis-position |
Value: | auto | none |
Initial: | auto |
Applies to: | all elements and text |
Inherited: | yes |
Percentages: | N/A |
Computed value: | specified keyword |
Canonical order: | per grammar |
Animation type: | discrete |
Media: | visual |
This property controls whether user agents are allowed to synthesize superscript and subscript glyphs when a font lacks them.
auto Synthesis of superscript and subscript forms is allowed none Synthesis of superscript and subscript forms is not allowed
Also, this would be added to the font-synthesis
shorthand with values
none | [ weight || style || small-caps || position ]
Also just for the record, pointing out that it says is allowed not is required. Same as font-synthesis-weight
and so forth.
@jfkthame @litherum @drott looking for positive signals on adding this
I agree with @dbaron that lack of feature detection is a problem for use of font-variation-position
. I admit I am mainly looking at it from the perspective of how to make it more useful without automatic synthesis - as experience with bold and italic synthesis shows that these have often caused undesirable effects or have hidden issues with correct usage of @font-face (aside from being complex to implement).
Two questions:
1) Is the proposal here for font-synthesis-position
to only affect synthesis behavior in font-variant-position
? If so, let's clarify that. (vs. synthesis behavior for <sub>
, <sup>
- which I interpret to be unrelated from this proposed property.
2) As the two proposed values are only auto | none
, what would be the canonical and reliable way to feature-detect that there is no synthesis for font-variant-position? Would !CSS.supports('font-synthesis-position', 'auto')
mean that, or how would we reliably encode that? Or would it need to mean a UA not supporting synthesis for font-variant-position should better not implement this property altogether?
@support
, if it will happen. or to guarantee that it won't. It should be.It should be.
What do you mean ? It should be happening, or it should be possible to test?
Yes, it can't be guaranteed that synthesis will be used by testing for positive support. But it would be useful if there was a way to identify that the UA has no support for synthesis, so it's not going to be there whichever way. Then the stylesheet could ensure that a font with the respective OpenType features is used, or otherwise vertical-align
is used, for example.
Should be possible to test
pointing out that it says is allowed not is required. Same as font-synthesis-weight and so forth.
That's quite problematic in this case, because the whole point here would be to detect if super/sub glyphs are guaranteed to be used or not.
Why is is allowed rather than required?
If this is because you should either get it from the font if available or synthesize, rather than always synthesize, then we should say that explicitly, because in that case, doing neither isn't actually intended.
Or we we actually mean that it's ok with the auto
value to neither get it from the font nor synthesize? I don't see why that would be useful.
The CSS Working Group just discussed font-synthesis: super
, and agreed to the following:
RESOLVED: Add font-synthesis-position as defined in https://github.com/w3c/csswg-drafts/issues/7441#issuecomment-1444461111 except 'auto' means synthesis is required (not merely allowed)
Just FTR, I noticed when re-reading the spec for font-variant-position
that there is already text that requires:
In the case of OpenType fonts that lack subscript or superscript glyphs for a given character, user agents must synthesize appropriate subscript and superscript glyphs.
which means the existing implementations that don't synthesis are actually non-compliant.
(In Gecko bug https://bugzilla.mozilla.org/show_bug.cgi?id=1849010, I'm currently implementing font-synthesis-position
, and as part of adding tests for that, I'll include a test to verify that UAs do synthesis when required.)
Also FTR, the "Status of the Specification" section of the specification lists synthesis in font-variant-position as "at-risk". https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position:~:text=The%20following%20features,variant%2Dposition%20property
CSS fonts 4 has this:
Which is nice, but it's currently implemented in Gecko only. The spec also marks this as "at risk".
This means
font-variant-position
is a bit useless - as it may or may not generate superscript, everyone just usesfont-size
andvertical-align
instead which is guaranteed to work cross-browser, even if it's not as nice typographically.Ideally all platforms would implement it, but an alternative would be: add
font-synthesis: super
to control whether this substitution takes place, and have it set by default. My presumption is this would be pretty easy to implement.More useful than turning it off is checking for whether it's supported. This would make
font-variant-position
safe to use in a cross-browser way.Technically it applies to subscript too, so could be
font-synthesis: position
?