- From: Laurens Holst <lholst@students.cs.uu.nl>
- Date: Mon, 01 May 2006 19:46:19 +0200
- To: Steve Zilles <szilles@adobe.com>
- Cc: www-style@w3.org, www-html@w3.org, www-font@w3.org
- Message-ID: <4456496B.20403@students.cs.uu.nl>
Let’s take a special font format for mobile phones as an example. I could imagine that only mobile phones would implement that format, and they would only implement that. Regular browsers will probably support TTF. There’s no need to require the mobile phones to handle TTF as well, nor browser to handle the mobile font format. If the font format can not be handled, nothing terrible will happen – the user will still be able to read the page. ~Grauw Steve Zilles schreef: > At 07:02 AM 5/1/2006, Håkon Wium Lie wrote: >> I think the priciple of specification independence, as far as >> possible, is important. There are several reasons: >> >> - 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. > > >> - it makes specifications more reusable; you can reuse a >> specification in new contexts without dragging along a bunch of >> other specs > > If you express the requirement to implement one or a small number of > formats as a minimum, then implementors can add other formats as they > become important (either to the public as a whole or to that > implementor). Having a minimum means that developers have something > they can depend upon and not having to prepare and list a long list of > fallbacks because the implementations differ on what is implemented. > > >> - it makes specifications prove their worth in the market. I believe >> in specificational Darwinsim. If a specification can't survivive on >> its own, perhaps it shouldn't. PNG proved its own worth, and so did >> TrueType. However, if we accept the idea that one specification can >> require support for another, it might tempting to rescue a >> failing format by requiring support for it. > > I agree that market acceptance is an important factor to be > considered. I might even argue that one should not develop standards > (Recommendations) where there is not some kind of market agreement on > what is needed. But, I do not think that standardizing on accepted > formats means trying to rescue a failing format. Standardizing on > accepted formats means making it simpler for designers to produce web > pages with interesting content and design and have them work across a > range of User Agents. > > 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? 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. > > * Steve > ===================================== > Steve Zilles > *115 Lansberry Court, > Los Gatos, CA 95032-4710 > steve@zilles.org > -- Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Laurens Holst, student, university of Utrecht, the Netherlands. Website: www.grauw.nl. Backbase employee; www.backbase.com.
Received on Monday, 1 May 2006 17:46:38 UTC