W3C home > Mailing lists > Public > www-style@w3.org > March 2010

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

From: Richard Fink <rfink@readableweb.com>
Date: Sat, 20 Mar 2010 11:34:00 -0400
To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'Christopher Slye'" <cslye@adobe.com>
Cc: "'www-style'" <www-style@w3.org>
Message-ID: <002a01cac842$c4292cf0$4c7b86d0$@com>
Friday, March 19, 2010 7:18 PM <jackalmage@gmail.com>:

>Agreed.  That's... a very bad idea.  The whole *point* of CSS and
>content/style separation is that you can still get the content even if
>the style is changed or missing.

>Providing authors the ability to
>ruin a page because some request failed is horrifying.  


(See my reply to Christopher Slye, too.)
I'm almost (almost) sorry I floated the idea because we're veering away from the more pressing issue that's been raised about the options for contextual alternates.
I'm surprised by your reaction. It seems like you're objecting to authors having too much freedom.
Say it ain't so, bro'!
I see fonts as something more fundamental than "styling". And judging by the amount of Flash you see on the web sites of Fortune 500 companies, they do, too. Ask a company that's commissioned a custom font to maintain a consistent brand identity if they would rather the UA display their stuff in Times New Roman or just skip it. I'm betting it will be skip it.
Look, if I go to the trouble of setting up @font-face declarations, ornery cuss that I am, if those fonts don't load, maybe I would prefer failure. What's wrong with that? Why do I have to have the UA/OS force upon me a font I don't want displayed?
You might consider the following as edge cases but they're still food for thought:

How about pages where examining the webfont is the whole point, like the in-browser specimen pages on a site like Font Spring? 
How about pages that are re-creations of old books and documents - along with re-creations of the original fonts?

In both cases, fallback to a keyword font means a message mangled beyond repair.

And when an image doesn't load, which might very well be a background text-as-image, what does the UA fall back to then? Nothing and nobody seems to be losing sleep over it.

What specifically is your fear about what would happen if, within @font-face, fallback could be disabled?



-----Original Message-----
From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Tab Atkins Jr.
Sent: Friday, March 19, 2010 7:18 PM
To: Christopher Slye
Cc: www-style
Subject: Re: [css3-fonts] font-specific feature handling

On Fri, Mar 19, 2010 at 1:45 PM, Christopher Slye <cslye@adobe.com> wrote:
> On Mar 19, 2010, at 12:32 PM, Richard Fink wrote:
>> 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.)
> [...]
>> 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.
> Sorta, maybe... but I think you are pushing the envelope with this suggestion. I don't like the idea of the content just disappearing because the author wants it to appear "just so".
> I think we have made great progress in giving designers control over appearance, and some reassurance that things will appear as they desire almost all of the time... but the web is (IMO) still about delivery of information, and I think users deserve to get it, even if the designer doesn't like the way it looks.

Agreed.  That's... a very bad idea.  The whole *point* of CSS and
content/style separation is that you can still get the content even if
the style is changed or missing.  Providing authors the ability to
ruin a page because some request failed is horrifying.  We can't stop
it, of course, as javascript can achieve nearly anything, but we
certainly don't have to make it easy.  You don't get to take your ball
and go home just because some element of your design isn't conveyed to
your satisfaction.

Received on Saturday, 20 March 2010 15:34:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:43 UTC