CSS3 and Its Adversaries

One of the amazing things about the development of web technologies is that they were relatively anarchic.

Unlike the development of traditional GUI systems, which were created behind the closed doors of academic institutions like Xerox’s PARC and later developed further by products such as Apple’s original Macintosh, the Web evolved in an open and, for lack of a better term, amateurish fashion. Although we can debate the benefits of one form of evolution over another, few argue that the Web isn’t a platform for incredible innovation, proving that either evolutionary method can push the development of such technologies in interesting and useful new directions.

As with all technologies, CSS is designed to solve a particular use case: separating the presentation of content from the structure of the content itself and reforming it to new presentations easily. However, CSS is not the only technology designed to solve this same use case. One notable competitor is XSL-FO, heavily used in the publishing industries for print layouts.

XSL-FO is a self-contained, unified, presentational markup language. This means that an XSL-FO document does not require external style sheets, scripts, or other apparatus to work as expected, and it is not considered semantically structured the way HTML or XHTML is. It is most often used to create print documents and is specifically tailored for paged media. A typical workflow involving XSL-FO would look something like this:

1. The XML document (such as DocBook, used in publishing contexts) is created.

2. The XML document is passed through an Extensible Style Sheet Transformation (XSLT) to convert the XML into XSL-FO.

3. The XSL-FO is passed through an “FO Processor”—software intended to convert the presentational document to another (potentially binary) format. The usual output is some press-ready format, such as PDF or PostScript.

XSL-FO contrasts with CSS in that it is a markup language, and all of the presentational data is contained within element attributes. It is not semantic at all, nor is it modular. It is a transition format between XML and some other format, and isn’t intended to be worked with by itself without some sort of programmatic capabilities on either end of the process (such as XSLT and software to convert to PDF).

The question is at what point in the advancement of CSS does XSL-FO become obsolete? With improvements in the specification around web fonts and print media, all the components for a full-featured print styling mechanism are coming into place. All that remains is a parser to convert your markup into a press-ready format such as PDF or PostScript. Printing your markup directly from a CSS style sheet instead of doing all that XSL-FO transformation means one less step in the process, and it leverages the opportunity to use external style sheets and skills that you already know to write manually, if that is needed or desired.

Another open question among web technologists concerns the CSS selection model. In CSS3, the ways in which elements can be targeted by CSS rules has been extracted into its own module called CSS3 Selectors. As you know, CSS’s notion of selectors originated in the first version of the specification, first published in 1996. However, in 1999 the W3C standardized a similar technology intended to be used to address parts of an XML document that provided much more granular control over which parts of the document were selected. This technology is called the XML Path Language, or XPath.

Today, the earliest versions of XPath still give XPath authors greater specificity over which parts of an XML document they wish to address than even the latest CSS3 Selectors draft. Many developers wonder, then, if such a precise language exists already, why is the CSS3 Selectors draft not incorporating more of it?

Some believe that XPath’s syntax is too complicated. A common selection such as “all <p> elements” is extremely intuitive using CSS (the selector is simply a p) and in XPath it is not (to achieve the same effect, the XPath expression you need to use is //p).

On the other hand, with new CSS constructions such as div#content — div:not(p:nth-of-type(3)a[href]), CSS Selectors can become frustratingly complex as well. What is an appropriate balance between simplicity and power? This is a debate that rages on to this day.

Other parts of CSS are taking the opposite route; rather than developing their own syntax and capabilities, they are taking on the behavior and terminology of other technologies. At the time of this writing, the proposed CSS3 modules for CSS Animations and Transitions was accepted to the standards track by the W3C. These modules incorporate SVG-like capabilities. More to the point, they are so similar that they can be thought of as a CSS interface to SVG graphical capability. Of course, CSS can be applied to SVG markup, so clearly there is some opportunity there for web authors to leverage their CSS skills in SVG elements.

In this case, the ubiquity of CSS is helping to promote and standardize the capabilities developed by other technologies. Since there are so many more knowledgeable CSS developers than there are SVG developers, it makes sense to utilize your existing familiarity to push the envelope of what is technically possible.

However, this path is not without its concerns. Although some would argue that creating more than one way to do something is a good thing, others argue that creating too many different ways to accomplish the same task fragments a standard and undermines its usefulness. Since many modern browsers support SVG today, the question becomes why not promote its use as is?

A further question that comes up is related to the technicality of the implementation itself. SVG is, a “thing” that can be referenced and re-purposed as a form of content. It is ultimately a language that describes building blocks of visual things. When you put the pieces together, you can create ever more complex graphical objects. On the other hand, CSS requires the use of a different thing; by itself, a style sheet doesn’t do anything.

These examples are the product of nothing more magical than developers like you playing around with the building blocks that we have today; such academic experimentation is the best thing you can do to expand your skills. When you run into a problem, ask yourself if you can use an existing building block—a CSS property or particular browser feature—to solve it, or if you need a new building block altogether. If you do need to create something new, since you’ve now imagined what it might be, tell other people what you need or, if you can, build it yourself.