- From: Hakon Lie <howcome@w3.org>
- Date: Sat, 8 Nov 1997 20:48:36 +0100 (MET)
- To: Al Gilman <asgilman@access.digex.net>
- Cc: w3c-css-wg@access4.digex.net, w3c-wai-hc@w3.org (HC team)
Al Gilman writes: > The attached HTML document is an annotated table of contents for > the CSS2 draft. Thanks for your lengthy message. While scanning the document I found > [need to discuss] > > The style combining policy is too chaotic. It shows no > convincing regularity or smoothness. This is a problem for > accessibility, but not a special problem of those with > disabilities. It is simply a CSS show-stopper across the board. Since the section in question (Cascading, that is) hasn't changed from CSS1, I thought the enclosed message could be helpful by giving some background information. -h&kon >From: Hakon Lie <howcome@w3.org> To: Paul Prescod <papresco@calum.csclub.uwaterloo.ca> Cc: www-style@w3.org Subject: The concept of cascading Date: Fri, 25 Apr 97 21:18:22 MET DST Paul Prescod writes (amongst other things): > 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." This is certainly one aspect of cascading, but there are several others. Your line of argument indicate that you are not aware of all of them, so I take the opportunity to go through the concept of cascading. The CSS1 Recommendation [1] defines cascading, but the description [2] is very tecnical and does not try to justify the mechanism. Let's go back to 1994. The web is taking off, but there is no style sheet mechanism suited to hang onto the wild ride. Users typically have access to some X resources that will change fonts and colors. Authors are envious ("we want to be able to set colors, too") and are starting to do something devious to achieve their goal: they render text into images. Just to get into the right sort of mood, review this message [3] which posted to www-talk in early 1994: In fact, it has been a constant source of delight for me over the past year to get to continually tell hordes (literally) of people who want to -- strap yourselves in, here it comes -- control what their documents look like in ways that would be trivial in TeX, Microsoft Word, and every other common text processing environment: Sorry, you're screwed. At some point the author of the above quote, Marc Andreessen, changed his mind. But that's another story. Now, most of us believe that authors should be given a say in how their documents are presented (there are some extremist, but well-argued exceptions to this view [4]) and would like to offer authors better typographic tools than images. E.g., an author should be able to say "make the headlines red", and the language to express this preference should be relatively easy. Also, since red headlines is all that the author cares about, he or she is probably not interested in declaring which of the HTML elements that are to be rendered inline vs. block-level. In other words, submitting a partial style sheet is one of the requirements for HTML style sheets. Since the browser needs a complete style sheet in order to render a document, being able to combine several style sheets into one is a basic function. At a very simple level, browsers already did this before CSS was proposed [5] in 1994: the X resources of XMosaic were combined with a hardcoded HTML style sheet. What CSS did was to give this functionality a name and definition. Still today, I think authors would object to always having to remind the browser that 'B' elements are rendered in bold and that 'PRE' uses a monospaced font. One can argue that other solutions could solve the same problem, e.g. an "#include <>" mechanism that would include a "standard" style sheet. Including the content behind another URL at the lexical level is scary to those who believe in validation, but CSS of 1997 actually has a mechanism that achieves the same goal: "@import" will import the rules of another style sheet. To make it possible to override imported rules, locally defined rules need to be given a higher priority. This is done through the cascading mechanism in CSS. Again, another solution could probably have solved the same problem. But, since we already have the cascading mechanism we don't need to introduce another solution -- the extra rule ("imported style sheets have less priority than local ones") is simply added to the existing cascading mechanism. We're now in 1997 and style sheets are about to enter the Web. Designers are faced with the question: should I design with style sheets now, or wait till everyone has a CSS-enhanced browser? Is there a way to combine HTML extensions while still taking advantage of style sheets? The answer to the last question must be yes; in a transition phase it must be possible to combine HTML extensions with style sheets in a way that gives users of older browsers the required experience while CSS-enhanced browsers add that little extra. This requirement, however, poses some challenges. What if the extensions are in conflict with the style sheets -- which one should win? For example, what if the BGCOLOR attribute on BODY says red, while BODY's 'background' property in the document's style sheet says 'blue'? Many people involved in style sheets would say that the style sheet should win -- it defines the presentation of the document. Period. However, this policy would lead to many surprises and attribute authors would probably feel slightly annoyed by being consistently ignored. As always, the cascading mechanism -- and a proposal from Chris Wilson -- comes to rescue. By converting stylistic HTML elements and attributes into their CSS counterparts and inserting the newly formed rules into the right place in the cascading order (see [2] to find out exactly where), it is possible for stylistic attributes to coexist with style sheets. Feel free to design other methods to solve the same problem -- they're out there somewhere -- but cascading is very well suited for this job. At this point, since it's getting late where I'm sitting, I'll jump way ahead on the ambitiousness axis. There we find unknown, badly engineered style sheets cascading with each other producing screaming H1 elements rendered inline with a blinking orange background on A4 paper. Total chaos. Why would anyone design such a mechanism? Balancing unknown author and reader style sheets surely is a crazy construct -- the only more insane idea would be to actually <EM>blend</EM> properties from different sources [5]. Clearly, some people must have seen we were heading for disaster? Before concluding, here are some of the scenarios we missed when jumping: - the "author style sheet on/off" button - the "user style sheet on/off" button - the "style sheet on/off" button - the controlled intranet - the "style sheet hall of fame" - the "apply this personal style sheet whenever you see this author style sheet" button - the reintroduction of the 'magnify' property [x] - the gentle GUI between users and personal style sheets Bottom line: cascading is a versatile mechanism that serves many purposes. Including screaming H1 elements. [1] http://www.w3.org/pub/WWW/TR/PR-CSS1 [2] http://www.w3.org/pub/WWW/TR/PR-CSS1#cascading-order [3] http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1994q1.messages/643.html [4] http://www.hut.fi/~jkorpela/styles/harmful.html [5] http://www.w3.org/pub/WWW/People/howcome/p/cascade 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 Saturday, 8 November 1997 14:48:57 UTC