RE: [css3-fonts] font-specific feature handling

Friday, March 19, 2010 7:22 AM <jonathan@jfkew.plus.com>:

Jonathan Kew wrote:

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

John Daggett wrote:

>I think we're all accustomed to dealing with font stacks and fallback
>issues but with downloadable fonts, that's really an old paradigm.  In
>a world where web fonts are ubiquitous, an author specifies the font
>they want and doesn't worry so much about fallback.  I don't think we
>should make authoring more difficult in this situation for the sake of
>fallback problems that are theoretically possible but generally don't
>occur in practice.

I agree. On balance, the verbosity that comes with *restricting* the values
to the @font-face declarations doesn't seem to bring a benefit commensurate
with the cost. More rules to write, more ways to go wrong.

I'm all for thinking things through but I suspect some over-cautiousness
might be at work here:

As someone who's used @font-face a lot - an early adopter of sorts - I can
tell you firsthand that, from a distance, it looks perilous but it isn't.
After years of relying on the OS to provide fonts, linking to a font feels
like a high-wire act without a safety net. Yet, exactly the opposite is
true. @Font-Face provides certainty where previously there was none.

(Remember, the fallback stack is nothing but a safety net designed to cope
with the problem of different fonts/different platforms. There is little
virtue in it other than that. Going forward, I can easily imagine scenarios
where, if the font fails to load, authors would rather a blank page be
displayed because the design and layout is so font-specific, the page would
be a mess and the message lost.
Currently, the draft has no mechanism for *turning off fallback* and taking
the OS out of the font-providing business entirely. I know of a highly
reliable JavaScript technique for detecting when and if a font has loaded,
but I would like to propose that you save authors the trouble of turning to
script and consider adding such a mechanism within CSS. I think it would be
very helpful during the development process to have a simple way to carve
the fallback fonts out of the picture entirely. Or, at least, the keyword
font families. I'd rather see blank space than have the UA "fill in" the
glyphs with another font that only confuses me as I try to design and
debug.)

Once you start using it, @Font-Face brings a change in perception: you
realize that the OS isn't in charge of fonts anymore; they are a resource
like any other; and that you - the author - are in charge.
It takes awhile for the added responsibility to feel normal but it comes.
Paradigm Lost. Data URI's anyone?

Restricting authors in an attempt to save them from their own mistakes
doesn't make sense - and if fallback to a keyword font family could be
turned off, the chance of an unintended consequence could be reduced to
nothing. If that's what the author wants.

Regards,

Rich

-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
Of Jonathan Kew
Sent: Friday, March 19, 2010 7:22 AM
To: www-style list
Cc: Robert O'Callahan; John Daggett; fantasai
Subject: Re: [css3-fonts] font-specific feature handling

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 19:33:13 UTC