[css-fonts-5] Add "font-synthesis: super"

faceless2 commented 2 years ago

CSS fonts 4 has this:

Because of the semantic nature of subscripts and superscripts, when the value is either sub or super for a given contiguous run of text, if a variant glyph is not available for all the characters in the run, simulated glyphs should be synthesized for all characters using reduced forms of the glyphs that would be used without this feature applied.

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 uses font-size and vertical-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.

.call {
    font-size: 0.7em;
    vertical-align: super;
}
@supports (font-synthesis: super) {
    .call {
        font-size: inherit;
        vertical-align: inherit;
        font-variant-position: super;
    }
}

Technically it applies to subscript too, so could be font-synthesis: position?

dbaron commented 1 year 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.

svgeesus commented 1 year ago

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 ]

svgeesus commented 1 year ago

Also just for the record, pointing out that it says is allowed not is required. Same as font-synthesis-weight and so forth.

svgeesus commented 1 year ago

@jfkthame @litherum @drott looking for positive signals on adding this

drott commented 1 year ago

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?

svgeesus commented 1 year ago

Yes, I believe so (because of the issue with missing sub/super glyph forms, and with nesting)
I pointed out earlier the problem that allowed does not mean required. So it is not possible to test, using @support, if it will happen. or to guarantee that it won't. It should be.

drott commented 1 year ago

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.

svgeesus commented 1 year ago

Should be possible to test

frivoal commented 1 year ago

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.

css-meeting-bot commented 1 year ago

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)

The full IRC log of that discussion

<fantasai> Topic: font-synthesis: super
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7441
<fantasai> astearns: jfkthame, can you take this one?
<fantasai> jfkthame: I agree there's a problem here, but unsure whta exactly is being proposed as a way forward
<fantasai> jfkthame: crux seems to be that it's not possible to tell whether superscript/subscript glyphs will be synthesized or not if unavailable
<fantasai> jfkthame: adding 'font-synthesis-position' doesn't solve the real problem here
<fantasai> fantasai: can you outline the problem?
<fantasai> jfkthame: font-variant-position is supposed to apply superscript/subscript font features if available
<fantasai> jfkthame: spec suggests that a browser may synthesize reduced+shifted glyphs if the OT feature doesn't actually support the characters that are present
<fantasai> jfkthame: a lot of fonts only have support for a small minority of characters
<fantasai> jfkthame: but whether the browser will or won't do synthesis is left up to the implementation
<fantasai> jfkthame: which means authors can't use font-variant-position because you won't know if it has an effect or not
<astearns> ack dbaron
<fantasai> dbaron: I think maybe the idea I was thinking at the time was, if we had font-synthesis-position
<fantasai> dbaron: then an engine that supported synthesis would support that value of font-synthesis
<fantasai> dbaron: and therefore you could use @supports to detect whether synthesis was supported
<fantasai> dbaron: whereas engine that didn't support synthesis of super/subscripts wouldn't support that value of font-synthesis because nothing to control
<fantasai> dbaron: since synthesis wasn't supported in the first place
<fantasai> dbaron: that way you can use @supports queries to detect synthesis support for font-variant
<fantasai> dbaron: through the addition of a font-synthesis value that controlled it
<florian> q+
<fantasai> This makes sense to me, fwiw.
<fantasai> astearns: So if you're using super/subscript for semantic purposes
<fantasai> astearns: you could check whether font-synthesis-position is supported
<fantasai> astearns: and know that it's OK to use it, because there will be fallback synthesis that will preserve semantics
<fantasai> astearns: but if not there, you know that you need to fiddle with the glyphs yourself to make sure the semantic meaning is preserved
<astearns> ack florian
<fantasai> florian: Minor related point, for this proposal of dbaron's to be reliable
<fantasai> florian: we need a tweak to the text
<fantasai> florian: currently we say that the browser "should" synthesize, we need to take it to "must"
<fantasai> florian: can't allow a UA to do it *sometimes*
<fantasai> florian: but I support dbaron's proposal
<fantasai> dbaron: it doesn't help for engines that already support synthesis but don't support the new value
<fantasai> dbaron: e.g. Gecko already does the synthesis, can't detect it right now
<fantasai> dbaron: but Gecko could implement this, which would make synthesis detectable
<fantasai> astearns: jfkthame, thoughts?
<fantasai> jfkthame: I think that seems reasonable
<fantasai> jfkthame: I think it would be nice to see a proposed spec wording
<fantasai> jfkthame: to make it explicit as to what happens
<fantasai> jfkthame: but I don't have any problem in principle with this way forward
<fantasai> -> https://github.com/w3c/csswg-drafts/issues/7441#issuecomment-1444461111
<TabAtkins> fantasai: I don't htink the specific wording is that complex
<astearns> ack fantasai
<TabAtkins> fantasai: Chris outlined the exact text we'd add
<TabAtkins> fantasai: The only thing we need ot make clear is if we support this property, you *will* perform synthesis for font-variant-position when it's needed. You don't have the option to not do it.
<TabAtkins> fantasai: Taht's all we need to add to make this work.
<emilio> fantasai: we'd add another prop and another value to the shorthand, and UAs must support it
<emilio> ... if they implement that prop
<fantasai> florian: Given backlog of edits, I think we can resolve on it, and if anyone is unhappy they can say so before the edit lands
<fantasai> astearns: Does that work?
<fantasai> jfkthame: sounds fine
<fantasai> jfkthame: main change in Chris's comment, 'auto' value means synthesis is *allowed* and instead we'd say is *required* if glyphs are missing
<fantasai> astearns: so playing out the future where we have an engine that does super/subscript synthesis now
<fantasai> astearns: decides they don't want to do synthesis anymore, they drop the property?
<fantasai> florian: yes
<fantasai> chrishtr: so spec would require synthesis
<fantasai> chrishtr: so chrome would no longer be spec compliant?
<fantasai> fantasai: No, you're mixing up font-variant-position and font-synthesis-position
<fantasai> chrishtr: so new thing to solve this issue
<fantasai> dbaron: we define the property so that it's not mandatory to implement, but if you implement has to correspond to this other feature
<fantasai> florian: nothing's ever mandatory in CSS, but if you implement `font-synthesis-position`, you must implement font synthesis
<fantasai> chrishtr: did drott's comments get answered in the issue?
<fantasai> astearns: ...
<fantasai> chrishtr: only applies to font-variant-position?
<fantasai> florian: UA stylesheet uses different things to simulate superscripts and subscripts, so conceptually related but technically not
<fantasai> florian: you can override that in CSS, but unless you do that, not relevant
<fantasai> chrishtr: Second question was about feature detection
<fantasai> fantasai: we're enabling feature detection by adding this property
<fantasai> @supports (font-synthesis: position) { ... do stuff with font-variant-position here ... }
<fantasai> chrishtr: so if we resolve to add this, then Gecko because they do synthesis, they ship this property
<fantasai> chrishtr: then developers would be able to reliably condition use of font-variant-position on support for font-synthesis-position
<fantasai> chrishtr: so can do it reliably or not
<fantasai> fantasai: yes, exactly
<fantasai> chrishtr: OK! seems fine to me, thanks for walking me through it
<fantasai> astearns: proposed resolution is to accept Chris's formulation of font-synthesis-position, but make it so that 'auto' forces synthesis intead of making it allowed
<fantasai> chrishtr: that would resolve Florian's comment at the end of the issue?
<fantasai> florian: correct
<fantasai> astearns: you're looking to preserve meaning, so you know that the syntax will be reliable
<fantasai> s/syntax/feature/
<fantasai> astearns: OK, any objection to proposed resolution?
<fantasai> 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)
<fantasai> astearns: Anything else on this one?

jfkthame commented 1 year ago

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.)

drott commented 1 year ago

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

w3c / csswg-drafts

[css-fonts-5] Add "font-synthesis: super" #7441