Re: Is DSSSL Hard?

Chris Lilley wrote:
> My intent was to encourage you to show how DSSSL would implement support
> for the same color space that CSS uses. Is that possible?

Sure:

(define sRGB (color-space "-//W3C//Color-Space Family::sRGB"))

> Sorry if I am being dense. How? Can you give an example?

I don't think Jade supports cascading yet, so I can't test the syntax
I'm about to show you. It also isn't called cascading in the DSSSL spec.
Note also that the DSSSL file format is a meta-dtd so all element names
can be renamed.

<!doctype style-sheet PUBLIC "-//James Clark//DTD DSSSL Style
Sheet//EN"[
<!ENTITY main-sheet SYSTEM "http://www.foobar.com/stylesheet.dsl">
]>
<style-specification use="main-sheet" >

(mode user
	(element p (make paragraph ...)) ; this overrides completely
	(element emph (make sequence font-weight: 'bold (next-match)))) ;this
"rethrows"

<external-specification ID="main-sheet" document="main-sheet">

Now I can completely take over the processing of an element, as shown
above, or I can introduce a "wrapper" flow object to influence the
processing and then ask the stylesheet engine to try again. I would not
in general recommend that you use this process with stylesheets you are
not at least familiar with, but I would not recommend that you do that
with CSS either. In either case the interactions between the styles you
set and the ones in the "unknown stylesheet" cannot be predicted.
 
> Also "lack of completeness". I note that you added the term 'confusing' in
> there. 

I added the word confusing to the sentence above, but it seems like a
fairly accurate translation of: "Setting 'list-style' directly on 'LI'
elements can have unexpected results."

> My point was, is it true that DSSL is capable of defining an
> inheritance cascade or not and if so, how?

In DSSSL you have modes. Construction rules in modes are tried before
construction rules outside of modes. 
 
> > > 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?
> 
> To be able to read the document, if I have poor eyesight, or am blind, or
> can't distinguish red from green.

But none of that has anything to do with cascading! In the case of poor
eyesight, you want a user agent that bumps up all font sizes, no matter
WHAT the author says or HOW "!important" he or she thinks they are. You
certainly do not want to make a new cascaded stylesheet that overrides
every possible .CLASS in the world! It's impossible. The only practical
solution is a user agent that ignores what the stylesheet says about
colours and does the Right Thing for you. That has nothing to do with
cascading.

If you can't distinguish red or green you want your user agent to always
distinguish these two colours for you. Probably not just in text, but
also in pictures. Once again, you probably have better things to do with
your time than write a new stylesheet to fix every page that uses a
.MYGREEN style. I just ran into this problem with the document on the
W3C that used black underlines for hyperlinks. If I had to work with
that document for a while, I would have just told my UA "turn off this
stylesheet, it annoys me." That is very different from using "a cascade"
and writing my own stylesheet!

If you are blind ... I could go through the same list again, but I'm
getting very redundant. What does the ability to override styles or
stylesheets have to do with cascades? I can override stylesheets in Word
for Windows!!
 
> > How can you know what you want to override
> > before you've seen it?
> 
> The type size, for example. Perhaps you forget that the relative units
> in CSS let, for example, a well-constructed stylesheet base all sizes
> on the body text size. 

There's the key! "Well-constructed". If we can depend on authors to make
well-constructed stylesheets then we might as well just allow them to
parameterize them instead of having a complex cascading mechanism. And
if we can't depend on them, we're screwed anyhow, because it is trivial
to make a stylesheet that will totally break the UA's attempts to help
the reader.

> The reader can then make all the text bigger,
> or smaller, with a simple one-line stylesheet.

You can do that trivially in DSSSL:

(declare-initial-value font-size: 20pt )
(declare-initial-value background-color: (rgb 0 0 0) )
 
You don't need a complex cascading mechanism. I would only recommend
cascading (in either language) as a last resort after the UA has failed,
the initial values have failed, you've searched the web and there is no
useful stylesheet for the document type you are looking at etc. It is
just too fragile and random, in DSSSL and CSS. Plus it is a lot of work!

> > > 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.
> 
> Perhaps but hardly relevant since Panorama does not use DSSSL. 

Panorama also does not support cascading. My point: what does cascading
have to do with exchanging stylesheets?

> My point
> was that if DSSL cannot handle reader stylesheets, then users have to fall
> back on browser-specific preference files and suchlike which are not
> portable, as I said:

Reader stylesheets and cascading are two different things. DSSSL
supports both. I tend to think that the latter is a very blunt tool. The
first is a critically important device in generic markup.
 
> > > - 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.
> 
> If not true, show how the reader stylesheets can be implemented. If they
> cannot, we are back to preference files as argued above.

Reader stylesheet files are SGML documents that conform to ISO/IEC
10179:1996, Document Style Semantics and Specification Language. Whether
or not they cascade, they are not proprietary and they are not
preference files.

On the other hand, the mechanisms I have argued for above would go into
a preference file, whereby a user agent might totally and completely
ignore what a stylesheet says in certain areas, such as colour and font
size. But you haven't yet explained how I can make a stylesheet that
will cascade wonderfully and turn all greens into reds. 

That could only be done a) with a smart user agent or b) with a
meta-stylesheet-language that mapped input structure (SGML) to
intermediate styles (author specified formatting) to output styles (user
specified overrides based on formatting characteristics). In that case
the elements in the input document are irrelevant. I would probably
support a W3C effort to make such a meta-stylesheet-language. It could
be applied to the output of a DSSSL formatting process or a PDF file or
whatever.
 
> > 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 - using stylesheets or magic non-portable files, X resources, etc?

Exactly! Unless you have an idea that works, that's what I'll do. CSS
cannot do what I am asking it to do. It absolutely cannot turn all
occurrences of "red" to "blue" or "12pt" to "24pt". A smart user agent
could do that for me with X resources or something. A
meta-stylesheet-language could do that for me. Neither DSSSL nor CSS
can.

Anyhow, why the Jihad against X resources? We're talking about an
inherently personal issue, my own perception of colour. Why do I want to
share that with everyone in the world?
 
> > 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.
> 
> But without a cascade this has to implement the whole thing and will give a
> generic presentation.

No, you can override construction rules (as mentioned in the paragraph
above).
 
> > 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,
> 
> Hmm.. 'I don't understand it so it won't work?' I take it you mean
> something else.

Well, I've asked several times in this discussion how it is supposed to
work. How the cascade is supposed to be more useful to blind people than
starting from scratch, how colourblind people can override all the
occurences of the colour they can't see. And how they know when that
colour is being used to differentiate things? How near sighted people
can override all small fonts. It isn't possible. It must be done in a
"meta-level", either by a smart UA or a meta-style-sheet-language.

> > so I prefer the series of mechanisms that are tried and
> > true: well known DTDs, strict validation, public identifiers,
> 
> I have seen no evidence that FPIs have helped solve a grewat deal on the
> Web.

No, FPIs are not rolled out on the web. I guess URLs are basically as
good as FPIs for what I am discussing, though. A single global name for
the document that describes the structure of the document you are
looking at: the DTD. Once you have that, the UA can recognize when a
stylesheet you already have will fit the bill: "Oh this is DocBook -- I
know how to deal with that." As I said in my last message, we must teach
XML and HTML users that CLASS and <!ELEMENT > are not a license to throw
away standardization. They must use existing, established DTDs whenever
possible so that they may benefit from the "accessibility
infrastructure" (special stylesheets, documentation, etc.).
 
> > What does that have to do with the cascade?
> 
> In the part you deleted was your question asking what authors would bother to
> implement ACSS stylesheets and the part you quote above was the answer.
> If you don't see what reader stylesheets have to do with the cascade then
> you need to read the relevant part of the CSS1 spec again.
>
> > What is the value to a blind person
> 
> I note you omit the 'print disabled' part and it is they who will benefit
> form the cascade the most. I agree that for people who want aural-only
> presentation in the case where the author stylesheets are visual-only the
> cascade comes down to throwing out the author stylseheet.

Okay, I'll bite. How does a print-disabled person using ACSS benefit
from the cascade? Presumably they have an ACSS stylesheet (that they may
have had to write themselves) and a visual-only stylesheet. How does the
ability to "logically" merge these into one stylesheet on their home
computers help them? DSSSL can do it too, but it doesn't seem like there
is any benefit over just having two stylesheets, one applied to print
and one applied to online.
 
> > The DSSSL spec does not specify. It is a language for attaching visual
> > semantics to documents and not for specifying user agent behaviour.
> 
> Hmm. You are saying that DSSL is uaable to handle the case of a browser
> window resize? It has no dynamic properties at all? I suspect that is
> not the case.

I said that the DSSSL spec does not specify whether the user agent
should re-evalute the whole DSSSL specification, or re-evaluate only the
(display-size) parameters or report an error message: "Sorry you can't
do that." The DSSSL spec does not use the words "browser" or "user
agent" anywhere. There are no descriptions of what a user agent must do
at all. Anyhow, (display-size) returns a special object of type
(length-spec) which is not just a quantity, but a "magic cookie" that is
passed to the "back-end" (of course the DSSSL spec does not discuss
backends either). Any browser with half a brain would keep the magic
cookie and reevaluate the characteristics that depend on it rather than
the entire document. 

I just wanted to make clear that the ISO DSSSL standard is not a
standard for applications, but for the visual semantics of the result of
combining a document and a stylesheet. So where a W3C spec (like,
perhaps, DSSSL-XML) would say something like: "When the link is clicked
the user agent must display the document whose URL ..." DSSSL would say:
"A link flow object represents a hypertext link that can be
interactively traversed, typically by 
clicking on the areas representing the flow object and its content."

> > AS opposed to calling it a mistake in the meta-stylesheet.
> 
> That is a fundamental difference of approach on the Web as opposed to
> the academic-oriented document processing research community. 

:) I wish that I could get money for document processing research!
Unfortunately most of the movers and shakers in the SGML world seem to
be out on the street chasing filthy lucre! Now everybody knows that
everything important in the computer graphics world happens in a
university lab somewhere. =)

You can specify that something is an error (in this case, that you
should not be able to make something bolder than the boldest) without
requiring user agents to report the error to the user. In this case, I
think that I would have just required the user agent to visually
differentiate the text somehow else, with underlining, or colour or
something. The differentiation is more important than the type of
differentiation, since the content is more important than the particular
type of presentation. That's the philosophy, right?

 Paul Prescod

Received on Thursday, 24 April 1997 00:13:19 UTC