[css3-writing-modes] text-combine-horizontal and font features (was: [css3-writing-modes] real vs. synthetic width glyphs)

fantasai wrote:

> > # Also, a ‘font-variant’ value of ‘full-width’ must be ignored in such
> > # cases: whether applied via ‘@font-face’ descriptor or property
> > # declaration, within the combined text this value does not not cause
> > # the UA to enable that font feature. [CSS3-FONTS]
> >
> > I've said this before, both on the list and in person, this statement
> > is in conflict with the rendering order specified in the Fonts spec:
> >
> >    http://dev.w3.org/csswg/css-fonts/#feature-precedence
> >
> > Step (4) is where other CSS features influence feature state.  What
> > you've spec'ed is that it override (5) or maybe (6).  I think this is
> > a bad idea for a number of reasons.  It complicates the simple rule
> > that font variant features override other features only for the reason
> > of excluding one possible "bad scenario", namely the enabling of
> > full-width variants.  But an author could just as easily cause
> > problems by specifying other width variants, swashes or annotated
> > figures. I don't think it's worth muddying up the feature precedence
> > model simply to avoid one particular mistake authors may make.
> 
> We're already breaking "the model" by doing codepoint transformations
> for a property other than text-transform. I don't have a problem with
> this, because as you've argued, it makes sense, gives better results,
> and satisfies use cases, whereas not doing it gives bad results and
> doesn't satisfy any real use case.
> 
> I don't see why breaking "the model" by tweaking the font feature
> stack in a well-defined way is so much more special that the same
> arguments you gave for the codepoint transformation do not apply.

Codepoint transformations are a separate operation from font features.
They always happen the same way and aren't affected by font choice.
Font features may be associated with a given font via @font-face rule
descriptors and they may be specified either via 'font-variant' and
'font-feature-settings'. That's a lot of combinations which is why the
feature precedence section of the Fonts spec is there.  You seem to
only want to "disable" full-width variants when 'font-variant' is used
but that just makes the authoring model more complex without any big
improvement in authoring experience.

Turning off full-width variants is only one thing an author might be
fiddling with that could affect the outcome of using
'text-combine-horizontal'.  An author could enable small caps or
specify italics.  Probably more relevant to the digits case, they
could specify old style numbers, proportional figures, or even
fractions. And all of these could be specified either via
'font-variant' or via 'font-feature-settings'.  I don't see a lot of
value for authors to adding in extra implementation logic simply to
prevent one pattern of poor usage with a subset of properties.  Better
to keep things simple unless absolutely necessary.

Cheers,

John Daggett

Received on Tuesday, 16 July 2013 06:12:02 UTC