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

Christopher Slye:
> On Feb 22, 2012, at 12:28 PM, Christoph Päper wrote:
> 
> Laying-out the big matrix of variations doesn't make much of an impression on me.

I wanted to be sure everybody knows exactly what we’re talking about here, not impress.

> I don't see it as "more complexity," I see it as "better control."

It may be finer control, but that doesn’t mean better, because …

> More important to me is what meaning the settings convey, and how often they would be used by most developers, most of the time.

… of that.

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

Yes, Germanism, sorry.

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

The digit styles in particular are a good example why we shouldn’t map OT features 1:1 to CSS. In a user-centric approach – where the user is a stylesheet author or web designer and not a font developer – detailed control often is a secondary requirement. First we have to make the most common usecases easy to deal with. 

  table { /* make digits monospaced, casing is unimportant: */
     font-variant: tabular;
  }
  h1 { /* make digits (and letters) uppercase, width is unimportant: */
     font-variant: titling;
     text-transform: uppercase; /* implied? */
  }

A CSS author usually doesn’t care in these cases which combination(s) of ‘lnum’, ‘onum’, ‘pnum’ and ‘tnum’ would yield the desired result. The current keywords are 1:1 aliases and that’s bad user interface design, in my humble opinion.

<http://lists.w3.org/Archives/Public/www-style/2011Mar/0183.html>

>> the initial value ‘normal’ relies on the default settings inside the font.
> 
> There is no such setting inside the font.

Then the draft needs changing, because it currently reads:

  A value of ‘normal’ implies that the defaults set by the font are used.

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

I once suggested to combine ‘hlig’ and ‘hist’ within a keyword (for the shorthand property) like ‘historical’, ‘historic’ or ‘old-fashioned’.

>> :root {font-variant-ligatures: common-ligatures;}
>> span  {font-variant-ligatures: discretionary-ligatures;}
> 
> I could just as easily assert that: (…) is adequate for either proposal.

Okay, but then your point that the new syntax was more verbose is moot.

> Setting them all off explicitly as per the current WD seems unnecessarily verbose.

I agree, but that’s what easily follows when you map binary font features 1:1 to CSS keywords.

>> When or where would you want ‘dlig’ to be on, but not ‘liga’?
>> 
>> Would you like ‘additional-ligatures’ or ‘optional-ligatures’ better?
>> 
>> 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

So I thought. 

As far as I understand implementation details, it’s complicated to inherit (“i”) properties partially. If we had properties ‘font-variant-ligatures-discretionary’ you could use that and have the shorthands ‘font-variant-ligatures’ and ‘font-variant’ reset non-specified sub properties (as this is common in CSS), but I think limiting the number of new (sub) properties to the bare minimum is a design choice the WG agreed upon.

> I prefer that 'discretionary-ligatures' have no effect on the setting of standard or historical ligatures.

Are your objections mostly about the name of the keyword then?

> I agree that in most cases 'dlig' would be enabled along with 'liga',

In this case, ‘foo-ligatures’ (‘liga’=1, ‘dlig’=1) would be a good companion to ‘bar-ligatures’ (‘liga’=1’).

> but there's nothing stopping a font developer from making them mutually exclusive (…).

If that’s a common scenario, we could add ‘baz-ligatures’ (‘dlig’=1).

I don’t care that much about the actual names of the placeholders foo, bar and baz.

In any case, we should spare ourselves of ‘no-…’ keyword variants.

>> No, it wouldn’t, because the average (website) developer is not a font designer, too.
> 
> … My opinion is based on the same reason, …

The hostname of your email address triggers certain stereotypes.

Received on Thursday, 23 February 2012 09:45:03 UTC