RE: DSSSL & Interleaf

(limited to www-style)

Glenn Adams wrote:
>For starters, the syntax and semantics of CSS (to the extent that they are
>specified at all), seem to encounter significant changes every few months.

That has certainly been true in the past, and hopefully will not continue, 
for all our sanities' sakes.  In discussions with Hakon and Bert, I don't 
think the syntax is likely to dramatically change for CSS Level 1 any more.

>In contrast, DSSSL is now an ISO standard.

Certainly I have never intended to give the impression that DSSSL (and/or 
DSSSL-O) are lacking in power, stability, or expressiveness, or that we 
"choose" CSS because we think it's "better" than DSSSL.  Our support of CSS 
is not intended to be exclusive of DSSSL.  You seem to be attacking CSS as a 
Band-Aid(TM) solution to a long-term problem - sometimes Band-Aids are 
necessary; this is not intended to be a replacement for the development of 
neurosurgery.  As one of my colleagues put it, "We certainly learned our 
lesson from MS-DOS, which was a collection of shortsighted hacky solutions 
to complex problems and was doomed to die off very quickly.  As everyone 
knows, Windows replaced MS-DOS in only 12 years."  Will CSS be a major 
stylesheet format in eight to ten years?  I don't know; for that matter, I 
don't know if DSSSL (or a subset) will either.  In the meantime, though, I 
believe there is a lot of good mileage to be obtained from CSS.  And, as 
always, I (as well as the CSS folks at W3O, I'm sure) welcome any 
contributions to making it more powerful or better specified; it makes my 
job easier.

>Moreover, the proposed style features represented by CSS seem to be
>poorly conceived, poorly specified, and, for the most part, a recipe
>for incompatibility.

In some ways, that may be true; certainly, font face specification is left 
way too open-ended for my taste.  I would like a more in-depth discussion of 
why "all" the style features represented by CSS seem to be "poorly 
conceived" - many seem to be very valuable stylistic markup.  Perhaps if you 
shared your conceptual differences, these shortcomings could be addressed.

>Finally, there is little direct involvement by the vendor community in
>the specification, development, or deployment of CSS.  Rather, it appears
>to be more of an academic exercise in building an experimental style
>system test-bed.

I disagree; Bill Perry, the "vendor" of Emacs-w3, has been very involved in 
the specification and deployment of CSS (since the beginning, I believe). 
 Microsoft has become increasingly involved in the specification also, and 
as I said at WWW4, we are working on a stylesheet implementation.  I know of 
at least one other organization working on stylesheets, in addition to your 
own company.  I certainly have never been given the impression that the 
W3C/W3O is turning away any attempts at vendor involvement in the CSS effort 
- much the contrary.

>Actually, it is my experience in implementing this support that it will be
>of limited utility for even current Web content providers since it is
>not capable at this time of describing the presentation behavior of
>popular UAs.  To give a quick example, try to specify the indentation
>and list item numbering/bullet semantics for the following in a manner
>consistent with current Netscape display behavior using rules not based
>on this particular document (disregard the fact that the following does
>not conform to an HTML2.0 or HTML3.0 DTD -- users don't care):

I took a look at this example in Netscape Navigator, and although I believe 
it would be possible to add declarations to the HTML 2.0 stylesheet that 
would describe the presentation of this document in CSS (1), I did not 
realize it was the goal of ANY stylesheet description effort to duplicate 
the presentation anomalies of any existing browser.  (I'm currently working 
on the third WWW browser of my career, and my first reference is still the 
HTML specification.)  The default stylesheet, at least as referenced in the 
CSS specification, should represent a clean interpretation of the HTML 
specification, not an attempt to describe some vendor's implementation of an 
HTML viewer.  If you wish to duplicate this behaviour, however, see my 
footnote; it's just a stab in the dark, and may have side effects, but it 
would duplicate Netscape Navigator's behaviour in this situation.

Gavin Nicol wrote:
>This is, of course, in addition to the fact that to accomplish it's
>main goal of avoiding tag explosion, it will have to be able to supply
>all of the possibilities that tag explosion allows. It is not even
>close yet, and probably will never approach this goal.

I still feel that CSS helps avert a large amount of tag explosion; for 
example, if we had had CSS in place in Internet Explorer 2.0, there would 
have been no "need" to create a tag for marquees.

>I think you'll find that people who really *care* about stylesheets,
>have a very different set of needs, and a very different mindset to
>the average WWW surfer.

Exactly, and in support for those who really care about stylesheets, I 
personally encourage the development of DSSSL-O, DSSSL itself, and any other 
future stylesheet proposals.  The "average WWW surfer" is, however, exactly 
the person we as a company need to support.  I do not believe this is to the 
exclusion of those who "really *care* about stylesheets," however.

	-Chris

(1): Something along the lines of:
OL { list-style: decimal }	/* As in the HTML 2.0 stylesheet */
LI { margin: 3em }		/* As in the HTML 2.0 stylesheet */
OL TABLE { list-style: disc }	/* To account for Netscape anomaly */
OL TABLE LI { margin: 0em; text-indent: 3em }	/* To account for Netscape 
anomaly */

Received on Monday, 15 January 1996 13:21:31 UTC