Re: Is DSSSL Hard?

>  > This is what I found in my test of DSSSL for a simple 
>  > CSS-like  stylesheet. Stylesheets follow.

> Your comparision is interesting, although confrontational. This
> message is not trying to argue that DSSSL is hard, 

I wish that someone would argue that! Rather, they tend to assert it
with no evidence or examples.

> but rather tries to
> clarify some of your arguments and answer your questions about CSS.
> Also, I add some DSSSL questions of my own. Let me also say that I
> think DSSSL and CSS can live peacefully together, and that our
> energy is best spent promoting the concept of style sheets instead
> of fighting syntax wars.

I agree 100%. What I'm worried about is not syntax, but semantics. If
CSS grows in ways that are incompatible with DSSSL, then implementors
will have to implement two different models. Of course CSS will always
be implementable as a subset of DSSSL: Turing proved that a long time
ago. But the kind of stylesheets that you get out of a system, with,
say, counters, are highly non-optimal. CSS should be growing towards
DSSSL as a declarative subset with a friendlier (not easier) notation
instead of growing into a competitive, complex language.

>  > Despite the fact that the DSSSL stylesheet is substantially
>  > more complete, I do not believe it to be much more difficult to
>  > understand or write than the CSS one.

> In what way is the DSSSL style sheet more complete? The parts 
> I see missing in CSS are values (e.g on 'display') to declare 
> TABLE as a table, IMG as a replaced elements and BR as a paragraph 
> break. 

The premise of the discussion is that we are applying the two 
stylesheet languages to a new DTD (e.g. something created with XML). 
You might have missed the discussions that lead up to that document. 
I will update it to make that clear.

Now given that premise, I think that a stylesheet that supports 
pictures, paragraph breaks and images IS substantially more complete. 
I don't write a lot of documents that do not use one of those elements.

> In
> DSSSL, I miss floating elements, anchor pseudo-classes and some
> relative values (e.g. on 'font-weight'). Anything else? I believe the
> missing parts can be added in both languages, and I don't see how you
> can argue that one is substantially more complete than the other.

I'll add relative values today. I'll look into relative values. Anchors 
pseudo-classes are meaningless in the print context that the DSSSL 
sheet was optimized for. I can take them out of the CSS one to make the 
comparison more accurate, though.

> Exactly. It would be natural for CSS to add a TABLE flow object (to
> borrow from DSSSL terminology), and I assume DSSSL would add the
> ability to float elements through a new flow object?

I believe that floats are equivalent to the existing marginalia flow 
object.

> Defining a new unit in one line of code sounds easy, but how do you
> convey how the new unit is to interpreted? I would think that has to
> go into a specification somewhere?

I was not arguing that DSSSL is more powerful because it is only one line 
to choose which color-space to use. I was pointing out that the DSSSL 
spec. has an extra line but that there was a good reason for the extra 
line and that it can be removed in a DSSSL-for-the-Web where RGB is the 
accepted default color-space (despite RGBs flaws).

> > 3.You may also
> > define units in DSSSL and I added "em" to the list of defined units
for
> > ease of translation. This could also be predefined in
DSSSL-on-the-web.

> Ditto.

Actually, these are not the same situation. Units are generally defined in 
terms of other units. This can be done right in the stylesheet. But again, I
wasn't really promoting this feature as something important to basic users. I
was just describing why that line was there.

>  > What does it mean for a display: inline
>  > element to have a margin-left property?=20

> It means that extra space is added on the left side of the element. Do
> you object to the terminology (arguably, we're not describing a
> "margin"), or functionality (the fact that you can add space to the
> left of an element)?

More the former than the latter.

>  > What does it mean for an inline
>  > element to have a list-style: property?

> The 'list-style' property does not apply to 'inline' elements -- it
> only applies to it 'list-item' elements. See section 5.6.6 of the CSS1
> Recommendation.

"Applies to: elements with 'display' value 'list-item'" I read the phrase
in the spec as slightly different than the one you have said above. You 
have taught yourself to divide the "flow objects" into "classes". But to 
a user, reading that, it looks like two characteristics "interacting." 
Let me suggest an analogy. What if the HTML spec were written this way:

--
HREF attribute
---------------

applies to: elements with the element-type attribute value "A"
--

Isn't that more confusing? SGML and HTML have chosen to make one 
property "special", the property that declares the type of the 
element (the generic identifier). That seems like the simplest 
solution for organizing the user's mental model of how these
all fit together.

> > In my opinion, these nonsensical
> > or questionable combinations will become unmanagable in the future.

> Fresh. I don't really see how e.g. the last example differs from the
> fact that not all DSSSL characteristics apply to all flow objects --
> perhaps you could clarify?

The DSSSL standard, like the HTML standard, is organized around the 
types of objects (elements, in HTML) rather than around a series of 
"peer" classes. This helps me to organize what characteristics will 
work with what objects in my head. It also provides a natural 
organization of the spec. The display: attribute is basically necessary 
for every element (unless it is implied as in HTML), so why not make 
it special in the spec and the syntax?

> > CSS rules can be split into multiple sections, but the rules of which
> > sections will be called for which elements are complex: much more
> > difficult than those for DSSSL.

> I don't understand this statement, could you give an example?

I mean this:

---
Setting 'list-style' directly on 'LI' elements can have unexpected 
results. Consider: 

  <STYLE TYPE="text/css">
    OL.alpha LI  { list-style: lower-alpha }
    UL LI        { list-style: disc }
  </STYLE>
  <BODY>
    <OL CLASS=alpha>
      <LI>level 1
      <UL>
         <LI>level 2
      </UL>
    </OL>
  </BODY>

Since the specificity (as defined in the cascading order) is higher 
for the first rule in the style sheet in the example above, it will 
override the second rule on all 'LI' elements and only 'lower-alpha' 
list styles will be used.
---

and also Section 3.2 which is too long to quote here. Interestingly, the
DSSSL people considered rule selection rules that would be more in line
with CSS's but decided that they would be too complex and potentially
confusing.

> Technically it's not a mistake. Conflicts are intrinsic to CSS and we
> have clear rules for how to resolve them. But, as with any language,
> nonsense can be expressed in CSS...

I would like to respond: "Conflicts are intrinsic to CSS" but you just 
said that -- and it's right in the spec.. I don't think that it is a good 
thing. If you want to inherit from somewhere else in the stylesheet 
(as opposed to from your containing element), just say so explicitly:

(element p (make paragraph
		use: default-p-style
		font-size: ... ))

> > Extensions to CSS beyond its current level will only appeal to
> > professional Web publishers,

> One of the extensions we are working on is ACSS: Aural Cascading Style
> Sheets. This will enhance access to the Web for visually impaired
> users -- only some of which are professional Web publishers...

I wonder who will actually apply them? Only the professional web 
publishers or the most scrupulous of amateurs. But anyhow, I was 
thinking of further extensions to the layout model, generated text and 
so forth. I support ACSS and hope that we can add whatever you come up 
with to DSSSL. ACSS is not really about expanding CSS's domain into 
generic documents and complex HTML, but about more properly serving the 
simple HTML consistency. I think that that's great. I also expect it
will be DSSSL compatible in the sense that extending DSSSL to suppor the
same characteristics would be easy. Other developments are not really
DSSSL compatible and those are the ones I am worried about. Vendors 
will have to implement two models for the same constructs.

> There's a couple of half-truths here. The CSS properties certainly
> applies to tables and describe how they should be rendered. True, you
> cannot declare that the TABLE element is a table but as you noted
> above, flow objects can be added. 

Flow objects can be added, but if you want them to have anywhere near the
flexibility of HTML tables, you would have to massively complicate the
CSS spec. Without a flow-object style reorganization, those characteristics
will get lost among the others. Plus if the table model is incompatible 
with DSSSL's then vendors will have to implement two.

> As for images, CSS supports
> floating, borders, padding, scaling etc. Again, it's not possible to
> declare IMG to be a replaced element. In the context of HTML, this
> hasn't been much of an issue, but as CSS is applied to XML this should
> be added.

Well, that sentence wasn't meant to slam CSS as much as to describe why
one stylesheet had some features that the other didn't. The reason I 
included those features is because there is a myth that DSSSL gets hard 
as soon as you want to do something a little bit more complex (like, say
tables). It doesn't. It gets hard when you want to do something a lot more
complex (like CALS tables).

> I have some questions to your sample style sheets:

>  > (define page-width 8.5in)	; these are just useful, not necessary
>  > (define page-height 11in)

> Could one define this in a manner that would work for both American
> and A? sizes -- e.g. through client-side binding?

I wouldn't call it client-side binding, but there is a feature to 
allow that. It is called the (display-size) procedure and returns 
the space that the element being created has available to it. It 
would have been better for me to have used (display-size) throughout. 
To be honest, I didn't know about it when I wrote the stylesheet. This 
is DSSSL's biggest weakness: the spec is large and finding the feature 
you want is difficult. I don't think that this is the same as being 
difficult, however.

>  > (element B (make sequence font-weight: 'bold))
>  > (element STRONG (make sequence font-weight: 'extra-bold ))

> The CSS style sheet you are replicating uses the 'bolder' value for
> 'B' and 'STRONG', i.e. a relative value. Using DSSSL, I assume you
> could query the font weight of the parent element and add 1 or
> something?

I don't think so. Font weights are not numbers. I could write a function
to do so in 30 seconds, but the DSSSL spec doesn't do it itself. I find it
a little disconcerting that CSS would just silently make something that I
asked to be BOLDER to be actually no bolder if the maximum boldness was
already specified.

>  > (element H5=20
>  >     (make paragraph
>  > 	space-before: 1em
>  > 	space-after: 0em
>  > 	font-weight: 'bold
>  > 	start-indent: (/ page-width 20)))

> Note that percentage values in CSS is based on the dimension of the
> parent element -- which may or may not be equal to the page width. How
> would you express this?

start-indent: (/ (display-size) 20)

 > (element P
 >     (make paragraph))

> The CSS style sheet you are trying to replicate is:

>  P {
>   text-indent: 4%;
>    margin-top: 0;
>    margin-bottom: 0;
>  }

> I assume it would be easy to represent the text indent of 4%, how
> would you do it?

This is a case of me only noticing one of the two rules that apply
to paragraph elements.

(make paragraph start-indent: (* (display-size) 0.4)))

I will advocate a "%" unit for DSSSL-on-the-Web. Usually units are based 
on other units, but the CSS shorthand is handy.

>From the sample CSS style sheet:

> How would these be represented in DSSSL? I'm aware that there is no
> DSSSL equivalent to pseudo-classes, but I assume it can easily be
> added. Could you give an example of what the syntax could look like?

Well, I really don't believe that it is reasonable to expect that people
will be able to override any property at all on visited links. CSS allows
it, but it seems like overkill to me. Should a stylesheet be able to turn
a followed link into a list item? It seems that the (simpler) equivalent 
is:

(make link
	color:
	visited-color:
	active-color:
	active-background-color:
	...)

On the other hand, if you really DO think that different links should 
be able to have completely arbitrary properties, then:

(element a 
    (case (link-state)
	(('visited) (make link blah blah blah))
	(('active) (make link blah blah blah))
	(else (make link blah blah blah))))

This is the same technique that you use for differentiating based on an
attribute value:

(element foo
	(case (attribute-string "bar")
		(("baz") (make ...))
		(("jaz") (make ...))))

and other element properties:

(element foo
	(case (first-child-gi)
		(("title") (make ...))
		(else (make ...)))

 Paul Prescod

Received on Tuesday, 22 April 1997 17:46:18 UTC