Re: The concept of cascading
Hakon Lie wrote:
> > "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.
Is it not the case that *well-written* user and author stylesheets can
merge in ways that will lose data? I can think of several examples where
two reasonable people could make stylesheets that negate each other in
ways that lose information. That's why I think that it is wrong to even
encourage people to merge reader stylesheets and author stylesheets
> > (1)If you are
> > colourblind, use a browser (or GUI, or hardware, or device driver) that
> > remaps colours for you. (2)If you are blind, ignore visual stylesheets and
> > use a browser that supports ACSS. (3)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: (2)either
> > by turning off stylesheets globally, (4)by fixing them on a case-by-case
> > basis, or (1)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.
I've labelled the scenarios above. (note that there are repetitions)
Could you please explain how the cascading mechanism will be a work? I
propose that they could all be either a) accomplished in a stylesheet
language with no cascade mechanism *and no special replacement for it*.
In other words, a language that is strictly a subset of CSS or b) not
accomplished in CSS.
(1) Browser remaps colors or fonts (blues become yellows, for instance,
no matter what the classes or elements in the input document) I do not
believe that CSS can accomplish this -- this is just a browser feature.
(2) Reader ignores visual aspect of stylesheet and uses only aural
aspects I believe that a strict subset of CSS without cascading could
(3) Reader turns off author stylesheets and uses reader stylesheet. This
is just a browser feature: it has nothing to do with the stylesheet
language being used.
(4) Reader modifies author stylesheet (by hand, or through GUI) to tweak
it for their special needs. This is juat a browser feature: it has
nothing to do with the stylesheeet language being used.
> > 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).
Sure, if you don't use CLASSes. But people do and will. So in practice
those benefits of cascading are probably not forthcoming. If you can
depend on people to stick to a single tag set then the whole
accessibility issue becomes trivial: Lynx et. al. do a good job with
fixed tag sets.
> > 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?
Sure: I want every <DIV CLASS=SECTION> to have a horizontal rule with a
particular graphic image before it and a hyperlink to the top of the
document after it.
> > 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 :-)
CSS1 is fixed. It can be superseded however.