- From: John Daggett <jdaggett@mozilla.com>
- Date: Tue, 30 Jul 2013 19:24:06 -0700 (PDT)
- To: www-style@w3.org
fantasai wrote:
> The CSS3 Fonts spec <http://www.w3.org/TR/2013/WD-css-fonts-3-20130711/#feature-precedence>
> specifies the following order of precedence for font features:
>
> 1. font-variant descriptor (@font-face)
> 2. font-feature-settings descriptor (@font-face)
> 3. Special Rules (like 'letter-spacing')
> 4. font-variant property
> 5. font-feature-settings descriptor
>
> This means that if an author requests ligatures for their document,
> e.g.
>
> html { font-variant: common-ligatures discretionary-ligatures }
>
> and then later uses tracking:
>
> em { letter-spacing: 1em }
>
> the element with tracking, depending on whether it ends up having
> text that triggers a ligature, will produce some very
> unevenly-spaced text. E.g.
>
> fi n d vs. f i n d
>
> Depending on exactly what fonts and exactly what sample text the
> author is looking at when designing the site, they may or may not
> see the problem compared to the actual production site (which
> potentially shows off user-generated content!).
I think you need to step back here and ask what the intent of the
author was in writing these styles. Did they want letter spacing
*and* ligatures? Things like common ligatures (e.g. the 'fi' ligature)
are on by default, there's no need to enable them for an entire
document. And enabling discretionary ligatures for an entire document
is dodgy at best. Normal behavior is that ligatures appear in text
unless it is letter spaced, by setting those styles an author is
explicitly saying they really want ligatures *and* non-zero letter
spacing.
> It seems to me that maybe, it would make more sense to put the
> Special Rules section last. I think authors are best off being able
> to express their variant preferences without having to always
> consider bad interactions with other properties deeper in the
> document (possibly via styles introduced by another author). Because
> they won't consider those things.
These are not "special rules", item (3) in the feature precedence list
[1] is simply features that are explicitly enabled/disabled by other
CSS properties, like letter-spacing or with vertical text. The
'font-variant' properties and 'font-feature-settings' properties can
both be used to *override* those settings if desired. If (3) is moved
to the bottom of the list there's no ability to override this and I
think that's a poor choice.
Like all of CSS there are particular combinations that authors can use
to shoot themselves in the foot. But I think it's a poor idea to
design functionality by focusing on how edge cases behave. It's
better to focus on a simple, understandable model for authors. Having
'font-variant' and 'font-feature-settings' be the final arbiter of
which features are enabled/disabled is simple and easy for authors to
understand. There's a similar issue with the way
'text-combine-horizontal' is specified to interact with font features. [2]
> Also, I think it's best that the font-variant descriptor and
> font-variant property behave as similarly as possible.
Um, they do *behave* the same way, identical descriptor and property
values enable/disable the same underlying font features. The use case
for the 'font-variant' and 'font-feature-settings' *descriptors* is
different, they are used for setting defaults with a specific font.
The *properties* are used for stylizing specific elements and should
always override the defaults.
[1] Font feature precedence
http://dev.w3.org/csswg/css-fonts/#feature-precedence
[2] Issue of text-combine-horizontal and font features
http://www.w3.org/Style/CSS/Tracker/issues/342
http://lists.w3.org/Archives/Public/www-style/2013Jul/0411.html
Received on Wednesday, 31 July 2013 02:24:33 UTC