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

On Sat, Mar 20, 2010 at 7:26 AM, Richard Fink <rfink@readableweb.com> wrote:
> The concern about the wrong contextual alternates being applied to the next
> font down the line in the font stack is about a concern that the *wrong*
> information would or could be delivered if extra controls aren't enforced.

Indeed, we don't want the wrong information to appear.  Thus our
concern, and our attempt to create solutions where it is impossible
for it to happen accidentally, especially in cases that are *very*
unlikely to receive testing coverage from authors.

> My point in mentioning a javascript solution was that authors already have
> the "no font, no text" option. It just isn't as convenient and easy as a CSS
> property that achieves the same thing. There *are* already ways to measure
> if the font has loaded and defeat the display of text if it hasn't. Maybe
> it's time to think outside the box and provide that option in CSS. Just
> thinking out loud. Maybe a keyword of "none". Perhaps local() could do
> double-duty for this and specifying local(none) would trigger "no fallback".
> I don't know how difficult this would be for implementers.

You can do basically anything in javascript.  That doesn't mean that
everything is a good idea.  This *should* remain something that is
fundamentally difficult for authors to do.  You should not get to
decide that if I can't display your content prettily enough, I don't
get to use it at all.

> The offhand comment "Data URI's anyone?" was intended to remind that there
> is a way to inextricably tie the font to the HTML document ("embedding" it
> as a base64 Data URI) so that both font and message are gotten with the same
> http request. For those authors extremely concerned about their font
> loading, that's one way to go. If the font doesn't load, the page almost
> certainly has not loaded, either. Data URIs are currently not supported in
> some UA's - for example, IE - but that's the kind of thing I assume the WG
> will be working on. Or at least talking about.

Sure, that's a valid option, though wasteful (as the font never gets cached).

> Today, we accept the "no font/no information" scenario with Flash on the
> iPhone

Flash has never been a good solution, for many reasons.

> or text-as-images that may fail to load for one reason or another.

No, we do *not* accept that.  We have fallback in the form of the @alt
attribute for *precisely* this reason.  If the image doesn't load, you
get the plain text instead.  Accessibility isn't just for the
disabled; it often has useful effects for everyone.  (If you're using
text-as-images without providing good @alt text, you're a bad author.)

~TJ

Received on Saturday, 20 March 2010 15:02:16 UTC