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

Hi John. Like Eric, I am not so keen on this proposal. You've made your case clearly, so I think I understand the problem and motivations (and the proposal is certainly not horrible), but I also think (a) it's a mistake to use font-feature-settings as a support outlet for limitations elsewhere, and (b) the problem you're solving isn't much of a problem.

I see we're getting very comfortable with OpenType font feature tags, but I remember a lot of angst about it when CSS3 Fonts was first emerging. The reasons for the anxiety were persuasive -- e.g. that 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.

Your proposal sacrifices a layer of control and defers it to font-feature-settings. 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 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 (which is how I remember it being pitched initially, but maybe I am mis-remembering).

You're worried about the current syntax being verbose, but your example

  /* enable common and discretionary ligatures */
  font-variant-ligatures: common-ligatures discretionary-ligatures;  

seems unlikely because common-ligatures will be on by default, making the new way about as verbose as the current way. Also, given that default feature behavior should be good for most people most of the time, I would think that when authors resort to customization, they would appreciate the more straightforward control that the current three axes give them. They have the benefit of being switches directly associated with distinct categories (default, discretionary, historical).

Also, common-ligatures is more likely to be enabled across sections of (or all) text, but discretionary ligatures might (depending on the font and feature design) be better applied situationally, i.e. with a span. Your proposed syntax merges the two and blurs this distinction, and I think it would be more confusing to the average developer.

Regards,
Christopher


On Feb 15, 2012, at 9:45 PM, John Daggett wrote:

> I'd like to propose restructuring the property values for
> 'font-variant-ligatures' in the interest of simplifying the overall
> syntax for the font-variant shorthand. Christoph Päper proposed this a while
> back [1].
> 
>  font-variant-ligatures: normal | inherit | [ <common-lig-values> || <discretionary-lig-values> || <historical-lig-values> ]
> 
> where
> 
>  <common-lig-values>     = [ common-ligatures | no-common-ligatures ]
> 
>  <discretionary-lig-values> = [ discretionary-ligatures | no-discretionary-ligatures ]
> 
>  <historical-lig-values> = [ historical-ligatures | no-historical-ligatures ]
> 
> Structuring the property this way allows individual ligature features to
> be explicitly enabled or disabled independent of each other.  The
> downside is that it ends up being verbose:
> 
>  /* enable common and discretionary ligatures */
>  font-variant-ligatures: common-ligatures discretionary-ligatures;  
> 
> Given that several user agents are now implementing the
> 'font-feature-settings' property, I think it would be simpler to define
> this more simply and let users use the 'font-feature-settings' property
> for more fine-grained control.
> 
> Proposed new syntax, similar to what Christoph proposed:
> 
>  font-variant-ligatures: normal | inherit | common-ligatures | discretionary-ligatures | all-ligatures
> 
> The value in this definition effectively defines the level of ligatures used.
> For OpenType fonts, these values would explicitly be defined to mean:
> 
>  normal                  == use defaults
>  common-ligatures        == liga=1, dlig=0, hlig=0
>  discretionary-ligatures == liga=1, dlig=1, hlig=0
>  all-ligatures           == liga=1, dlig=1, hlig=1
> 
> I also propose trimming the 'no-contextual' value from
> font-variant-alternates for similar reasons.
> 
> The way 'font-feature-settings' is defined, individual OpenType features
> can still be disabled individually for unusual cases.
> 
> Regards,
> 
> John Daggett
> 
> [1] http://lists.w3.org/Archives/Public/www-style/2010Mar/0049.html
>

Received on Saturday, 18 February 2012 01:13:41 UTC