Re: Is DSSSL Hard?

Chris Lilley wrote:
> That would also have turned off the rest of the formatting. The only
> thing you didn't like was the links being in black. A one-line user
> stylesheet
> 
> a {color: blue}
> 
> would fix that. 
> Of course, the UA is free to offer whatever GUI
> interface it wants to let readers adjust their reader stylesheets.

Sure, and when I come to a page where where book titles are blue and
underlined, I'm confused again. What I need is not a cascading mechanism
but a simple UI for fixing broken stylesheet designs. I don't really
care if the underlying mechanism is X Resources, .INI files, CSS
stylesheets or DSSSL stylesheets.

> But equally, readers can use standard authoring tools to generate them,
> or copy other oners that they like.

Unfortunately it is fundamentally dangerous to have users writing
stylesheets in "FrontPage" and asking them to be merged with arbitrary
stylesheets on the web. This should not be encouraged. There is no
reader/author balance. Authors have all the control in the initial
document. Readers have all of the control in the final display. Trying
to arbitrarily merge their ideas according to the cascade algorithm will
result in something unpredictable.
 
> I think if we are arguing differences between a cascade and a selective
> override of part of a stylesheet then we are splitting hairs as these
> mean essentially the same thing.

I think of the cascade as being tied to the "reader-author balance"
idea. You specify some options, without looking at my stylesheet, I'll
specify some options without looking at yours, and we'll combine them
and the result will be "balanced." 

Rather, an override is: "This stylesheet *that I am looking at* uses
BLUE for these elements. <click> Okay, now I can see which construction
rule is making them blue. <click> There, now it makes them red." The UA
should remember that the stylesheet for this DTD has been modified and
when it occurs in the future the UA should use the author's version. 

The difference between parameterization and cascading (in my lingo) is
that parameterization is set up by the author, thinking of the reader's
needs.

The difference between overriding and a cascading (in my lingo) is that
overriding is done by the reader, while looking at a particular
stylesheet. Note also that overriding does not take any particular
stylesheet support. The UA can read the stylesheet, present the options
(in a GUI or whatever) and change the stylesheet as per the user's
request. No special language support ("cascade") is necessary.
 
> We can encourage them but not depend on it. Well-constructed stylesheets are
> designed to cascade well and to allow readers to cascade them well.
> Paramertrisation is similar except it requires the document author to have
> thought of everything that the reader might require; as you say, we cannot
> really do that.

In extreme cases parameterization will fail and the user must resort to
manual override: but they should only override with a particular
DTD/CLASS set/stylesheet in mind, not in the hopes that their half a
stylesheet will merge nicely with future half-stylesheets.
 
> > 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,
> 
> I think you just argued yourself in a circle

No, I'm talking about two different things. One is reader stylesheets:
stylesheets for particular document types (class sets) made with a
knowledge of how that document type works. The second thing I am talking
about is the post-stylesheet override that was also promoted by Scott
Preece and (implicitly) David Perrell. This post-stylesheet override is
usually done in X-resources, or the Windows 9t "Accessibility Options"
dialog, or the "Display Properties" dialog or whatever. I don't have a
problem with it being done there.

> There is a mechanism but it requires functionality which has not been made
> public yet. Sorry I can't say more. The mappings to cope with deuteranomaly
> (a type of constant-lightness reduced red-green discrimination) are however
> well characterised and it would be fairly straightforward to integrate this
> into a special color management step. 

That's what I'm talking about. A special step after the application of
the stylesheet. Now can we agree to remove deuteranomaly from the list
of accessibility problems that require cascading, because there is a
better (post-stylesheet) algorithm? We've already removed outright
blindness, because the original stylesheet is useless. We can also
removed near-sightedness, because a simple relative font scheme can
handle that, or else a post-stylesheet scaling as described by David
Perrell can look after it.

> I'm not entirely clear what you are proposing here. Instead of email, if
> you think this would be a real help why not write it up when you have time
> and make a Web page?

The idea is simple, and already in practice. After the user agent
applies the stylesheet to the data, it applies algorithms that take into
account the user's needs. For instance, presumably most browsers already
know when they are running on a black and white monitor and adjust their
display accordingly (or maybe they just depend on the GUI to do it).
You've described above how a UA could map one colour to the next
according to a person's colour differntiation problems. David described
how user agents can scale up font sizes according to a person's needs. A
"meta-stylesheet language" would just provide a portable mechanism for
describing which of these changes you need applied to the output of the
stylesheet process. But on thinking about it, I don't think we really
need such a thing. The combination of smart UA's, "X-resources",
GUI-level accessibility options etc. already do the job just fine. Once
again, we don't really need either overriding or cascading to solve the
vast majority of these problems. The UA can just handle it. A small
minority may have to be accomplished with plain ol' overriding.

 Paul Prescod

Received on Friday, 25 April 1997 11:17:16 UTC