From: Douglas Rand <drand@sgi.com>
| Wolfgang Rieger wrote:
| > Suppose you were a Web author ready to write style sheets in CSS,
| > DSSSL-O and DSSSL. There would be browsers supporting
| > ...
| > What would you do?
---
If we really get to the point where there are significant user bases
with access to only one of the alternatives, we would have to hope that
it's possible to translate CSS into DSSSL. But is it really likely that any
of the major US vendors will support DSSSL and not support CSS?
A possible model is that serious authors (those with ""heavy" stylesheet
needs) would specify both DSSSL and CSS stylesheets and provide
documents via servers that recognize DSSSL-capable UAs and serve the
right STYLE element for the delivery vehicle.
---
|...
| What I would want as both an implementor and a web author is some style
| sheet language which fit naturally within the syntax of HTML. I would
| probably not be happy with DSSSL having a lisp syntax (although I
| haven't any problems with it myself). Why can't a style sheet look more
| like:
|
| <STYLE CLASS=ABSTRACT.PARAGRAPH
| SPACE-BEFORE="10 POINTS"
| SPACE-AFTER="20 POINTS"
| START-INDENT="5 EN"
| KEEP-WITH-PREVIOUS>
|
| What is the necessity to set the style declarations off in something
| which requires a separate lexer and parser? You could still store
| the entire style sheet in a URL and load it once per. set of pages
| which use the particular style sheet.
---
That's a question I wondered about, too. Why not just create a
DTD for stylesheets, like
STYLE (RULE*)
TYPE CDATA
RULE (PROPERTY*)
ELEMENTS CDATA
CONTEXT CDATA
PROPERTY CDATA
WEIGHT (important|legal|normal)
giving (for bits of the HTML 2.0 sample in the CSS1 spec):
<STYLE>
<RULE elements=BODY>
<PROPERTY> margin=1em
<PROPERTY> font-family=serif
...
</RULE>
<RULE elements="H1,H2,H3,H4">
<PROPERTY>margin-top=1em
<PROPERTY>margin-bottom=1em
</RULE>
...
<RULE elements="IMG" context="A:link">
<PROPERTY> border-color=red
...
Or even create separate elements under RULE for each property, as in
your example.
I don't know the answer. Naming and character restrictions might have
been an issue. The extra bulk of the SGML notation might have been an
issue. Maybe the authors would like to comment.
scott
--
scott preece
motorola/mcg urbana design center 1101 e. university, urbana, il 61801
phone: 217-384-8589 fax: 217-384-8550
internet mail: preece@urbana.mcd.mot.com