Re: [CSS21] @font-face question

On 7/2/04 12:07 AM, "Chris Lilley" <chris@w3.org> wrote:

> 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.

Right.

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

The revision?  Do you mean a future revision to the CSS3 Web Fonts module?

Yes, I think it would be quite useful for future implementers if the feature
was simplified in that fashion.  Heck, just drop all the pieces that were
never implemented since by now (>6 yrs after CSS2 became a REC), who will
bother?


> 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.

I agree that sometimes when folks argue for whole bunch of stuff for a
feature, that it's not always obvious that it's not all needed.

However, now we have the CR period where such "overdesigns" can and should
be pruned away, unless those people that insist on them want to put up their
time/money and build the functionality themselves.


> 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.

Good.


>>> 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."

Ah, ok, then we are talking about different "early browsers".  Browsers
without CSS were before my time as an implementer.


> 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.

Just the standard rant for CSS, which tends to encourage semantic markup,
and against presentational markup, which tends to lead to nearly completely
non-semantic markup.

Tantek

Received on Friday, 2 July 2004 14:29:25 UTC