Re: Is DSSSL Hard?

Chris Lilley wrote:
> What I am getting at is that simply asserting that it is possible does
> not help people judge how hard that possibility might be. Your examples
> are a big help in this.

That's part of my goal. As long as CSS stays truly a subset of DSSSL, we
can all win.  The only feature that is problematic now is the cascade,
(which may be central to the marketing, but not to everyday use ...
override would work as well).
 
> Good, because your style sheet defined device RGB whereas CSS uses a fully
> defined, color managable definition of the color space, defined in terms of
> an ICC profile (submitted by ISO TC 130 as ISO 15076 Graphic technology --
> Prepress digital data exchange -- International colour profile format)
> 
> See also http://www.w3.org/pub/WWW/Graphics/Color/sRGB

I'm certainly not a graphics expert, but I know experts who feel very
passionately that RBG is broken, so I am glad that the DSSSL syntax has
mechanisms for choosing other color spaces when they are necessary.

BTW, that document bothered me because the link colours were overridden
to be black. I'm used to them being blue. Black underlines I interpret
as emphasis. The interesting thing is that despite the fact that I
theoretically have the ability to override it, I have absolutely no
interest in doing so. Instead, I wish that the authors had just left the
default styles relatively alone. That relates back to my other message
about the cascade. Authorial responsibility is still more important than
the cascade.

> Yes. It's not in the DSSSL spec because (correct me if I am wrong) DSSSL
> has no cascading mechanism - I am sure you will say that one can be
> programmed in DSSSL since it is Turing complete - 

Not at all! Things that are a good idea (and not intrinsically complex)
should be easy in DSSSL: and usually are. I don't think that the cascade
falls into this category (anymore).

> and thus the reader
> is unable to influence the presentation with their own stylesheet;

Not true. The stylesheet is data. It can be embedded in another
stylesheet where the user's construction rules take precedence.

> authors are unable to 'subclass' existing stylesheets by cascading
> them with their own overrides. 

Once again, stylesheets can be embedded in other stylesheets.

> Thus DSSSL avoids having to specify
> how to resolve conflicts by limiting itself to situations that do
> not generate any.

Exactly! Usually the avoidance of confusing conflicts is called
"simplicity." That's why I argue that DSSSL is *easy*.
 
> Fine - can you inherit from a different stylesheet? How can document
> readers inherit from a stylesheet they haven't seen yet? 

Why do you want to do that? How can you know what you want to override
before you've seen it? How can you predict the interaction between your
styles and theirs? How can you know if you will undo distinctions that
the stylesheet author carefully created? How can you know in advance
what classes (in HTML) or elements (in XML) to override? It's like
building a subclass of an object in Java or C++ without looking at the
headers or documentation for the class. Your new, combined object is
just not going to work right. Thus, just in Java, you have three
options:

#1. You use the provided class (stylesheet).
#2. You explicitly inherit from the provided class (stylesheet) in a
well-documented manner.
#3. You use your own class (stylesheet) and ignore the provided one.

> And if DSSSL
> cannot do this, how can readers exchange stytlsheets with each other

I don't see the connection. Panorama users exchange stylesheets with
each other all of the time. 

> - we are back to non-portable and often non-exposed proprietary 'user
> preference' files, we are back to 'one size fits all eyes' presentation
> and if you happen to be dyslexic or color-blind or have low vision,
> there is nothing you as a reader can do.

Not at all true. 

The first problem is that it isn't clear how CSS helps nor DSSSL hurts.
How do I globally override all colour changes on all classes using CSS?
The same way I would in DSSSL, or without any style language at all: I
ask the UA to map colours to greyscales. How do I globally override all
font sizes in CSS? I can't.

So I don't see CSS helping much. DSSSL can help through mechanism 2
above. It can make it very easy to build parameterized stylesheets. It
can also allow you to override construction rules. Finally, you always
have the option of using your own style sheet. When I say "your own", I
actually expect that public domain stylesheets for the visually impaired
be related to actual DTDs through public identifiers. This cannot be
done for ad hoc CLASS sets as in the HTML+CSS model.
 
> CSS has chosen to tackle these issues, they are important issues, and
> I hope DSSL can be adapted to tackle them too.

CSS tried to tackle these issues, but I have no evidence that the
cascade solution works, and I don't even see how it would work
theoretically, so I prefer the series of mechanisms that are tried and
true: well known DTDs, strict validation, public identifiers, and
stylesheets customized for visually impaired people (a la ICADD). The
cascade transfers responsibility (and work) into the lap of the user. It
doesn't really transfer control, because everyone has the fundamental
control of telling the UA not to use the author's stylesheet.
 
> Ah, you forget the cascade. Blind and print-disabled *readers* will
> apply them, in the first instance. 

What does that have to do with the cascade? What is the value to a blind
person in "cascading" on top of a stylesheet of beautiful colours that
he or she can't see! Wouldn't she or he rather just dump it and start
again?

> That is really good news and perhaps we could address that in a
> separate thread.

Certainly.
 
> > 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.
> 
> Is that a volunteer I hear in the audience?

I'm not sure what's involved. I suspect that the SGML community would
want to be more involved than just handing it off to me! We can begin to
throw around ideas, however.
 
> Even better, what happens when the reader resizes the browser window?
> I know that DSSSL was originally a print-oriented technology but it
> should at some point be possible to use it for interactive reading of
> online documents rather than batch processing, shouldn't it?

There is nothing about DSSSL that presumes batch processing. Issues of
batch processing vs. interactive are also distinct from print vs.
online. I want a DSSSL wordprocessor for print documents that gives me
an interactive WYSIWYG view. That's interactivity without online.

Anyhow, ISO DSSSL supports online. It is not specialized for the web,
however. And there was certainly not as much work put into the online
flow objects as there were into print.
 
> A subtle distinction, perhaps. But does this mean that when the reader
> resizes the browser window, the display-size procedure will return a
> different result? If so, does this trigger a reflow or are flow objects
> created only once as the document is read?

The DSSSL spec does not specify. It is a language for attaching visual
semantics to documents and not for specifying user agent behaviour. That
distinction is subtle and blurry, so maybe DSSSL-XML will specify some
of that stuff.
 
> > 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.
> 
> As opposed to doing what?

AS opposed to calling it a mistake in the meta-stylesheet. Of course I'm
not saying that Netscape should pop up an error message, but a validator
should trigger an error message.
 
 Paul Prescod

Received on Wednesday, 23 April 1997 21:33:38 UTC