The Web is based on URLs. Unfortunately, URLs have to do double duty: they serve both to locate and to identify resources. This is unlike, for example, the Domain Name System (DNS), where numbers are used for location and names for identification and which allows names to remain constant while the numbers change. It is also different from a library catalog, where the location is based, again, on numbers, but the identification has multiple dimensions (author, title, subject, year, etc.), that can be combined for the desired level of precision and robustness.
While waiting for the problem to be solved on the Web, it is best to keep URLs as stable as possible. One of the tasks of CSS is to help with that, especially in cases where the changes in the resources have to do with adaptation to different devices and different user preferences. (The other task of CSS is to make the Web beautiful and user-friendly.) The solution in that case is to separate the resource into multiple sub-resources, each of which is stable by itself, and let the user agent (client) construct a representation by combining the appropriate parts. One simple (and very common) example of this is where the parts are an HTML file, a handful of images and some CSS files. The URL of the HTML file identifies the resource and the HTML file in turn contains enough information for the user agent to find the other parts that it needs.
Of course, there are limits to what can be done this way: the information provider has to split the resources the right way, but it is hard to know what devices (will) exist; if the parts are too small, network latency may interfere with the user's experience; the parts need to have enough meta-data, but if the meta-data is too complex, it will be hard for the author to be correct and it may also be too complex for the user agent (which may be running in very little memory); we probably also do not yet have all the required technologies, such as flexible meta-data languages and data formats.
That last point, flexible meta-data and data formats, in particular when it comes to expressing presentation semantics, is what occupies the CSS working group. There is a balance that has to be found between different requirements: the style sheet language and the meta-data have to be simple enough to use and understand for nearly everybody; the style rules have to be generic enough that a designer can cover many environments with a single single style sheet, otherwise he has to write too many separate style sheets; the language has to be sufficiently low-level that even small devices can implement it; and yet it has to be powerful enough that designers can express what they want.
All these deliberations come to play, e.g., in finding the boundary between the meta-data (the "media queries" in the case of CSS) and the style sheet language itself. When we provide a language for fairly abstract styles (rules expressed in percentages instead of absolute measurements, positioning with floats instead of absolute, etc.), we give designers a way to design styles that work in many environments. Such rules are harder than concrete styles, but still easier than writing multiple style sheets. Designers often refer to such styles as "liquid." But when the rules are too abstract, people cannot handle them anymore. At that point the meta-data language must take over and allow the designer to create separate style sheets and describe in the meta-data language what environments they cater for.
Questions that the workshop participants may be able to (partially) answer include: