W3C home > Mailing lists > Public > www-style@w3.org > April 1997

Re: The concept of cascading

From: Hakon Lie <howcome@w3.org>
Date: Mon, 28 Apr 1997 15:14:19 +0200 (MET DST)
Message-Id: <199704281314.PAA17085@www4.inria.fr>
To: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Cc: www-style@w3.org
Paul Prescod writes:

 > 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."

There is an underlying assumtion in the quote from the specification
that the style sheets have to be well-engineered, but this seems
hardly necessary to write out.

Badly written style sheets, or non-cooperarting style sheets will not
cascade gracefully with other style sheets, and you are correct in
trying to correct this view wherever you find it. What you should be
aware of, however, is that cascading has many other benefits and that
cooperating, well-engineered style sheets will offer benefits as
described in the above quote.

 > 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.

All these scenarios are possible in a CSS-compliant browser and the
cascading mechanism will be at work.

 > 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. 

I agree about tag sets, and some of the benefits of cascading is
linked to having a fixed tag set (which HTML has).

 > 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.

Sure, cascading has lots to do whith reader/author control. No,
there aren't any one-size-fits-all solutions.

 > My main point is: a vote against cascading in
 > DSSSL is not a vote against accessibility.

DSSSL has been designed with other goals in mind, and I'm not certain
that retrofitting a cascading mechanism would be the best solution.

 > In CSS every input element maps to
 > exactly one output object. I think this is a limitation that future
 > authors will find a problem.

Could you expand on this and give some examples?

 > Aligning DSSSL and CSS would take a major overhaul of the CSS cascading
 > mechanism. I think that we should undertake that overhaul.

The CSS1 specification is a W3C Recommendation that will not be
changed. Feel free to find inspiration in it, though :-)

Regards,

-h&kon

H      k   o   n      W   i   u   m       L   i   e
howcome@w3.org   W o r l d   Wide  W e b  Consortium
inria # FRANCE http://www.w3.org/people/howcome
Received on Monday, 28 April 1997 09:14:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:49 GMT