Bert Bos
Cascading Style Sheets tell how to translate a digital document to human media
em { font-style: italic }
em em { font-style: normal }
h1 { font-size: 150%; color: red }
p.note { margin: 2em; text-align: left }
Currently most support for screen-based display, but paper, speech, etc. also possible. CSS also works for styling vector graphics (SVG)
CSS works best with documents where the semantics are to a certain extent independent of the way the document is presented. This holds in fact for a very large class of information: the same text can be presented with different fonts and different colors, on different media and the user gets more or less the same information from the document in all cases.
Principles:
These principles lead to a an attractive and very usable style language, but at the same time they impose limits on the power of the language. Especially the simple syntax (suitable for hand editing as well as WYSIWYG/Direct-Manipulation) and the cascading limit the expressive power. Documents that need to be transformed or that need complex layouts that cannot easily be expressed by drag-and-drop or by menu selection will have to use something else. That something else can either be something that combines with CSS (XSLT) or something that replaces it completely (XSLT + XSL-FO).
Some of the things that CSS cannot do (except in some very simple cases) are:
For example, you can display an RDF file, but the result will still look rather "technical." You will probably want to transform the file to something with more text and a different order (or maybe to a diagram, using SVG) before applying a CSS style sheet to it.
Expanding functionality:
Better media support:
CSS level 3 will contain many enhancements over level 2, especially in its support for non-Western typography. Vertical text will be possible, as well as CJK-style grid layout, ruby annotations, Arabic line justification by stretching, alignment of Indic scripts with other scripts, etc. But there will also be improvements in printing (page numbers, headers and footers, columns, etc.), form layout (to support XForms, in particular) and audio & speech.
There is too much too explain it all in 20 minutes, and therefore I won't. Instead, the talk concentrates on another development in CSS: style sheets targeted at specific devices and media. "Profiles" help to ensure that implementations have an interoperable core of features, that a designer can rely on. The "Media queries" allow a designer to be more precise in what style rules apply to which media. They allow conditional rules in cases that the variations between devices is so great that the normal fallback rules don't give a satisfactory result.
Some of the functionalities under development:
For simplicity, all media in CSS level 2 were "mono-media": a browser that implemented the visual properties was not supposed to apply the aural properties at the same time. The aural properties do not apply when the type 'screen' (for desktop screens) is in use and, conversely, visual properties do not apply to 'aural'.
But we know that desktop computers can make sound as well, and some browsers allow HTML pages to emit sound (although to a very limited extent). Thus it makes sense to use the experience gained with CSS so far and the increasing power of computers to define multi-modal media. E.g., elements can have sounds attached to them that play (once or continuously) when the element is visible. State changes, such as activation of a hyperlink or hovering a mouse over an element, can also have their own sound effects.
W3C has in fact just started a new working group whose specific task is to develop ways to allow multi-modal input, such as combined keyboard and voice input to forms. And of course there already are two versions of SMIL, the multi-media synchronization language. But they serve different purposes.
Browsers are notoriously bad at printing. What comes out is readable, but usually far from beautiful. The properties for printing in CSS 2 were basically limited to a control over page breaks, but of course much more is needed, e.g.: columns, page numbers, footnotes, running headers & footers and cross-references.
CSS has so far mostly dodged the question of styling interactive elements, such as menus, buttons and input fields. But with the arrival of XForms the issue becomes urgent. XForms elements are abstract and need a style sheet to determine their look. The "selectMany" element of XForms can be shown as a menu, a set of checkboxes, a scrolling list or other things. It only specifies the functionality (select from a list of predefined items), but not the user interface, which may differ widely based on the environment.
XForms defines some "pseudo-elements" that CSS can use, but we probably need more: new layout models, complex boxes, boxes with three or more states, etc. The work is by no means ready yet.
Non-Western typography was already mentioned. The description of the new properties forms quite a voluminous specification and implementers that want to support multiple markets will have some work to do. That's not the fault of CSS, of course: typography happens to have many different traditions. However, most people do not write in more than one or two scripts at a time, and thus the size of that module should not affect them too much.
The levels (1, 2, 3) of CSS are similar to profiles, but not tied to media.
CSS 3 is quite large, because it contains properties for many different media and some very advanced functionality. We don't expect many implementations of the whole of CSS 3 (except such implementations as the CSS validator and non-WYSIWYG editors). On the other hand, we expect the profiles to be implemented in full and with far fewer bugs than we have experienced with CSS 1 and 2 implementations so far.
A W3C Candidate Recommendation since Oct 2001
There will be a new version that includes relevant parts of CSS 3 once they have become W3C Recommendations
A mobile device clearly has limitations relative to the desktop computers most people are familiar with. It can display text and graphics, more and more also color, but it has limited memory, small screens and slow processors (if not for technical reasons, then at least for economic reasons). Some of the more "expensive" features, such as absolute positioning and generated counters, are therefore left out.
The WAP Forum specifies that all WAP-compliant phones must implement everything in the "Mobile profile 1.0," but it also adds three extensions that are not (or not yet) in CSS. Two of them (marquees and access keys) are expected to be in CSS 3 (and will then also be in the next version of the "Mobile profile"). The third one (input format) may become part of some other W3C format instead; XForms would be a good candidate.
A W3C Working Draft since Dec 2001
The next and last draft is expected this month (May 2002) and the W3C Candidate Recommendation in June/July
A TV has a larger screen than a handheld device and the electronic parts don't need to be as light and small. They may consume more energy as well. On the other hand, price and reliability are important factors, and thus here also it makes sense to not require too complex features.
Just as for the WAP case, we expect standards for digital TV to include the TV profile, but also add some extensions that are not, or not yet, part of CSS. Those standards are not made by W3C, but by three or four other consortia, and it is often impossible to get agreement on all the required pieces within the time frames of each standards body ☹.
A W3C Working Draft, latest Jan 2002
E.g., a style sheet only to be used on a color printer:
<link rel=stylesheet href="cprint.css"
media="only print and (color)">
(XML is similar) Or from CSS:
@import "cprint.css" print and (color);
CSS has always had some shades of a constraint-based model. The way boxes are sized and positioned is described by a set of constraints of different priorities that balance the influences of the contents of an element, the surrounding elements and the properties set in the style sheet.
When the CSS working group was started within W3C, there was a workhop where different approaches to styling where shown, including one that was based completely on constraint resolution. Constraint solving is a very elegant model, once you get the hang of it, but not everybody gets the hang of it and in its full generality it may also be too slow for real-time browsing. CSS has therefore mostly tried to keep to a model where following elements do no not influence earlier ones.
Then some time ago, in 1997 to be precise, there was a paper by Alan Borning, Richard Lie and Kim Mariott at an ACM conference that described constraint-based style sheets. Greg J. Badros, Alan Borning, Kim Marriott and Peter Stuckey went on to define "CCSS," showing how CSS could be extended with a fairly simple way to make a whole style sheet conditional on a constraint. They made a prototype implementation in Amaya, that was shown at the 1999 Web conference in Toronto.
CCSS included more than constraints on whole style sheets, it also allowed constraints within individual style rules, but those have so far not been taken over by the CSS working group (although every once in a while some aspects of them are discussed again).
Recently, while working on profiles for different media, it became clear that there were such differences between user agents on one and the same media (there are "handhelds" in all shapes and sizes, e.g.), that we needed a way to specify more than just the media type when selecting a style sheet. Thus "media queries" were born, using the same idea, though a different syntax, for adding a constraint to a style sheet. In this case, the constraint can be put on the '@media' and '@import', as well as the "media" attribute of HTML.
The extra keyword "only" is necessary in HTML, because the "media" attribute in HTML wasn't designed to be extensible, like the @media and @import declarations in CSS. The "only" will cause old HTML implementations to properly ignore the link, while a value starting with the keyword "print" will not.
In CSS, the "only" may be added for aesthetical reasons, but it has no meaning.
CSS also allows to combine style rules for different media in one file, by means of the @media declaration:
@media print {
... rules for all printers here...
}
@media print and (color) {
... rules for color printers here...
}
@media tv and (scan: interlace) {
... rules for desktop screens here...
}
Small number (probably 11). E.g.:
Most accept prefixes "min-" and "max-"
print and (min-resolution: 300dpi)
(= "printers with 300dpi or more")
The features can be used without a value, e.g., "(color)" or "(monochrome)", to test for the presence of a feature, or with a value, e.g., "(color: 8)" or "(monochrome: 4)", to test both the presence and the level (in this case the number of bits per pixel).
Many features will make most sense with a prefix of "min-" or "max-", to express the limits within which a style sheet applies. E.g., to express that a certain style is meant for handhelds with screens of between 200 and 500 pixels wide, one can use
handheld and (min-device-width: 200px)
and (max-device-width: 500px)
Media Queries are simple to write. A style sheet author can easily list the features he needs: there aren't many to choose from anyway and the syntax is simple. Writing a JSP, PHP or similar server-side script to adapt a style sheet based on a device profile is harder.
Writing a device profile is hard, but it should usually be the maker of the device or of the browser that creates the profile. Some parts of the profile come from the preferences dialogs of the browser. Sending a device profile also takes some bandwidth, but it shouldn't happen very often: the client can send a pointer to the profile and the server only retrieves it when it is not in its cache.
If there is only a small number of style sheets, the most efficient way is to write all of them once, attach a media query to them (either in the CSS itself or in the HTML or XML that links to them) and then let the client select the appropriate one. There is no load on the server (or not more than for any other static page), because the client does the matching of device profile against media query.
On the other hand, if there is an infinite number of style sheets (e.g., one for every size of screen), then the style sheets have to be generated on the fly by the server, based on the device profile. But this should be a very rare case. CSS is flexible enough to express most "liquid layouts" (layout that adapts automatically to the size of the screen).
The most important benefit of Media Queries is that they allow static resources: the client requests the resource it wants by URL and the server doesn't need to adapt the contents based on who or what is requesting it.
In the case of device profiles, the client only knows one URL and the server has to send different contents for that URL, depending on the profile of the client that requested it. The same URL means different things to different clients. For example, a store-and-forward system, such as a search engine that indexes pages without knowing what kind of clients will connect to it later, has no way of knowing what resources are available, since it is impossible to generate all possible profiles. With Media Queries, the search engine would know exactly what resources are available, and can pass that information on to its own clients.
A common case of store and forward occurs when you want to print a page after having looked at it on a screen or maybe on a handheld device. If the style sheet came with media queries, the browser knows whether it has all the style sheets it needs for printing, or whether it has to get additional ones. In a device profile-based system, it has no option but to request the same document again, but with a different profile.
The "road map" for CSS 3:
http://www.w3.org/Style/CSS/current-work
This talk:
http://www.w3.org/Talks/2002/0509-CSS-WWW2002/all.htm
CSS is still being enhanced with new typographic features. Level 3 will support vertical text, hyphenation, columns, Indic scripts, and many other improvements. This talk, however, focusses on a different development: profiles of CSS for specific media (handhelds, television) and ways to target style sheets to specific devices (media queries).