- From: Jonathan Kew <jonathan@jfkew.plus.com>
- Date: Fri, 19 Mar 2010 11:21:41 +0000
- To: www-style list <www-style@w3.org>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, John Daggett <jdaggett@mozilla.com>, fantasai <fantasai.lists@inkedblade.net>
On 19 Mar 2010, at 07:21, John Daggett wrote: > > Robert O'Callahan wrote: > >> Another approach, which I raised the previous time we discussed this, is >> to allow font-specific features (i.e., numbered features) everywhere, >> but (outside @font-face) we only apply those features where the font >> being used to render the text is the first font in the font-family >> property. > > I think it would work in a lot of cases but I think it's a confusing > rule for authors. As the examples I posted show in some cases > discretionary ligatures can be very font-specific, so I don't think > restricting this behavior to a specific set of values makes sense. There > are also cases where a particular fallback pattern *would* be consistent > across fonts, it really depends on the content and the fonts involved. IMO, it's a mistake to try classify font features into distinct "font-specific" and "font-independent" categories which are then handled differently in CSS. While in some cases the classification would be reasonably clear-cut, in others it's less obvious, as John has illustrated. We should give typographically sophisticated authors/users the generic tools to make use of advanced font features, and let them decide how to apply those tools. The draft text allows for both font-specific and font-independent patterns of use, and it should be left to authors to decide which pattern is best suited to their particular purposes. Yes, it's possible to mix features and fonts in bizarre ways and get unexpected or undesirable visual results; either page authors or users with custom stylesheets and unusual fonts can indeed shoot themselves in the foot. But this is no reason to impose an artificial division of features into these two kinds. We might want to recommend some examples of typical "best practice" for how various features may be specified, but should avoid both complicating the spec and restricting potential uses. JK
Received on Friday, 19 March 2010 11:22:38 UTC