Re: Is DSSSL Hard?

Henry, since what you wrote is relatively uncontraversial, I'm going to
risk Jon Bosak's ire by expanding this discussion to www-style. =)

Henry S. Thompson wrote:
> 
> Further to Paul's comments about DSSSL and CSS, here's something I
> showed at WWW6.  This is actually all but the first line of something,
> which follows after the page break -- have a guess as to what it is,
> before scrolling onwards:
> 
> ---------------------------
> p [ space-after: .3cm ]
> h1 [ font-weight: bold ]
> title [ space-after: .2cm
>          font-weight: bold
>          quadding: center ]
> 
> hr |rule]
> ---------------------------

This is exactly what I had been thinking of an hour before I read your
message. Great minds etc. etc. I hadn't thought of the trick of using
SGML syntax magic to do the transformation, but you and I agree that
that's not a good idea in practice. Dave Raggett wants a simple notation
for DSSSL, and I think that that's a good idea. People who are convinced
that DSSSL is "built upon" Scheme (as opposed to extensible through
Scheme) will never believe that it can be used declaratively until it
doesn't look "fully parenthesized prefix" anymore. CSS is established as
a simple notation.

This is similar to the idea proposed by Alan Karben (which I shot down:
sorry!), except that I interpreted his message as proposing that CSS by
DSSSL's "little sibling" "as is". I think that CSS notation is fine
(even great) but the semantics would have to be changed. They are not
scalable for three reasons.

First: The set of "flow objects" are weak. There is no table, no image,
no line break, no hyperlink, etc. That wouldn't be a problem, but for
the second problem.

Second: The concept of a flow object is buried. Which is to say that the
result of applying style to a particular element is not another "object"
of a defined "class" but simply an object of the same class as
everything else, that happens to look different. The problem with this
is that specifying what characteristics will apply to objects depending
on what other characteristics apply will become a massive problem: "If
the table cell property is applied to an element then the list-style
property is ignored or not allowed" etc. etc. I would like to know why
the CSS people made this choice. I don't think that CSS would be more
complicated if the user had to say clearly that they were making a new
paragraph, a new list item, a new inline item, a new horizontal rule, or
whatever.

Third: CSS does not allow generated text or other generated flow
objects. Text-before and text-after properties won't do the job. What if
I want an image before every P.warning (e.g. a little "hazardous waste"
sign)? What if I want a horizontal rule after every DIV.section? I'm not
talking about esoteria here: I'm talking about things that any serious
webmaster should be demanding as the next step in reducing their file
sizes and reducing the redundancy of their documents. Again, if CSS has
flow objects, this would be easy to add, but right now there is no way
to say: "put an image here" because there are no flow objects. We could
do the old "specify it as markup" trick, but that does violence to the
accepted concepts of SGML processing, the installed software base and is
also much more difficult in many situations.

I'm going to call the new CSS that I am thinking of "CSS+." I don't
think that any RFC or proposal has that name. I don't have time to flesh
it all out right now, but I'll take a stab at some ideas:

First, the "display:" property should be made special. It should declare
the "type" of the element that is output. New drafts of CSS should be
reorganized so that the effects of different characteristics on
different "presentation types" is obvious.

Second, there should be a shortcut for the "display:" property that
makes it clearer what is going on: Something like 

H1.pastoral { block color: #00FF00 }

and

LI { list-item  color: white;    
        background: blue;     /* so text is white on blue */ 
        margin: a b c d; 
        padding: e f g h;
      } 

Third, these things should be allowed to nest:

P.note { display color: white;    
        background: blue;     /* so text is white on blue */ 

	before: { text 
		color: white;
		data: "NOTE:"	
	}
	after: { horizontal-rule
		 ...
	}
      } 

and probably concatenated:

P.note { display color: white;    
        background: blue;     /* so text is white on blue */ 

	before: { 
		{ image
			source: "http://www.nuclear.org/warning.gif"
		}

		{ text
			color: white;
			data: "NOTE:"
		}
	}
	after: { horizontal-rule
		 ...
	}
      } 

This looks a little complex, but it seems to me to be a simple
declarative extension to CSS that is mostly compatible with the DSSSL
model and would allow straightforward translation to DSSSL in the
browser. It would also be more extensible and powerful even if DSSSL
didn't exist. It is in line with the power and complexity of stylesheet
facilities in standard wordprocessors. I do not believe that it any way
complicates the simple cases where you only want to add a few styles to
HTML. This idea bridges the gap between the "simple" CSS model and the
"complex" declarative-DSSSL model, but preserves CSS notation and
backwards compatibility. I have to think more about cascading,
(equivalent to DSSSL styles?) but would invite initial impressions of
what I have thought out so far.

 Paul Prescod

Received on Monday, 21 April 1997 07:34:06 UTC