W3C home > Mailing lists > Public > www-style@w3.org > May 2009

Re: CSS3 Web Fonts issue with ?block on downl oad?

From: David Hyatt <hyatt@apple.com>
Date: Thu, 07 May 2009 13:59:24 -0500
Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, www-style@w3.org
Message-id: <A15BC6B7-344C-4A1D-A6BB-B9FEC96D55C8@apple.com>
To: Adam Twardoch <list.adam@twardoch.com>
On May 7, 2009, at 1:17 PM, Adam Twardoch wrote:

> Short: 640K ought to be enough for anybody.
> Long: this is completely illusoric and is not supported by
> typography-aware designers.
> In many cases, it's not possible to provide similarly-proportioned
> fallback fonts when the designer has chosen to create the website  
> using
> fonts of non-Carterian proporions (i.e. fonts that have proportions
> obviously different from the Microsoft fonts designed by Matthew  
> Carter:
> Verdana and Georgia). If you use a more condensed font, you can easily
> fit three columns onto a web page rather than two (of course, you'd  
> use
> a larger point size). But the standard operating systems may not ship
> with good approximations of those fonts. Just look at script and
> calligraphic fonts as an example.
> What you're saying is similar to the idea that web pages should only  
> use
> 216 colors, because those can approximate all possible colors, or  
> that,
> if "proxy" images that use 216 colors were displayed instead of the
> actual graphics, people wouldn't mind the FOUC.
> I must admit that EOT, which provides a mechanism simiar to that of a
> "progressive JPEG", is an attractive alternative to desktop font  
> formats
> which would solve some of these problems. In short: with properly-made
> EOT, a web page could be perceived to "load much faster" than a the  
> same
> page that used a remote desktop font with the same design and glyph
> repertoire.

I never said the solution couldn't be improved upon, and I never  
opposed the suggestion of progressive streaming.  In fact I think  
that's a good idea.

With existing technology, the choice is between always flickering all  
of the text on the page, or having text pop in and risking some visual  
jumping.  I never said this sort of jumping would never occur in the  
latter case, but the choices are between "always look bad" and  
"occasionally look bad" when dealing with what we have currently.   
WebKit has opted for "occasionally look bad."

An even better solution is obviously "never look bad" and I didn't  
oppose that with my message, so I have no idea why you're attacking me.

Received on Thursday, 7 May 2009 19:00:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:26 UTC