Intent to Ship: CSS font-variant-position property

[Munira Tursunova]

Contact emails

moo...@google.com, dr...@google.com

Explainer

https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position

Specification

https://drafts.csswg.org/css-fonts-4/#propdef-font-variant-position

Summary

The font-variant-position CSS property controls the use of alternate, smaller glyphs that are positioned as superscript or subscript.

Motivation

Font-variant-position property allows users to control usage of typographic superscript and subscript glyphs. 

Currently font-variant-position is implemented without synthesis functionality and affects only fonts that have superscript or subscript glyphs (“sups”/”subs” opentype feature); i.e. if the font doesn’t have superscript/subscript then setting font-variant-position to “super”/“sub” won’t synthesize superscript and subscript glyphs, therefore won’t change anything.

Subscript and superscript glyphs can be also activated using the font-feature-settings property, however using font-variant-position property might be more reasonable since it cascades like a regular CSS property and with the font-feature-settings, if the element inherits the “sups” or “subs” value, users need to activate/deactivate other features that were also defined in font-feature-settings of the parent element. 

Implementing the synthesis part would be complex and it is questionable if it is worth the cost since synthesized glyphs may look unnatural and synthesis of the font-variant-position property is at risk in the spec. Also Safari supports font-variant-position property without synthesis functionality as well.

This feature is implemented behind the ‘experimental’ flag and is part of Interop 2022. Shipping this feature will provide a higher stable score for Interop and will decrease the stable vs. experimental score difference.Since Chrome is the last browser to ship this, this will enable broader usage of the feature on the web.

Blink component

Blink>Fonts

Search tags

font-variant-position, subscript glyphs, superscript glyphs, sub, super

TAG review

Already shipped in other browsers, see below, no TAG review required.

TAG review status

Not applicable, existing standard, shipped in other UAs

Risks

Interoperability and Compatibility

Gecko: Shipped/Shipping

https://bugzilla.mozilla.org/show_bug.cgi?id=1024804 Gecko has implemented the feature with the synthesis functionality.

WebKit: Shipped/Shipping

https://bugs.webkit.org/show_bug.cgi?id=148413 WebKit has implemented the feature without the synthesis functionality.

Web developers: No signals

Other signals: -

Activation

None expected; Feature already implemented in other browsers.

Debuggability

Same as any other CSS property, css_properties.json will be rolled to DevTools during development.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes, following tests are testing property implementation:

https://wpt.fyi/results/css/css-fonts/font-variant-position.html

https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html

https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html

https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html

https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html

https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html

https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html

Flag name

FontVariantPosition

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1212668

Estimated milestones

No milestones specified

Anticipated spec changes

None expected

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5067180721307648

[Philip Jägenstedt]

I will recuse myself from this one since I have an interest in the success of Interop 2022 (and 2023), but I think shipping this makes sense. Chrome is the last browser to not support it at all, and we've seen with other features that the time it becomes available in all browsers can be an inflection point in usage.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com.

[Manuel Rego Casasnovas]

Is there a way to feature detect the synthesis functionality or not? How
a web author will be able to differentiate between Gecko vs
Chromium/WebKit behaviors? Would the lack of this feature confuse
authors? Maybe having some console message information when
font-variant-position doesn't have any effect due to missing synthesis
functionality, dunno if that makes sense.

Do we have an use counter for the cases where we're not using
synthesized glyphs due to lack of functionality? So we can track how
common is that situation and understand the priority of such feature in
the future.

Cheers,
Rego

On 14/02/2023 17:08, Philip Jägenstedt wrote:
> I will recuse myself from this one since I have an interest in the
> success of Interop 2022 (and 2023), but I think shipping this makes
> sense. Chrome is the last browser to not support it at all, and we've
> seen with other features that the time it becomes available in all
> browsers can be an inflection point in usage.
>
> On Tue, Feb 14, 2023 at 4:56 PM 'Munira Tursunova' via blink-dev

> <blin...@chromium.org <mailto:blin...@chromium.org>> wrote:
>
>
> Contact emails
>
> moo...@google.com <mailto:moo...@google.com>, dr...@google.com
> <mailto:dr...@google.com>
>
>
> Explainer
>
> https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position>

> <https://drafts.csswg.org/css-fonts-4/#:~:text=The%20following%20features,variant%2Dposition%20property>. Also Safari supports font-variant-position property without synthesis functionality as well.

>
> This feature is implemented behind the ‘experimental’ flag and is
> part of Interop 2022. Shipping this feature will provide a higher
> stable score for Interop and will decrease the stable vs.
> experimental score difference.Since Chrome is the last browser to
> ship this, this will enable broader usage of the feature on the web.
>
>
> Blink component
>
> Blink>Fonts

> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>
>
>
> Search tags
>
> font-variant-position
> <https://chromestatus.com/features#tags:font-variant-position>,
> subscript glyphs
> <https://chromestatus.com/features#tags:subscript%20glyphs>,
> superscript glyphs
> <https://chromestatus.com/features#tags:superscript%20glyphs>, sub
> <https://chromestatus.com/features#tags:sub>, super
> <https://chromestatus.com/features#tags:super>

> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

>
> Yes, following tests are testing property implementation:
>
> https://wpt.fyi/results/css/css-fonts/font-variant-position.html

> <https://wpt.fyi/results/css/css-fonts/font-variant-position.html>
>
> https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html>
>
> https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html>
>
> https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html>
>
> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html>
>
> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html>
>
> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html>

>
>
> Flag name
>
> FontVariantPosition
>
>
> Requires code in //chrome?
>
> False
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1212668
> <https://bugs.chromium.org/p/chromium/issues/detail?id=1212668>
>
>
> Estimated milestones
>
> No milestones specified
>
>
>
> Anticipated spec changes
>
> None expected
>
>
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5067180721307648
> <https://chromestatus.com/feature/5067180721307648>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Daniel Bratell]

I'm curious how this relates to the "old" way of doing superscript.

If I understand correctly (and I might not!), then

x<span style="font-variant-position: super">2</span>

will render as "x²", somehow finding the "super" variant of 2 in the font?

The old way of doing this would be with

x<span style="vertical-align: super; font-size: 0.83em">2</span>

which will use the normal glyph for 2, but smaller and differently
positioned?

/Daniel

[Munira Tursunova]

> Is there a way to feature detect the synthesis functionality or not? How
> a web author will be able to differentiate between Gecko vs
> Chromium/WebKit behaviors? Would the lack of this feature confuse
> authors? Maybe having some console message information when
> font-variant-position doesn't have any effect due to missing synthesis
> functionality, dunno if that makes sense.
> 
> Do we have an use counter for the cases where we're not using
> synthesized glyphs due to lack of functionality? So we can track how

> common that situation is and understand the priority of such feature in
> the future.

 

I’m not sure I completely understand your question, but I suppose identifying cases when the feature is requested and the font does not have subscript/superscript glyphs might not be possible since we perform the checking of the font features in the shaping stage in Harfbuzz and we check different fonts in the shaping process without knowing what font will be finally used in the page. So, for example, we can trigger on some system font that does not have sub/superscript glyphs (so this glyphs should be synthesised) however, in the end, this font won’t be used in the page but a different web font will be used instead.  

One of the ways to detect whether a font has super/subscript glyphs is to check whether the font with the feature has loaded (using document.fonts for instance) and if it did then we won’t synthesise.

> I'm curious how this relates to the "old" way of doing superscript. If I understand correctly (and I might not!), then x<span style="font-variant-position: super">2</span> will render as "x²", somehow finding > the "super" variant of 2 in the font? The old way of doing this would be with x<span style="vertical-align: super; font-size: 0.83em">2</span> which will use the normal glyph for 2, but smaller and differently > positioned?

Not exactly, vertical-align always does synthesis, so even if the font has subscript or superscript opentype features vertical-align would still synthesize the glyphs. The old way of activation superscript/subscript is through font-feature-settings, i.e. setting it to “sups” or ”subs”.  

[Manuel Rego Casasnovas]

On 21/02/2023 10:06, 'Munira Tursunova' via blink-dev wrote:
>> Is there a way to feature detect the synthesis functionality or not? How
>> a web author will be able to differentiate between Gecko vs
>> Chromium/WebKit behaviors? Would the lack of this feature confuse
>> authors? Maybe having some console message information when
>> font-variant-position doesn't have any effect due to missing synthesis
>> functionality, dunno if that makes sense.
>> 
>> Do we have an use counter for the cases where we're not using
>> synthesized glyphs due to lack of functionality? So we can track how

>> common that situation is and understand the priority of such feature in
>> the future.
>  
> I’m not sure I completely understand your question, but I suppose
> identifying cases when the feature is requested and the font does not
> have subscript/superscript glyphs might not be possible since we perform
> the checking of the font features in the shaping stage in Harfbuzz and
> we check different fonts in the shaping process without knowing what
> font will be finally used in the page. So, for example, we can trigger
> on some system font that does not have sub/superscript glyphs (so this
> glyphs should be synthesised) however, in the end, this font won’t be
> used in the page but a different web font will be used instead.  
>
> One of the ways to detect whether a font has super/subscript glyphs is
> to check whether the font with the feature has loaded (using
> document.fonts for instance) and if it did then we won’t synthesise.

Mmmm, I'm not sure if I'm understanding properly.

In the first email you wrote:
> Currently font-variant-position is implemented without synthesis
functionality and affects only fonts that have superscript or subscript
glyphs (“sups”/”subs” opentype feature); i.e. if the font doesn’t have
superscript/subscript then setting font-variant-position to
“super”/“sub” won’t synthesize superscript and subscript glyphs,
therefore won’t change anything.

I understood that if the font has super/subscript glyphs we'll use them,
but if the font doesn't have them, we won't synthesize them, so the user
will see no difference between a text with `font-variant-position:
normal;` vs `font-variant-position: super;`. Am I getting this wrong?

If I'm right, my question was how to feature detect if the browser is
synthesizing things or not. For example we have this:

x<span style="font-variant-position: super;">2</span>

In Firefox that will always look as "x²". In Chromium/WebKit I
understand that depending on the font it'll look as "x²" or "x2".
Is there any way the author can detect what's going on so they can use a
different method to do the superscript here?
Isn't this going to be confusing to web authors why this is not working
in Chromium, while working in Firefox? Are they going to be able to
understand this is because the selected font doesn't have the proper
glyphs (even when it's the same font in Firefox)?

I was wondering about this kind of things, but I'm not sure if I
understood properly the original message.

Cheers,
Rego

> https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position> <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position <https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-position>>

> <https://drafts.csswg.org/css-fonts-4/#:~:text=The%20following%20features,variant%2Dposition%20property <https://drafts.csswg.org/css-fonts-4/#:~:text=The%20following%20features,variant%2Dposition%20property>>. Also Safari supports font-variant-position property without synthesis functionality as well.

> >>
> >> This feature is implemented behind the ‘experimental’ flag and is
> >> part of Interop 2022. Shipping this feature will provide a higher
> >> stable score for Interop and will decrease the stable vs.
> >> experimental score difference.Since Chrome is the last browser to
> >> ship this, this will enable broader usage of the feature on the web.
> >>
> >>
> >> Blink component
> >>
> >> Blink>Fonts
> >>

> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EFonts>>

> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>>?

> >>
> >> Yes, following tests are testing property implementation:
> >>
> >> https://wpt.fyi/results/css/css-fonts/font-variant-position.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position.html>
> >> <https://wpt.fyi/results/css/css-fonts/font-variant-position.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position.html>>
> >>
> >>
> https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html>
> >>
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-01.html>>
> >>
> >>
> https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html>
> >>
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-02.html>>
> >>
> >>
> https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html>
> >>
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html
> <https://wpt.fyi/results/css/css-fonts/font-variant-position-03.html>>
> >>
> >>

> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html> <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-valid.html>>
> >>
> >>
> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html> <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-position-computed.html>>
> >>
> >>
> https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html> <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html <https://wpt.fyi/results/css/css-fonts/parsing/font-variant-valid.html>>

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_C-aHBXYr1mp%3DiJkTQEPgP-isxxv-u-Uv%3DyO4Mp9b_j5Q%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "blink-dev" group.
> >> To unsubscribe from this group and stop receiving emails from it,
> send
> >> an email to blink-dev+...@chromium.org
> >> <mailto:blink-dev+...@chromium.org>.
> >> To view this discussion on the web visit
> >>

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com?utm_medium=email&utm_source=footer <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcZ%2Br_RpUWL3Z8QKTYzF5WTG3nnZeaM3UbDwofYc9cu8g%40mail.gmail.com?utm_medium=email&utm_source=footer>>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org
> <mailto:blink-dev+...@chromium.org>.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bafec970-883b-45a2-9c93-fd8f8220e741n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bafec970-883b-45a2-9c93-fd8f8220e741n%40chromium.org?utm_medium=email&utm_source=footer>.

[Munira Tursunova]

Duplicating the summary of our conversation from the chat here.

We agreed that it might be confusing for some of the web authors if they don't check the font for the feature existence beforehand. Also implementing synthesis behaviour detection most probably is not possible since feature detection/activation happens in shaping stage in Harfbuzz where we check different fonts and we don't know which of the fonts will be finally used on the page at that point.

Thanks,

Munira

[Yoav Weiss]

The API owners discussed this at length in yesterday's meeting, without reaching concrete conclusions.

It seems to me that it'd be good to get some web developer signals here to get a better understanding of if and how they'd be able to use the feature, given the interop issues in case of fonts that don't have "super"/"sub" features.

I'm not sure what the right answer is (feature detection, synthesis of some kind, or something else entirely), but it seems to me that getting "x2" instead of "x<superscript 2>" or "x<subscript2>" would result in real semantic difference.

Do we know how developers are using that feature today, given the difference between Gecko and WebKit?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/eba52bce-1e12-48af-a867-bea424f7a1a2n%40chromium.org.

[David Baron]

A few notes on the history of this feature that relate to some of the questions asked:

When font-variant-position was being designed, the CSS Working Group had an extensive discussion (part 1, part 2) about trying to build a model where browsers could synthesize appropriate glyphs if the font didn't have special superscript or subscript glyphs, or only had special superscript/subscript glyphs for a subset of the characters that were superscripted/subscripted, in a way that would get the sizes and positions correct.  This proposal was abandoned primarily because of evidence that font metrics for super/subscript position and size (which the proposal depended on) are generally incorrect (e.g., as noted in those minutes, all Adobe fonts at the time shipped with the same metrics for superscript position and size), but also secondarily because of the complexity needed to make it work correctly.  (The underlying goal of that proposal was to make this property something that could be used for the default rendering of <sup>/<sub> elements.)

However, we ended up (and I don't remember the history of this part) with synthesis in the spec, though with a requirement that a single super/subscript is fully synthesized if it can't be fully rendered without synthesis.  The advantage of doing synthesis is that the semantics of super/subscript don't get lost, and thus using the feature doesn't require that the author fully control the fonts that are used (which authors perhaps think they can do with downloadable fonts, but which isn't always fully reliable).  But synthesis can certainly lead to bad results where neighboring superscripts/subscripts are inconsistent with each other, even though consistency is required within a single super/subscript.  This makes me think that the synthesis in the current model probably isn't high enough quality to be a default rendering of <sup>/<sub> elements, although the spec is very vague and thus I'm not sure one can say this authoritatively, and I don't know details of what Gecko implemented.

I don't think the specification was designed around the idea that some implementations would follow the spec's rules on synthesis and some implementations would ignore the spec... and thus it does appear to be a problem that whether an implementation does synthesis isn't detectable.  (This seems worth discussing in the CSS Working Group if it hasn't been already.)

As far as comparison to the "old way" of doing superscript/subscript:  there are (as discussed) two different "old ways".  The oldest way, and the way still used for <sup>/<sub> elements, and probably still the most common way, involves vertical-align and font-size: smaller.  This produces a result that is typographically incorrect:  it's just using body text shrunk to a smaller size, so the superscripts appear too "light" in comparison to the surrounding text.  There's also a newer "old way" that involves using the low level font-feature-settings property, whose use for this case is discouraged in the specification, though it produces the same typographically-correct results as font-variant-position, with all of the same disadvantages (plus a few more), including (if font-variant-position does have synthesis) the disadvantage that it might fail very badly when the font doesn't have the necessary glyphs.

-David

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfX3ZjLqXXO3XZWpLebMSFAaA15m6gvi0BA%3DfC1xU4KrXw%40mail.gmail.com.

[Manuel Rego Casasnovas]

Hi David,

Thanks for the amazing email!

On 23/02/2023 23:52, David Baron wrote:
> I don't think the specification was designed around the idea that some
> implementations would follow the spec's rules on synthesis and some
> implementations would ignore the spec... and thus it does appear to be a
> problem that whether an implementation does synthesis isn't detectable. 
> (This seems worth discussing in the CSS Working Group if it hasn't been
> already.)

There's a CSSWG issue about this topic in particular:
https://github.com/w3c/csswg-drafts/issues/7441

Cheers,
Rego

[Yoav Weiss]

Indeed, thanks David!!

Is this something that can be put on the agenda for the CSSWG to discuss?

Anecdotally, it seems like developers do expect synthesis to work, which echoes the CSSWG issue (filed by a developer AFAICT).

Cheers,
  Rego

[David Baron]

On Fri, Feb 24, 2023 at 5:49 AM Yoav Weiss <yoav...@chromium.org> wrote:

On Fri, Feb 24, 2023 at 11:27 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

There's a CSSWG issue about this topic in particular:
https://github.com/w3c/csswg-drafts/issues/7441

Is this something that can be put on the agenda for the CSSWG to discuss?

I added this to the group's (long) agenda backlog.

(Also, a few other relevant CSSWG issues I found were w3c/csswg-drafts#1888, w3c/csswg-drafts#2796, w3c/csswg-drafts#5225, w3c/csswg-drafts#5518, and also some minutes from July 2020 and from September 2020.)

 

One other point that I missed yesterday is that one of the key reasons that these new properties can't be used for the default rendering of <sup>/<sub> elements is that they don't support nested subscript/superscript.  One of the goals of the 2011 discussion I cited above was to solve that issue in a reasonable way.  All of the current ways of doing typographically correct super/subscripts only support a single level of super/subscript, and not nesting.  This works for the majority of use cases, but not all.

-David

[Rick Byers]

It's a shame to me to be holding back interop on the case of fonts having the superscript or subscript glyphs out of fear for the case where they don't. Perhaps we can treat the case of font-variant-position being used with fonts that lack the glyphs as a site bug that we can work to address independently? Personally, as long as Safari and Chrome behave the same here, I'm skeptical that the lack of synthesis would turn into a non-trivial problem in practice.

If we were to ship without synthesis, would it be practical to have a UseCounter which measures how often we see font-variant-position used with a font that lacks the glyphs? This would tell us how important the bug is. If it remains really rare, then IMHO we've probably already wasted more energy worrying about it than it's worth. If it becomes more common over time then I think we have a variety of options, chiefly implementing synthesis, but also raising awareness with devtools features, UKM-based site-specific outreach, and possibly even interventions of some form (like using a fallback font?). 

Rick

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG0MU3ht%3DrZwCtQoUWJXR4avCaY2TvAa9NMiYAfMsdan94wzVw%40mail.gmail.com.

[David Baron]

I think it's worth noting that lack of interop here could take two different forms: (1) different behavior in different browser engines and (2) different behavior on different machines in the same browser engine, because of different system font availability.  Some of the more advanced font capabilities in CSS mostly make sense only with downloadable fonts and not with system fonts -- and the choices we make regarding synthesis may affect whether this falls into that bucket of capabilities.

So if it makes sense to add use counters to understand the compatibility implications here, I think it may be worth adding what we would need to understand the breakdown of how many sites are using this in a way that (a) is interoperable across browsers/machines versus (b) is broken in some browsers and working on others versus (c) is broken on some machines and working on other machines, even using the same browser.  I suspect this would mean something like measuring how often we see font-variant-position used with a system font versus a downloadable font.  (This might also need to be recorded along with the data on whether the font has or lacks the superscript/subscript glyphs, because the intersection of the two might be interesting.)

-David

[Dominik Röttsches]

Hi David and Rick,

It's a shame to me to be holding back interop on the case of fonts having the superscript or subscript glyphs out of fear for the case where they don't. Perhaps we can treat the case of font-variant-position being used with fonts that lack the glyphs as a site bug that we can work to address independently? Personally, as long as Safari and Chrome behave the same here, I'm skeptical that the lack of synthesis would turn into a non-trivial problem in practice.

I think expectations as to what should the browser do vs. what is reasonably expected of site owners in terms of font selection and visual delivery is on a spectrum (font fallback being a similar case). 

In the case of using font-variant-position, I tend to agree with Rick: I'd consider using font-variant-position without a suitable font is a site bug. Safari seems to be of the same opinion by shipping font-variant-position without synthesis.

If we were to ship without synthesis, would it be practical to have a UseCounter which measures how often we see font-variant-position used with a font that lacks the glyphs? This would tell us how important the bug is. If it remains really rare, then IMHO we've probably already wasted more energy worrying about it than it's worth. If it becomes more common over time then I think we have a variety of options, chiefly implementing synthesis, but also raising awareness with devtools features, UKM-based site-specific outreach, and possibly even interventions of some form (like using a fallback font?).  

It's difficult to measure the visual end result accurately: 

Only at shaping time we know exactly which font binary is used. This in HarfBuzzShaper and we can determine whether the `sups` and `subs` OpenType features are requested (we would need extra code for determining whether these features were requested through font-variant-position: or font-feature-settings). Then we can determine whether the font has such a feature in its shaping tables. The difficulty is: We reach the shaping code lots of times for every relayout or web font arriving. So initially, we may shape with a fallback font before the web font arrives, which affects the measurement result. Measuring in shaping is not synchronized with a stable layout stage or something like a "done" state of the page. So we could get to an approximation, but in shaping we can't currently determine what's the last state that "stayed" and was perceived by the user.

David wrote:

So if it makes sense to add use counters to understand the compatibility implications here, I think it may be worth adding what we would need to understand the breakdown of how many sites are using this in a way that (a) is interoperable across browsers/machines versus (b) is broken in some browsers and working on others versus (c) is broken on some machines and working on other machines, even using the same browser.  I suspect this would mean something like measuring how often we see font-variant-position used with a system font versus a downloadable font.  (This might also need to be recorded along with the data on whether the font has or lacks the superscript/subscript glyphs, because the intersection of the two might be interesting.)

I do agree this feature is most meaningful in combination with web fonts. Or even more specifically: Selecting font-variant-position needs to be carefully synced with the selected font and making sure the exact font has high chances of getting loaded.

Do I understand correctly you suggest measuring font-variant-position usage with system fonts vs. web fonts because of the differences between machines? Or did you also mean platforms? 

The system font set used from the web is relatively stable between machines, meaning: Windows fonts are usually similar across machines (when it comes to those selected from the web), so are Mac fonts.

In any event, I did a quick check:

Mac: Helvetica, Times, and Courier New on Mac, and as far as I can tell, neither has a specific superscript or subscript OpenType or AAT font feature. 

Windows: Out of Arial, Courier, Times, Verdana only Verdana has subscript glyphs (no superscript), the others do not have such a feature. 

Bottom line: 

I am with Rick on shipping this and considering a lack of glyph support up a site bug. 

Depending on feedback from API owners, if needed, we can measure an approximation of selection of the feature vs. support in the font. 

As is, this measurement may read too high (see above: initial shaping with fallback font), but potentially we can filter that measurement and only report selection of the feature vs. support in a successfully loaded web-font. Development of such a measurement takes from 2 days to 9 days, depending on complexity (very basic, no distinction of font-feature-settings and font-variant-position, no distinction of system fonts to complex: distinguish font-feature-settings from font-variant-position, distinguish system fonts, web fonts). 

Dominik

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9fMAG16L3_KweN4FnnSnVsfevxHyH2qfdN1B42ef1Xmg%40mail.gmail.com.

[Rick Byers]

Thanks David, Dominik.

As API owners I think our job is largely about evaluating interop risk vs. platform benefit. It's hard for me to evaluate the benefit of this feature without synthesis (how big of a problem is webfont fallback in practice?). But it seems clear to me that adding this feature to Chrome matching Safari (but not Firefox) is a net reduction in interop risk compared to the status quo of all three browsers behaving differently due to Chrome's lack of support. So, while we could have all sorts of debate and discussion about what more to do, as-is this passes our I2S bar for me. 

LGTM1. Sorry for the long delay.

Rick

[David Baron]

I was trying to avoid being too specific about what would be worth measuring both because I haven't taken the time to think through all the details, and because other folks on this thread have a lot of domain expertise that can help figure out what makes sense.  I just wanted to point out that if you are measuring stuff, it's worth considering that it may be useful to measure something about usage of system versus downloaded fonts in order to understand variation between machines (which I agree is at least mostly variation between platforms).

-David

On Tue, May 30, 2023 at 11:44 AM Dominik Röttsches <dr...@google.com> wrote:

[Rick Byers]

Yes, 100%. Very good point, I was definitely over-simplifying the measurement challenge. Thanks David!

[Mike Taylor]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-SQGewKUSrL0MGTXh_L3DU_RSfah2t8SrS8K3FPaeR2g%40mail.gmail.com.

[Daniel Bratell]

LGTM3

/Daniel

[Munira Tursunova]

We decided to ship font-variant-position without adding a metric measuring whether the feature is applied against a correct font because of difficulties determining a stable document state at the shaping level, for details, see https://docs.google.com/document/d/1dYiljb9pJmWtEIulsse_jzxJwLh3F14Y_X6WbHfETXg/edit?usp=sharing&resourcekey=0-6TIx4OqLWmKBuzv3yR-qRA.

[Jonathan Kew]

Note that the CSS Fonts 4 spec requires the browser to synthesize appropriate scaled/shifted glyphs if the font does not provide them:

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

(see https://drafts.csswg.org/css-fonts-4/#font-variant-position-prop)

[Marcel Gerber]

I also think that synthesizing is a core feature of this CSS property:

Without synthesizing, the same functionality can also be achieved using plain `font-feature-settings`. Using `font-variant-position` is nicer, sure.

But what happens if the requested webfont cannot be loaded for whatever reason, and the page is rendered using a fallback system font, is very much something that the current Chrome implementation of `font-variant-position` doesn't solve in any way:

It will just render the text using normal glyphs, which is very confusing if they're supposed to be superset glyphs.

For example, go to the MDN font-variant-position page and look at the "Result" section in Chrome 117+: Even though the browser supports `font-variant-position` now, the text there is completely rendered using "normal" glyphs (assuming your system font doesn't have sup/sub glyphs) and there is not the slightest indication that the text is supposed to be in super/subscript.

A compromise that would work well in my eyes is to at least synthesize if we detect that the rendered font doesn't have any superscript/subscript glyphs at all. That might be easier to detect in OpenType fonts than checking for the existence of every single rendered glyph?