Intend to Implement and Ship: Font-Variant-Caps

[Dominik Röttsches]

Contact emails

dr...@chromium.org

Spec

https://drafts.csswg.org/css-fonts/#font-variant-caps-prop

Summary

Our implementation of CSS Fonts Module Level 3 has gaps, we're stuck in a mix of CSS 2.1 with some support for font-variant-ligatures of CSS Fonts Module Level 3. Font-feature-settings is working, but most of the OpenType font feature selection through CSS value keywords is not implemented. 

My plan is to bring Blink up to date with CSS Fonts Module Level 3 in several steps: Starting with font-variant-caps and fixing parsing and returning correct values for the the font-variant shorthand. Then probably addressing font-variant-numeric next.

The small-caps activated through font: or font-variant: were also always synthesised in our implementation and not activating OpenType features correctly, this will be addressed along the way.

Motivation

Using the CSS keywords for feature selection is at candidate recommendation status in the CSS Fonts Module level 3 and is the spec recommended way to activate common features:

"Authors should generally use ‘font-variant’ and its related subproperties whenever possible and only use this property for special cases where its use is the only way of accessing a particular infrequently used font feature."

Signals from content developers and font foundries indicate that the CSS font-variant-* value keywords are easier to work with and less cryptic than font-feature settings. In the case of font-variant-caps, there is also additional fallback/synthesis semantics for fonts that do not have this feature. 

Interoperability and Compatibility Risk

Safari Nightlies and Developer Preview version and Firefox since 34 are shipping the feature.

Edge seems to ship only the low level font-feature-settings selection, but not the keyword implementations.

In my opinion the compatibility risk is low. The spec takes care of resolving some ambiguities between the font-variant: CSS 2.1 settings and and the newer syntax. (See the syntax for font-variant-css21 in the font property shorthand.)

One important step during the implementation is to synchronize the font-variant values coming from the font: shorthand to be reflected in the font-variant-caps value, but the spec has provisions for backwards compatibility in this case which I plan to follow.

Wherever possible, on Mac these font-variant-* keywords are mapped from OpenType features to the respective features of AAT fonts as good as possible. However, this is outside the scope of Blink and mainly done by our HarfBuzz text shaping library.

Ongoing technical constraints

None

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

Yes

Debuggability

Debuggable as usual through the CSS properties inspection panel, where values are autocompleted and can be toggled.

OWP launch tracking bug

crbug.com/587094

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5764191470223360

Requesting approval to ship?

Yes

[PhistucK]

Can you check with Edge regarding their plans? Perhaps try adding the feature to their platform status page?

☆PhistucK

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

[Dominik Röttsches]

On Tue, Feb 16, 2016 at 4:35 PM, PhistucK <phis...@gmail.com> wrote:

Can you check with Edge regarding their plans? Perhaps try adding the feature to their platform status page?

Currently, the closest match would be this item on uservoice - no public signal from MS:

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6514821-font-size-adjust-other-font-properties

[PhistucK]

Jacob, can you advise?

☆PhistucK

[Philip Jägenstedt]

It's nice how this is defined directly in terms of OpenType features and not some hand-wavy language that leaves a lot of room for interop issues.

Can this be seen purely as a nicer syntax for the font-feature-settings property, or does it also enable something that is currently not exposed at all?

P.S. I manually added this to bit.ly/blinkintents, the script is picky about the subject title and missed it.

--

[Dominik Röttsches]

Hi Phillip,

It's nice how this is defined directly in terms of OpenType features and not some hand-wavy language that leaves a lot of room for interop issues.

Can this be seen purely as a nicer syntax for the font-feature-settings property, or does it also enable something that is currently not exposed at all?

Generally selecting and combining features in the CSS inheritance hierarchy works better with the font-variant-* subproperties syntax, as specifying a new font-feature-settings value resets the OpenType features configuration that parent classes so far specified.

Some of them, like font-variant-numeric are rather simple mappings to OpenType feature activation. In the case of font-variant-caps, the spec also requires what the synthesis of small-caps, etc. should look like. In other words, when "smcp", "c2sc" are activated through font-feature-settings there is no synthesis of these features, but when specifying font-variant-caps: small-caps then there is. In addition, I would also say that the font-variant-* syntax for selecting alternates/swashes improves human-readability. 

 

P.S. I manually added this to bit.ly/blinkintents, the script is picky about the subject title and missed it. 

Thanks - do I need to ping the API Owners to revisit this? Or what's the best way to proceed?

Dominik

[Philip Jägenstedt]

On Mon, Feb 22, 2016 at 12:25 PM, Dominik Röttsches <dr...@google.com> wrote:

Hi Phillip,

It's nice how this is defined directly in terms of OpenType features and not some hand-wavy language that leaves a lot of room for interop issues.

Can this be seen purely as a nicer syntax for the font-feature-settings property, or does it also enable something that is currently not exposed at all?

Generally selecting and combining features in the CSS inheritance hierarchy works better with the font-variant-* subproperties syntax, as specifying a new font-feature-settings value resets the OpenType features configuration that parent classes so far specified.

Some of them, like font-variant-numeric are rather simple mappings to OpenType feature activation. In the case of font-variant-caps, the spec also requires what the synthesis of small-caps, etc. should look like. In other words, when "smcp", "c2sc" are activated through font-feature-settings there is no synthesis of these features, but when specifying font-variant-caps: small-caps then there is. In addition, I would also say that the font-variant-* syntax for selecting alternates/swashes improves human-readability. 

Ah, thanks, so in addition to being nicer to work with, there is a difference in behavior when it comes to synthesis.

This sounds very nice, LGTM1.

 

P.S. I manually added this to bit.ly/blinkintents, the script is picky about the subject title and missed it. 

Thanks - do I need to ping the API Owners to revisit this? Or what's the best way to proceed?

It should be included in the next "Last week in Blink intents", but if it isn't or this otherwise fails to get the attention it needs, poking some people off-list should work :)

Philip

[Dimitri Glazkov]

LGTM2.

:DG<

[Alex Russell]

LGTM3

On Monday, February 22, 2016 at 8:56:16 AM UTC-8, Dimitri Glazkov wrote:

LGTM2.

:DG<

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google