Re: The concept of cascading

Hakon, thanks for the reply about the cascade. The general impression I
get from your message is that the cascade is useful for many things and
the poor idea of merging two stylesheets that were not designed to work
together is sort of a side effect. But that's not at all what I read in
the CSS spec:

"One of the fundamental features of CSS is that style sheets cascade;
authors can attach a preferred style sheet, while the reader may have a
personal style sheet to adjust for human or technological handicaps. The
rules for resolving conflicts between different style sheets are defined
in this specification."

I think that the rhetoric of shared reader/author control should be
dumped. There is the problem of complacence that I mentioned before, but
also the more subtle problem that users should NOT be encouraged to
"blindly" merge their stylesheets with those of the authors. Even when
both parties are being completely reasonable this sharing could result
in information loss. It is a BAD IDEA. "Trust the browser." If you are
colourblind, use a browser (or GUI, or hardware, or device driver) that
remaps colours for you. If you are blind, ignore visual stylesheets and
use a browser that supports ACSS. If you have strong personal
preferences about colours, turn off author stylesheets and use your own.
By all means, take control, but take control with your eyes open: either
by turning off stylesheets globally, by fixing them on a case-by-case
basis, or by allowing your UA to do some form of post-process that fixes
it how you like it in a deterministic manner that is consistent from
stylesheet to stylesheet and, ideally, marked distinctively so that you
know what has happened.

It has been argued by multiple people that DSSSL absolutely must have a
Cascade to be as good as CSS. I have demonstrated that DSSSL has some
cascading mechanisms, but they are neither as complicated (in their
rules) nor as simple to use, (in the simple cases) as CSS's. In my
opinion, they pretty much presume that the author is working to make the
stylesheet cascadable. CSS works on the presumption, rather, that the
author is not, and that it must thus resolve "conflicts." But in
practice the author has all of the control at the beginning because it
is impossible to design a stylesheet in advance for a tag set or CLASS
set that you have not seen. 

This would not be a problem, but some people have got the idea of the
cascade tangled in their head with the problem of shared reader/author
control. The CSS spec. encourages this view. Actually, cascading doesn't
seem to have anything much to do with shared reader/author control. In
fact, there doesn't seem to me to be any one-size-fits-all solution to
that problem at all. I've argued on behalf of parameterization and
overriding as two simple methods for allowing readers to take some
control that do not involve complicated cascading rules. Overriding does
not require any particular language support at all: every major
wordprocessor allows it. My main point is: a vote against cascading in
DSSSL is not a vote against accessibility. I have no evidence that
cascading helps accessibility and have argued that it may hurt it by
making authors complacent.

Cascading is the only feature of CSS that I know of which does not fit
nicely into the DSSSL framework. In CSS every input element maps to
exactly one output object. I think this is a limitation that future
authors will find a problem. CSS can easily be extended to support
multiple objects per output object, and remain semantically a subset of
DSSSL (in fact a friendlier-notation subset), if only it were not for
the cascade. Without it, CSS and DSSSL could grow together as brother
and sister, working towards a common goal. With it, I believe that they
will always be competing for vendor resources and user mind-share
because their implementation, specification and semantic models will
always be quite different. 

I'm not saying that a CSS->DSSSL translator is impossible, but that the
output would be ugly and hard to relate to the input (for one thing, the
translator would have to "run" or "embed" the CSS algorithm to figure
out which rules apply when). We are so close to completely compatible
models that I think that this one feature is not worth two diverging
paths. One CSS concept which would be VERY ugly to implement in DSSSL
would be cascading choice of a flow object: you say that "LI" means
"paragraph", I say that LI means "List Item" and a complicated algorithm
decides who is right. OUCH! This is another result of making "flow
object type" just another property like "font size" and "background
colour".

Aligning DSSSL and CSS would take a major overhaul of the CSS cascading
mechanism. I think that we should undertake that overhaul. Before we do
so, however, we must know what problems we are trying to solve. Your
message has helped to clarify that. Now we can stop trying to solve
problems which are fundamentally not solvable through a cascade (such as
visual impairments, reader/author "balance") and concentrate on the
problems which are: mainly stylesheet "inheritance" and
parameterization.

 Paul Prescod

Received on Monday, 28 April 1997 05:27:17 UTC