RE: CSS and SGML document formatting -Reply

Gavin Nichol writes:
>>CSS requires a seperate lexer/scanner. In fact if you go and look at
>>a few scheme implementations, you'll see that the code required for
>>parsing DSSSL is considerably less than the code needed to parser CSS
>>(and faking it by using lex and yacc doesn't cut it).

Having looked at DSSSL and CSS in some depth, I would strongly contest
the "considerably less" statement above.  However, there are two issues
here that this statement doesn't take into account - 1) The
implementation of the features DSSSL opens up would, I believe, require
MUCH more code than the implementation of the features allowed by CSS,
and 2) the readability of the stylesheet - people still author HTML
documents by hand, so the ease of authoring stylesheets needs to be
taken into account.  I don't believe DSSSL is as readable as CSS for the
average Web author (remember, here, that we're lucky if the average Web
author knows what SGML stands for).  This is not a condemnation of DSSSL
by any means; just pointing out that the goals of DSSSL and CSS are
different.
>
>>DSSSL is huge, and complex. It's true. However, here is a reasonable
>>subset of DSSSL that can be implemented (and perhaps as Scott
>>mentioned, CSS can be translated into it), while still providing
>>expandability. I should note that even with all it's complexity, I
>>doubt very much if a core DSSSL engine would weigh in at much more
>>than 100k after compilation. The complexitiy comes in the extras.

I would be very surprised if the difference between pre-DSSSL and
post-DSSSL code size would be 100k or less.  However, even so, looking
at DSSSL, large portions of functionality would have to be added to
non-SGML-based Web tools (the top 10 or so most popular web browsers,
definitely) in order to support DSSSL.  The concept of a tree
transformation engine, for example, is difficult to grasp in Web
browsers that currently don't even maintain document structure according
to the strict SGML nesting model.
> 
>>>If this isn't done, then IMO you'll continue to see ad hoc solutions
>>>from Netscape and Microsoft. 
>>
>>Some of us feel like putting CSS into the "ad hoc" category as well.

Perhaps; CSS has been under public discussion for over a year now,
though.  There are a number of definitions of "ad hoc" - I would say
previous solutions like <CENTER> and <FONT> have been ad hoc in the
sense of "for the particular end or case without consideration of wider
application" (Webster's Ninth Collegiate Dictionary) - this is obviously
not a good thing.  I consider CSS to be ad hoc in that it is "concerned
with a particular end or puppies" (also Webster's Ninth Collegiate
Dictionary).  CSS is not thumbing its nose at DSSSL, nor at the need for
a stylesheet language for use with generic SGML applications.  However,
I am (and I believe the people who have worked on developing CSS) are
concerned with a particular purpose - creating a stylesheet language for
attaching common desired style characteristics to HTML, to eliminate the
need for <FONT>-style ad hoc solutions.  We don't want solutions that
are arrived at without considering the wider application (e.g. designing
<CENTER> without considering the need for right-alignment), yet at the
same time a solution that can be implemented in a timely and useful
manner in the popular applications we use today obviously cannot be all
things to all people.

>>I should agin restate my position: I am not against CSS. For what it
>>is aimed at, it's OK, but let's *not* pretend it will satisfy anything
>>beyond the simplest typographical needs.

I would say it goes a bit beyond the "simplest" typographical needs, but
it certainly does not try to allow for everything that DSSSL does, nor
necessarily everything you might want to do in a stylesheet language.

>>I would *never* put it into the
>>category of "the only stylesheet language worth knowing" though.

Nor would I, and I am a strong supporter of CSS.  Has anyone been
representing it as such?
>
>>I should note that some people have told me that CSS is not relying
>>upon the hundreds of years of experience in typography we already
>>have, and is instead catering to the "new world". I cannot judge if
>>that is a valid stance or not. Perhaps the WWW is a new world. For
>>myself, I tend to feel it as just another exploration in human
>>communication/social interaction. 

In a broader sense, absolutely.  However, there are old paradigms
running rampant in the computer industry.  Occasionally, the conventions
have good reason to be there; occasionally, they are legacies of
previous technology (e.g., font leading vs. line-height).

Gavin also previously wrote:
>>I think you may be right. What concerns me is that with all the hype
>>surrounding the WWW, DSSSL may be given the back seat to CSS, when it
>>clearly does not deserve to be (they are chalk and cheese, or perhaps
>>chalk and granite). The folk who are pursuing CSS make this worse by
>>pretending that they can scale to full SGML, which is a blatant lie.

I would suggest a better comparison: consider DSSSL to be marble, and
CSS to be clay.  Marble is certainly preferable if you are attempting to
create a beautiful statue, but flowerpots are usually made of clay.  It
doesn't mean that flowerpots should all be made of marble, or that you
should sculpt all your statues out of clay... each has its place.
>
>>I have no problem with CSS being targetted to HTML/low quality
>>publishing. It's fine for that, and I can only encourage people to
>>start actually using it as an introduction to stylesheets. Anything
>>beyond that is clearly beyond it's realm though.

I believe the target audience for CSS is indeed HTML.  "Low quality" has
severe connotations that I would disagree with.  At any rate, if someone
came to me and asked about stylesheet languages for SGML documents, I
would point them at DSSSL or its like, not CSS.
>
>	-Chris
>Chris Wilson
>cwilso@microsoft.com
>-[-
>
>

Received on Thursday, 25 April 1996 14:49:46 UTC