- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Thu, 01 Jul 2004 18:18:20 -0700
- To: Chris Lilley <chris@w3.org>, Adam Badura <abadura@o2.pl>
- Cc: <www-style@w3.org>
On 5/5/04 2:14 PM, "Chris Lilley" <chris@w3.org> wrote: > > On Wednesday, May 5, 2004, 9:19:50 PM, Adam wrote: > > > > AB> ----- Original Message ----- > AB> From: "Chris Lilley" <chris@w3.org> > AB> To: "Adam Badura" <abadura@o2.pl> > AB> Cc: <www-style@w3.org> > AB> Sent: Wednesday, May 05, 2004 9:06 PM > AB> Subject: Re: [CSS21] @font-face question > > AB> On Wednesday, May 05, 2004 9:06 PM, Chris wrote: > > CL>> AB> Or is there a way using > CL>> AB> something other, perhaps DHTML or JavaScript? > CL>> AB> Adam Badura (abadura@o2.pl) > CL>> > CL>> Not really. > CL>> > CL>> Are you using downloadable fonts for a particular artistic effect, or > CL>> are you using them to get support for a particular language? > > AB> Artistic. I know that I can use graphic images, but I supose this is not > as > AB> good as font would be > > You are right, it is not. Its still very prevalent, though, because > its seen as easier (until the design changes or the text changes and > someone has to find the old photoshop files and edit the text, or re > do the thing from scratch) and better (precise control over tracking > and kerning, ese of drop shadows and other effects). > > > AB> and using a font is easier for me, because I can > AB> change text easly. > > Yes, exactly. > > AB> Why "@font-face" is not implemented in browsers, or at leasn not as it > AB> should be? I thought it is not THAT difficult, esspecialy for big > companies. > > I agree it is not that difficult, as demonstrated by the fact that it > is implemented in SVG Tiny browsers on mobile phones! So a desktop or > laptop machine could fit it in I am sure *if there was a will to do > so*. > > The original font wg, which I chaired and whose work later got > absorbed in to the CSS wg, was unable to agree a single font format > that should be supported - vendors championed their own one, and > no-one would give in to the other. So the original specifications, as > they became in CSS2, had ways to link to different font formats, lists > of formats, and all that. > > 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.) Not true. We implemented the same simple @font-face font download support in IE4.x/Mac as went into IE4.x/Windows. However, because the @font-face feature as a whole was too onerous to fully/properly support, and because nowhere was it even implied that a "download only" profile of such feature would be acceptable, we cut our incomplete support and dropped @font-face from IE5/Mac. @font-face is a good example of an over-designed/bloated/monolithic feature that directly resulted in at least one implementer trying and giving up. > Frankly this was not a desirable solution and was too much work for > content developers. They were willing to make one font, in a subset > suitable for their site; they were not willing to make multiple copies > in different versions with different tools and put different markup > and styling in their content, one per implementation. Agreed. > 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. 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. This seems like a fairly inaccurate generalization, at least if you take "early browsers" to include browsers that attempted even a reasonable implementation of CSS, also (primarily) a graphical standard, yet one that encourages semantic markup (which is potentially presentable across devices with a wide variety of different media) instead of presentational markup which more often than not obscures (if not destroys) semantics and makes it difficult (if not impossible) to provide alternate presentations for different media, users, preferences etc. Tantek
Received on Thursday, 1 July 2004 21:18:03 UTC