One of the goals of CSS has always been to allow a separation between device-independent documents and their device-dependent rendering. This is one sense of the term "device-independence": nothing in the document even mentions device-dependent characteristics, such as color, border or sound volume. Another goal is to allow the same URL to always return the same document, independent of who or what issued the request. This is the second sense of device-independence. Other, related goals of CSS are to make the document independent from the reader's preferences and even from changes in the infrastructure over time.
The latter factor, time, is of course hard to design for, but the hope is that, even if CSS proves to be unsuitable for the Web in a few years, it can be modified or replaced, without changes to the document. Thus CSS is also a protective layer around documents, for the (common) case that the text is more important than the style.
The reader's preferences are handled by having the reader express them in the same language as the author, i.e., in the form of a style sheet, after which the reader's browser merges the two sets of rules. In fact, a third set of rules is taken into account as well, viz., that built-in to the browser. The word "cascading" (the "C" in "CSS") refers to this process of merging and overriding of rules from different sources.
It is noteworthy that the style sheet itself is not device-independent in the first sense, since it obviously talks about properties that do not exist on all devices, but it is device-independent in the second sense: the style sheet is the same, independent of who or what requests it. That is because the style sheet is not a rendering, but a recipe for a rendering. The recipe never changes, but the result will depend on the ingredients (the document, the device, the user's preferences...)
Level 1 of CSS gives the author the possibility to provide the reader with several style sheets, from which the reader may choose, but if the reader doesn't choose, the only adaptation of the style to the reader's environment is that the browser will ignore rules that don't apply. This still allows the designer a limited level of fallback. E.g., if the author specified the color red, with black as a fallback and if the device is monochrome, black will be used.
In level 2, there is the notion of classes of devices, such as 'screen', 'speech' and 'projection', which allows the author/designer of a document to create different styles for each class of device. But variations of devices within each class are still handled like in level 1, with the browser ignoring style rules that do not apply.
Usually this works well. Especially if the designer takes care to use "liquid designs," i.e., designs that don't assume a fixed screen size or specific font, but rely on relative units ('em', percentage) and that make use of floating boxes. Nevertheless, in level 3 there will be some extra parameters to distinguish devices within each media. E.g., whether color is supported or whether a (TV) screen has aspect ratio 4:3 or 16:9..
These so-called "media
queries" are not just for CSS. They can also be used in HTML and XML
whenever there is a media-dependent link. Two examples are the media
attribute in HTML and the media pseudo-attribute in the style linking PI for XML.
However, the media queries follow the general design of CSS: they must be
simple, allowing the average non-expert to solve at least 80% of the cases
that demand device-specific rendering. Although, like everything in CSS, they
are extensible, the syntax is optimized for simple cases, that require just
one or two parameters.
The concept of cascading is powerful and yet easy to use, but it has its limits. (It, too, follows the "80%-20% rule.") Obviously, there are documents where form and content are inseparable, such as certain types of art or jokes. But let's ignore those for the moment. To merge the user's and the author's preferences, the user and the author must each have a good idea of what the other specifies: there must be a limited number of dimensions along which things can vary. If adaptation of content to a device requires more than changes in style or hiding of less important parts of a document, but needs reorganization of the content, it becomes difficult to imagine how the author's transformations and the user's can be merged. In other words, if the style sheet contains XSLT, either the author's transformations or the reader's can be applied, but not both at the same time.
It is not only to achieve device-independence that CSS sends the rendering rules to the client, instead of executing them on the server. Other reasons are that the author cannot predict all the ways in which devices may differ, and thus the server cannot render for every possible device; and don't forget privacy and security: the reader may not want to tell his preferences or let the server know what hardware and software he uses.
Client-side processing also fits in with the goals of the semantic Web: give the client (the reader and his browser) as much and as high-level information as possible, and in an explicit form. The reader doesn't have to guess why something looks the way it does, but he can ask his browser to show the rules that the author provided. (E.g., Mozilla has a "DOM inspector" that lets you select an element and view the style properties and style rules that apply to it.)
Created: 22 Jan 2002. Modified: $Date: 2002/02/12 11:35:39 $