under-edited comments

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