Style sheets are complex and quite incompletely defined, and not implemented yet in general. But in addition to such problems, the style sheet approach is fundamentally on the wrong track. It works in the direction of preserving author-controlled layout. It just tries to prevent author's control from having too harmful effects on the HTML language. It provides new and more structured layout design tools - to authors. It is the right way of doing the wrong thing. Readers' control over layout cannot be harmonically combined with author's control over layout, and since layout is a physical thing, it should be designed for the physical device, and for the individual user. Style sheets ultimately work in favor of postponing the necessary change towards control by readers.
Fortunately the work on style sheets has produced useful material for defining one way in which the reader might control the layout. For this purpose the cascade concept must be removed, the specifications simplified syntactically and elaborated semantically, and serious modifications to the HTML language - adding structural features and removing layout attributes - must be considered.
For example, instead of standardizing vendor extensions to HTML for specifying the background color of table elements, the Cascading Style Sheets, level 1 (CSS1) specification provides a general method for specifying the background color for any element. Style sheets even make most HTML element attributes, such as ALIGN attribute and the attributes of BODY, quite redundant, since the same effects plus a lot more can be achieved using style sheets.
The language used in style sheet declarations is sufficiently different from HTML to carry the message of separating structure (expressed in HTML) from presentation (expressed in style sheets). On the other hand the language is almost intuitively understandable. Anyone who has elementary knowledge about HTML will probably realize without saying that a declaration like
BLOCKQUOTE { background-color: yellow }
says that BLOCKQUOTE elements be presented so that their background
is yellow. (Of course some study of the style sheet language is needed
to be able to write such declarations.)
Consider the very basic issue of style sheet preferences, or cascading order in CSS1 terminology. The cascading order rules in CSS1 can be roughly presented as follows: the precedence order is
!important declarations
!important declarations
Within each of the above-mentioned categories, there are additional rules of preference: complicated specificity rules are applied, involving a special treatment of declarations in STYLE attributes of elements. Ultimately, the textual order of declarations in a style sheet is taken into account to handle conflicting declarations. This means of course that there is very little semantic checking that can be applied, since conflicts cannot be treated as errors.
The complexity of CSS1 results, you may say, from the necessity of guaranteeing author-reader balance. But when people refer to the need of such balance, they just use the word balance to avoid the tough questions. Either you let the user have the final word or you don't. Either you use logical markup and not physical or you don't.
The idea of authors and readers somehow jointly setting up the presentation ignores the fact that good style is not just a sum of "style" selections for various features. Moreover, it is utterly unrealistic; readers can, at most, be expected to select the presentation for a few dozens of different logical structures (HTML elements) in general. Not to map, say, pink color into some font, without knowing why the author suggested pink color. And the "why" question should logically be expressed by using logical markup, avoiding any particular colors.
What will most probably happen
is that when people have found out that their own style sheets,
whether as author or as user style sheets, are not honored, they
will flag everything
!important. Since there is no true balancing -
preference is given to author style sheet - some users will simply accept
the situation and take what they get, discarding the idea of user
style sheets. The rest of the users will turn style sheets off, since
this is their only way of getting the final word. This brings us back
to the time before style sheets, but with added confusion.
Consider the typical example of declaring the background color for some element. There is nothing in the CSS1 specifications that says how this should really be done. Most people will just write a background-color declaration and think they've done it right. They won't even care about setting text and link colors as well, since no official specification requires it and no commonly used software warns about not doing so. Even less will they give any thought to the complicated issue of nested elements having their own color declarations from various sources.
It has been argued that some presentation issues, e.g. selection of fonts on one hand and selection of colors on the other, are orthogonal in the sense that you can do the selection (relatively) independently of each other. But consider the following simple example. Assume an environment which has a lot of colors but only a single font. One would probably like to use (different) colors for several purposes like headings, emphasis, block quotations, elements like VAR and CODE, etc. Then assume another environment which is rich in fonts but just black and white. Now if an author has provided a style sheet specifying some particular background color for his examples, and if there is a need to separate examples from the rest of the text clearly, this would fail - because the style sheet model is too concrete. (What was really needed is a standardized element for specifying that we have an example here, letting each environment and user decide how to present such elements in general. Style sheet ideology works against such reasonable improvements to HTML, since they promise to deal with the problem in other methods.)
HTML specifications have mostly been attempts to unify common practices in browsers and to find greatest common denominator. But the interpretation of CSS1 has no similar background, since it is intended for directing the development of browsers (which in itself is a good approach). Therefore, unambiguous and easy-to-read semantic descriptions would be crucial in CSS1. What we have is syntax specification (in an ad hoc formalism) plus a few sentences about their meaning.
The descriptions of the effects of individual declarations, taken in isolation, are usually satisfactory in the CSS1 specification. The problem is that their interplay is described vaguely, if at all.
Consider colors, for example. Obviously if I define a background color
I should define text color and link colors, too, to avoid the unhappy
situation where the text color (from some other style sheet) coincides
with the background color I have defined. But this is not enough.
Suppose I define white background for normal paragraphs (P elements),
yellow background for quotations (BLOCKQUOTE elements),
pink background for ADDRESS elements, etc. Assuming that I wish to use
red as text color, I must declare it cleverly. The obvious solution of
defining BODY { color: red } does not work in general,
since my reader might have background-color: red
for some element which is used by me but not taken care of in my
style sheet, since I don't care. Thus, in practice both authors and
readers should be very careful and assume the worst about each
other's style of using styles. It seems that the current style sheet
model provides no easy way to formulate practical rules in order to
avoid such conflicts.
However, the flexibility of CSS1 has a high price. You could, and you probably would, easily define classes for various purposes, such as declaring some texts as warnings by attaching, say, CLASS=WARNING to them and declaring some prominent presentation (say, blinking red) for them. Effectively, you would be extending the HTML language with an element for warnings - but you would do it in your personal way. A user who wants to have warnings presented in some other way couldn't specify that, except very clumsily on per-document basis after looking at your HTML code!
Conceivably, conventions and standards might be developed. But since this issue really deals with structure, not presentation, it should be treated at the HTML level. If new structural features are needed, then HTML should be extended. And even if we really wanted to have a hypertext markup language which is flexibly extensible by authors, the extension mechanisms should belong to that language, not to a language for mapping that language into visible presentation.
Some of the above-mentioned serious problems could be alleviated by modifying and clarifying the specifications. However, inherent and unavoidable difficulties would remain. CSS1 is based on thinking which has very good aims and which inevitably leads to disaster. Perhaps the designers of CSS1 thought that the "visualists" should be given toys to play with so that they will stop playing with adults' tools (HTML). This will fail; they will take the toys and still continue using HTML constructs for layout purposes.
The key idea of supporting both author and user style sheets fails to accept the essential nature of the World Wide Web as a medium.
The traditional system of publishing, applied in newspapers, books, TV programs, etc, involves the preparation of a publication up to the smallest detail, including layout, by the authors (in the broad sense, including a lot of technical and artistic staff in many cases). Once prepared, the publication is reproduced in some sort of mass production, i.e. identical copies are issued. The role of the consumer is to take it or leave it. This paradigm has already been challenged by factors other than Internet, e.g. the feasibility of print on demand. The paradigm was applied for obvious economic reasons.
On the Web, each access to a document by a user involves customized formatting according to users' screen, browser, option settings, etc. Moreover, publishing takes place every day and everywhere, with no definite publication dates. The difference between a simple personal home page and some popular document is not technical - both could be single HTML files and accessible to anyone on the Internet. There are no strict borders - a document can slowly move from one extreme to another as it becomes more interesting and known to people. Copies of the publication can be made at ease, typically one at a time, and in greatly varying forms. In addition, the contents of a publication may vary, since the author may update it or the user may customize even the contents e.g. by requesting some HTML elements to be ignored. In the future, publications themselves may support customizability.
The common idea of designing Web pages with newspaper-like format is therefore inherently archaic: it binds itself to a primitive system of mass production of copies, and that system doesn't even work, since people do not use the same kind of hardware, software, and settings as the designers. (It would be impossible to do that, because different designers work on different systems.) Far from being progressive, it essentially takes the limitations and features dictated by the old medium to a new one. It is, in a deeper sense, similar to putting typewriter-style text (within PRE element) onto the Web. The products of ambitious "visual design" on the Web usually don't even pass the simple mouse test: take the mouse and modify the size of the browser window horizontally and vertically.
De gustibus et coloribus non est disputandum.
The above-mentioned traditional paradigm of publishing will soon be considered as a necessary evil which is no more necessary. It was, during a few centuries, necessary for economical reasons to issue publications in thousands or even millions of identical copies. But it was contrary to the basic nature of human communication; human beings are different, they live in different environments, and they need and prefer different methods of presentation.
People employed or otherwise involved in traditional publishing presumably feel uneasy, and not without reason. They are accustomed to seeing their job and professional competence as important and essential in publishing. Now they are faced with the situation where the careful and detailed design of layout is not only unnecessary but also harmful.
Layout will not lose its importance but it will take place on users' workstations. A user, that is a customer, will have his own layout preferences and styles, with colors and margins and fonts and so on, perhaps designed by a professional, but anyway selected by him to suit his personal preferences. Any layout by the author or by the publishing side will just not get through; an attempt to enforce it will fail miserably, since if a document is not formattable according to user's specification, it will look like a mess and the user will therefore discard it.
What is left to the author is the production of contents and structure. This has always been the author's most essential job, and it should be regarded as a relief that the author neither can nor need care about presentation issues.
Let's have a dream. Suppose that I'm starting to read a real newsdoc (that's my neologism, a structural, device-independent counterpart of newspaper) using my Web browser on the screen (or as printed out on my printer, if I prefer that). The browser will obey my presentation preferences and format the entire newsdoc according to them. My personal preferences are irrelevant here, but they might include the following: display first a table of contents in pure text form, with the most important items (as designated by the editor, using structural markup) first but otherwise all headings in thematic order; text in single column, 130 mm wide; images aligned to the left, never alongside with text; video clips in separate window, to be started on my command only; background music, if suggested by author, to be started automatically but with low volume. Alternatively, when tired or doing some cooking, I might ask my browser read the headlines to me, and I'd whistle when something is so interesting that I want to hear the entire text of an article. You might have entirely different preferences - and get them obeyed.
Exactly because visual presentation and other external expressions of the contents of a document are so important, it shall be left to the customer (who ultimately pays the bill, by the way, either as paying customer, taxpayer, or target of advertising).
"Contents and structure" does not mean plain boring text with a few different types of headings. Contents includes figures, images, photographs, formulas, music, videos, and lots of other forms of communication, most of which have not been invented yet. Structure is not only a simple hierarchical division into sections and subsection; it includes the relationships of various kinds and pieces of contents with each other and with the contents and structure of other documents. And what looks like an ordinary page of text would, in this new mode of thinking, actually be structured as a rather complicated entity; it might contain quotes from other texts, mathematical and scientific symbols, emphasized parts, less important parts, unordered and ordered lists of things, and so on. Depending on the user and his environment, the various elements might each have its own style of presentation, or the entire text might be just plain text in one font, or something between the extremes.
This way of thinking does not mean that you should, as a general rule, just divide the document into parts according to the internal logical structure of the subject matter and fill this hierarchical, analytical structure with text contents. Even less does it mean that you take a long piece of plain text and put a few headings (like Introduction and Test arrangements and References) here and there. Such a paradigm of document authoring seems to be dominant in the production of research reports and many other papers, and it may have a restricted area of applicability. But the normal way should be to pay a lot of attention to
Thus, journalists may still have jobs. In fact, they will be desperately needed - but only if they are able to adopt entirely new forms of expression. They will have to learn to speak fluent HTML. They will lack fonts, colors and layout; they will have to concentrate on the structure and contents. This means, inevitably, that they will have to learn to think and communicate more abstractly. Of course they will not be writing HTML 3.2 but something that resembles it. Their language will be a lot richer in expressions for structural relations, and it will lack expressions for presentation issues.
My answer to this is that by attaching style sheet declarations into your documents you support and encourage the principle of author's dominance over presentation. And in practical terms you gain very little. Most browsers do not support style sheets yet, there is no guarantee that they will do and do it correctly, and in particular they might discard the difficult concept of cascade - but just in the wrong way, ignoring user declarations.
A common motivation for setting up some particular layout for Web pages is the need for uniformity, "company look". (The word company should be understood generically here; it could equally well refer to an institution or even a private person.) There is a good point behind this idea. When I visit a lot of interlinked Web documents, I would very often like to see, at a glimpse, where I am in terms of page owner and officiality.
But "company look" is not the right answer. It makes the recognizability of pages dependent on presentation, which in any case varies a lot. And a "company look" says nothing to a casual visitor who sees it the first time. The HTML language should be made more structured, and this includes requiring the presence indispensable metainformation like source, author, officiality, language, abstract etc. The key question is not how the author could provide a company look but how the reader can check what company the information comes from and have this displayed in a manner the reader likes. Some users might prefer seeing a company logo on each page (and for this purpose the address of a suitable logo might be one part of the metainformation); some others might prefer just the company name since they think logos are usually awful; occasionally one might even wish to have the company main page displayed in a separate window alongside with each document from that company; and still some other might let such information to stay on the background, to be popped up when desired.
Finally, one may argue that if document layout is left to browsers and users only, each browser will have different aspects of presentation that can be controlled by the user and different methods of doing it. In a sense, each browser would have its own syntax and semantics for (users') style sheets. My reply is that this need not be more disastrous than differences between browsers in general. Moreover, why shouldn't it be possible to standardize this? The style sheet model would be essentially simpler than the cascading style sheets concepts, so it should be at least technically more easily standardizable.
The document Publishing on the Web Is Different is essentially an extract from this document, presenting the basic idea of reader control in a more general context.