W3C home > Mailing lists > Public > www-html@w3.org > May 2006

Re: Downloadable fonts and image replacement

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 1 May 2006 21:19:09 +0200
Message-ID: <17494.24365.895622.614004@localhost.localdomain>
To: Steve Zilles <szilles@adobe.com>
Cc: www-style@w3.org, www-html@w3.org, www-font@w3.org

Also sprach Steve Zilles:

 > >  - it makes specifications simpler to implement; simplicity is good
 > I do not think that this is true unless you intend that an implementor 
 > implement no font (or image) format. Having one or a small number of agreed 
 > formats to implement would be simpler than having to guess what formats 
 > might be needed.

Conventions develop more easily outside of specifications. One example
is JPEG. Only the "lossy" half of the JPEG standard is used, not the
"arithmetic coding" part. The unused part of JPEG is encumbered with
patents and if HTML required support for it, it would have been much
harder to support HTML. And, there probably wouldn't have been any
open source browsers.

On that note, one way to skew competition is for vendor A to lobby to
require support for a format that vendor B cannot support (due to
patents or other reasons).

 > Standards are aimed at benefiting both providers and users of the 
 > tools/User Agents that implement the standards. Standardizing on subsidiary 
 > standards simplifies the life of both the providers and the users. Would 
 > you argue that having a minumum character encoding standard of UTF-8 and 
 > Unicode was a bad idea and that we should have allow as many character 
 > encodings as people might create? 

Yes, certainly it should be allowed. For example, HTTP is agnostic
wrt. character encodings. It does not favor UTF-8 or Unicode, and this
is a correct design. Of course, for practical reasons we want there to
be a limited number of encoding content. But the list should not be
specified by HTTP.

 > As the discussion on this topic points out, many of the problems we
 > have today are there because the initial support for Unicode was
 > inadequate.

Support for many web specifications (including CSS) has been
inadequate. Making normative cross-references between them would not
have solved the problem.

Assuming you could specify the list of required formats for webfont
implementations, what would the list look like?

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 1 May 2006 19:20:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:13 UTC