I think that it would be premature to standardize CLASSes until we see what
people want to do with them.
But Benjamin's concern is valid and common. Others are expressing it in
various HTML forums. They want their CLASSed text to be visually
differentiated ASAP. New browsers are coming out every month, but they are
no closer to differentiating between CLASSes of text, because they are
waiting for style sheets. Therefore people use HTML as presentation markup
and say they will change to style sheets "when they come out." Designing and
implementing a good style sheet language takes time, but people are impatient.
I suggest we develop a transitional style sheet format while we work out the
"real thing." We can call it "W3C Style Sheets version 0.5" or perhaps
"W3C Interm Style Sheet format" to indicate that something better is coming.
Alternately, we might want to keep style sheet version numbers in line with
HTML version numbers for simplicity. Everyone knows that HTML 3.0 is
coming, so they would assume that HTML 3.0 "style sheets" are coming too.
What people are clamering for, really, are simple font size, color and style
changes. We could also throw in some paragraph and background stuff. Our
unofficial (though not secret) mandate would be to provide functionality
roughly equivalent to the Netscape extensions. I do not think we should be
bound to Netscape naming conventions are specifications, however, or that we
should attempt bug for bug feature clone (i.e. BLINK). I think that we
should use them as a benchmark for when we are "done."
If we think we can work out the major issues and achieve file format upward
compatibility with 1.0 ("the real thing") style sheets, then that would be a
nice bonus, but I wouldn't want to hold back 0.5 while we try to work out
the fundamentals of addressing etc. If we need to make 0.5 and 1.0
incompatible, we could provide code to convert 0.5 to 1.0 that browser
writers could put in the browsers.
The CLASS and ID attributes should also be added to HTML as soon as possible
(HTML 2.1?). A useful style sheet language can be developed which does not
depend on them, but can use them when they are present.
For instance, if your document was strict HTML 2.0 you would say:
EM = BOLD
If it was (my proposed) 2.1, you could be more specific:
EM.[CLASS="Important"] = LARGE BOLD
LINK is already part of HTML 2.0. Browsers that do not understand the LINK
attribute should just ignore it. As I have shown, the style sheet language
need not require anything beyond HTML 2.0.
Once people are familiar with the interm language, learning the "full" one
is easier. They will understand why style sheets are useful, making them
more likely to seek out and master the new standard. The benefits of
authoring using style sheets are well documented.
Once browser authors have implemented simple style sheets, implementing the
"full" one is easier (and more likely). There is a danger that if we
present them with a complex and difficult-to-implement standard before their
users understand the benefits, both parties will just ignore it.
Style Sheet Group
The existance of the interm language would allow the style sheet group to
take more time and carefully think through the issues in designing the full
specification. They can also gather information about usage in designing
the full one. Users would be more likely to join the style sheet group and
contribute once they are familiar with the basics.
There are other benefits. I believe it would:
slow the creation of "tomorrow's legacy documents."
dispell the myth that the HTML WG is "against" presentation.
encourage the usage of CLASS, which would contribute to its usage in
robots and other software.
allow us to judge how people use CLASS so that we can think about
standardizing some usages.
increase the awareness of platform portability issues.
put the IETF and W3C back in the driver's seat with respect to the
direction of HTML and the Web.
Comments? Ideas? Should I present a more technical specification? I would
imagine the language would be a touched-up subset of the current CSS proposal.
Paul Prescod (email@example.com)