W3C home > Mailing lists > Public > www-style@w3.org > February 2012

Re: [css3-fonts] simplifying font-variant-ligatures

From: Christopher Slye <cslye@adobe.com>
Date: Wed, 22 Feb 2012 17:55:42 -0800
CC: www-style list <www-style@w3.org>
Message-ID: <52F5E5B1-A748-4A22-97FE-F8C1D536DB2F@adobe.com>
To: Christoph Päper <christoph.paeper@crissov.de>

On Feb 22, 2012, at 12:28 PM, Christoph Päper wrote:

> Christopher Slye (2012-02-18 02:13):
>> … the font attributes should convey features in high level, technology-agnostic terms, not with the lower level wiring of OpenType feature tags. The current draft follows this spirit well enough.
> 
> I still disagree. The current WD and ED has
> 
>            ‘common-ligatures’ ⇔ ‘liga’ := 1
>         ‘no-common-ligatures’ ⇔ ‘liga’ := 0
>     ‘discretionary-ligatures’ ⇔ ‘dlig’ := 1
>  ‘no-discretionary-ligatures’ ⇔ ‘dlig’ := 0
>        ‘historical-ligatures’ ⇔ ‘hlig’ := 1
>     ‘no-historical-ligatures’ ⇔ ‘hlig’ := 0
> 
> John Daggett wants to change it to
> 
>            ‘common-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 0, ‘hlig’ = 0
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = 0
>               ‘all-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = 1
> 
> and forgets, I guess, ‘none’ or ‘no-ligatures’. Other keywords for common combinations could be added (now or later). 

Laying-out the big matrix of variations doesn't make much of an impression on me. I don't see it as "more complexity," I see it as "better control." More important to me is what meaning the settings convey, and how often they would be used by most developers, most of the time.


> It probably merits discussion whether it should rather use default values like ‘normal’
> 
>            ‘common-ligatures’ ⇔ ‘liga’ := 1
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1
>               ‘all-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = 1
> 
>> I think it's better to pretend that font-feature-settings doesn't exist and design the primary attributes to include and control font features as they should ideally be.
> 
> I agree, but “font features” to be controlled in this context should be abstracted from Open Type, because OT features are all but perfect. They are neither designed in a coherent manner nor with authors in focus. CSS properties and values should be both.

By "all but perfect" I think you mean "far from perfect," not "nearly perfect" (which is how I would normally read it). We can probably agree the OT features are not perfect, but I find them reasonably coherent in design. Given that most UIs (e.g. InDesign) present many features 1:1 with a familiar name, I'd say they are fairly author-friendly. CSS need not be abstracted for the sake of abstraction; many features (e.g. 'onum') are fairly straightforward.


>> I prefer to think of font-feature-settings as a way to have access to OpenType features that are too obscure or specialized to have a place among the regular font attributes (…).
> 
> Yes, or for rare combinations of features.

I'm not sure I agree.


>> You're worried about the current syntax being verbose, but your example
>> seems unlikely because common-ligatures will be on by default,
> 
> Not necessarily: the initial value ‘normal’ relies on the default settings inside the font.

There is no such setting inside the font. Such conventions (e.g. 'liga' on by default) are recommended (imperfectly) by specification. The feature instructions are just there in the font, and it's up to the shaping engine to employ them or not, based on default and user settings.

Still, I understand the assumption that one would have to specify 'common-ligatures' anyway, for UAs that might choose to ignore the "on by default" recommendation. It's still likely that 'common-ligatures' would need to be set at the document level, and 'discretionary-ligatures' set, er, discreetly. Historical alternates are something quite separate IMO, and I can easily imagine historical ligatures conflicting with standard or discretionary ligatures. It seems better to keep them apart.


>> They have the benefit of being switches directly associated with distinct categories (default, discretionary, historical).
> 
> These categories (or their names) are all but distinct.

If you mean they are not at all distinct, then I disagree. For a font designer they should have a direct influence on feature design, and if the font designer does so wisely, it should be easy for an author/user to understand. True, an historical alternate is a kind of discretionary alternate, but if both are present, the meaning should be clear enough.


>> Also, common-ligatures is more likely to be enabled across sections of (…) text, but discretionary ligatures might (…) be better applied situationally, i.e. with a span.
> 
> That is
> 
>  :root {font-variant-ligatures: common-ligatures;}
>  span  {font-variant-ligatures: discretionary-ligatures;}
> 
> instead of
> 
>  :root {font-variant-ligatures: common-ligatures
>                       no-discretionary-ligatures
>                          no-historical-ligatures;}
>  span  {font-variant-ligatures: common-ligatures /* ‘no-…’?*/
>                          discretionary-ligatures
>                          no-historical-ligatures;}

I could just as easily assert that:

 :root {font-variant-ligatures: common-ligatures;}
 span  {font-variant-ligatures: discretionary-ligatures;}

is adequate for either proposal. (If 'liga' and 'dlig' conflict, then an addition would be necessary in both cases.) I can't imagine that any UA would have 'dlig' or 'hlig' on by default. Setting them all off explicitly as per the current WD seems unnecessarily verbose.


> (The current draft doesn’t seem to say whether features that are not set explicitly are inherited or fall back to their font-specific default, as in ‘normal’.)
> 
>> Your proposed syntax merges the two and blurs this distinction,
> 
> When or where would you want ‘dlig’ to be on, but not ‘liga’?
> 
> Would you like ‘additional-ligatures’ or ‘optional-ligatures’ better?
> 
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = 1
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = 0
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = i
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 1, ‘dlig’ = 1, ‘hlig’ = d
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 0, ‘dlig’ = 1, ‘hlig’ = 1
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 0, ‘dlig’ = 1, ‘hlig’ = 0
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 0, ‘dlig’ = 1, ‘hlig’ = i
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := 0, ‘dlig’ = 1, ‘hlig’ = d
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := i, ‘dlig’ = 1, ‘hlig’ = 1
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := i, ‘dlig’ = 1, ‘hlig’ = 0
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := i, ‘dlig’ = 1, ‘hlig’ = i
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := i, ‘dlig’ = 1, ‘hlig’ = d
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := d, ‘dlig’ = 1, ‘hlig’ = 1
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := d, ‘dlig’ = 1, ‘hlig’ = 0
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := d, ‘dlig’ = 1, ‘hlig’ = i
>     ‘discretionary-ligatures’ ⇔ ‘liga’ := d, ‘dlig’ = 1, ‘hlig’ = d
> 
> Which one of the above would you prefer? (‘i’ means inherit, ‘d’ is font default.)

I suppose: ‘discretionary-ligatures’ ⇔ ‘liga’ := i, ‘dlig’ = 1, ‘hlig’ = i

I prefer that 'discretionary-ligatures' have no effect on the setting of standard or historical ligatures. I agree that in most cases 'dlig' would be enabled along with 'liga', but there's nothing stopping a font developer from making them mutually exclusive (making the former an alternative to the latter). At Adobe we're relatively consistent about such things, but we've seen other take many different approaches.


>> and I think it would be more confusing to the average developer.
> 
> No, it wouldn’t, because the average (website) developer is not a font designer, too.

I believe you mean to say, "No, I don't think it would ..." My opinion is based on the same reason, so your belief is just different than mine and it's all speculation.

-Christopher
Received on Thursday, 23 February 2012 01:56:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:51 GMT