Re: [CSS21] @font-face question

On Friday, July 2, 2004, 3:18:20 AM, Tantek wrote:

TÇ> On 5/5/04 2:14 PM, "Chris Lilley" <chris@w3.org> wrote:

>> There was also a failure to get the solution that had been agreed upon
>> actually implemented in the Netscape 4.x timeframe. IE 4.x implemented
>> it (although only on Windows, and most designers used Macs in those
>> days.)

TÇ> Not true.  We implemented the same simple @font-face font download support
TÇ> in IE4.x/Mac as went into IE4.x/Windows.

Thanks, I had been misinformed. Perhaps it was implemented later? I
recall there were complaints at the time that it was windows only.

TÇ> However, because the @font-face feature as a whole was too onerous to
TÇ> fully/properly support, and because nowhere was it even implied that a
TÇ> "download only" profile of such feature would be acceptable, we cut our
TÇ> incomplete support and dropped @font-face from IE5/Mac.

Aha. So, is IE4/Mac only.

However, the revision should make it clear that a 'download only'
profile is conformant.

TÇ> @font-face is a good example of an
TÇ> over-designed/bloated/monolithic feature
TÇ> that directly resulted in at least one implementer trying and giving up.

Well, I agree that the stuff that people insisted on having, such as a
look-alike synthesised font while the real font downloaded, was not in
fact needed. However, in the WG, it was strongly argued for by many of
those present, so it wasn't clear at the time that it was over designed.

But now, in hindsight, dropping the features that have not proven their
worth and taking note of implementation experience since the original
spec is certainly a good thing.

>> Building on this experience, in SVG we picked *one* font format that
>> everyone had to support, and allowed optional support of other
>> formats. We also dropped the (frankly, experimental) stuff about
>> synthesising fonts on the fly, generating lookalines based on
>> detsailed font metrics, and so forth. The parts that people actually
>> used, ie describing a font and making it available for download, we
>> used in SVG.
>> 
>> I think that is why fonts in SVG have been a lot more successful.

TÇ> That certainly seems like a reasonable explanation.


>> The other reason is that people who implement graphical standards like
>> SVG tend to be more worried about design and aesthetics than people
>> who implemented the early browsers, who often saw it as merely a
>> rendering layer that they had to get done on top of the really
>> interesting network code.

TÇ> This seems like a fairly inaccurate generalization, at least if you take
TÇ> "early browsers" to include browsers that attempted even a reasonable
TÇ> implementation of CSS,

No, early browsers had no CSS at all. It seems like a very accurate
generalization to me, having been there at the time and talked to the
folk involved.  As an example, this attitude was expressed more than
once:

"we don't need a specification for text layout. Its obvious. You read a
char and put the char on the line, until it doesn't fit and you start a
new line."

TÇ> also (primarily) a graphical standard, yet one that
TÇ> encourages semantic markup (which is potentially presentable across devices
TÇ> with a wide variety of different media) instead of presentational markup
TÇ> which more often than not obscures (if not destroys) semantics and makes it
TÇ> difficult (if not impossible) to provide alternate presentations for
TÇ> different media, users, preferences etc.

That was (unfortunately) a bit (too) hard to parse and had rather wooly
waving around of 'semantics'. If it was relevant to the current
discussion, please feel free to rephrase.



-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Friday, 2 July 2004 03:07:26 UTC