CSS Regions Considered Harmful

Håkon Wium Lie is the father of CSS, the CTO of Opera, and a pioneer advocate for web standards. His last article in this magazine led directly to real fonts on the web. When Håkon speaks, whether we always agree or not, we listen. In today’s post, Håkon shares his opinion on CSS Regions.

Way back, when designers first started emigrating from their islands of desktop publishing onto the web, they asked a seemingly simple question: how could they take with them their favorite colors, fonts and layouts? At first, we had no good answer. HTML offered semantic tags to describe the structure of documents, not their presentation. Browsers couldn’t be told what fonts to use, or where to fetch them. Authors, however, soon found a sneaky shortcut: the img element. By making images of their text, authors could achieve their colorful helveticized designs. In the process, all semantics (that is, information about the meaning of elements, as opposed to the presentation) was removed and even the searchable text was gone. CSS was proposed in 1994 to stop this practice; saving semantic HTML was just as important as achieving desirable layouts.

A few years later, at the height of the XML fever, presentational elements made a comeback. XSL defined an XML vocabulary for Formatting Objects; XSL-FO tags that said nothing about being headlines or list items, but all about their presentation. Computer scientists have a peculiar way of expressing fear and doubt. They publish essays with “considered harmful” in the title. This particular design pattern was started by Edsger Dijkstra when he published “Go To Statements Considered Harmful” in 1968. The development of formatting objects led me to use the same device; “Formatting Objects Considered Harmful” argued that formatting objects were font tags in disguise and that their use on the web must be avoided to preserve web semantics.

It seems that proposals for presentational elements return every so often. The most recent incarnation is CSS Regions. One should not write “considered harmful” articles lightly, but presentational elements is not the only problem with CSS Regions. For those who believe in meaningful HTML tags, responsive web design, and compact CSS code, the introduction of CSS Regions is not good news.

Problem #1: regions use dummy divs

Some articles on CSS Regions have already looked at the source code. An article published by WebPlatform.org describes how to achieve a commonly used two-column design:

The formatted document is on the left, and the corresponding regions are shown on the right. The HTML code that generates this layout must be studied in order to understand CSS Regions. Here’s a snippet:

<section class="page">
 	<div id="title">	<h1>Region #1</h1>			</div>
 	<div id="intro">	<h1>Region #2</h1>			</div>
 	<div id="col1">	<h1>Region #3</h1>			</div>
 	<div id="col2a">	<h1>Region #4</h1>			</div>
 	<div id="pull">	<h1>(Separate Region)</h1>	</div>
	<div id="col2b">	<h1>Region #5</h1>			</div>
</section>

The elements above represent regions, which are containers where text can flow from one to the other. Here is some of the corresponding CSS declarations for the #intro element:

#intro {
	width: 45%;
	position: absolute;
	top: 5em;
	height: 3em;
	-webkit-flow-from: main;
	-ms-flow-from: main;
	flow-from: main;
}

The CSS code above says, roughly: turn the #intro element into an absolutely positioned element with a given size and position, then discard the content of the element and replace it with content from the flow called “main”. Thus, the h1 element inside #intro isn’t a headline at all—the div element is a presentational container and the h1 element is discarded.

The proponents of CSS Regions might argue that, “Yes, the divs are there for presentational purposes, but only elements can be scripted on the web and we must therefore use elements.” This underlines an important point: it’s not regions per se that that are harmful to web semantics, it’s the fact that they are encoded as presentational HTML elements. If we want regions on the web, we should find a way to write them in CSS and not in HTML. If CSS Regions are accepted in 2014, we will be stuck with absolutely positioned dummy divs for the foreseeable future.

Not all web designers are concerned about semantics. If regions can provide the design tools they crave, a few dummy divs are worth the cost to some. Therefore, let’s analyze CSS Regions from a web design perspective. Do CSS Regions make good websites?

Problem #2: regions are not responsive

Responsive design is a hallmark of good web design. We want our sites to be scalable across a wide range of devices; from small mobile phones, to smarter phones, to big screens. Columns are a neat way of using the full width while keeping line lengths down. The example from the WebPlatform article flows its content into two columns. The width of the columns are set in percentages (45 percent, as can be seen in the example above). That provides for scaling as the two columns will grow with the width of the screen. But, there will always be two columns. Even on a very narrow screen, the example will not change to a one-column layout.

Ideally, you want the number of columns to be dynamic so that a narrow screen has one column, a medium screen has two columns, and an ultra-wide screen has three, or maybe four columns. CSS Regions will not give you this. Another CSS specification, however, describes how to achieve pages with scalable number of pages:

The samples above are produced with CSS Multi-column Layout, a specification for which I am the editor. And here is the code:

article {
	columns: 20em
}

The snippet above tells the formatter that the optimal line length is 20em, and that the number of columns should be computed accordingly. Thus, on a small screen you will have one column, on a wider screen two columns, etc. In effect, multi-column layout automatically creates the optimal number of connected regions needed to display the content. No presentational elements are needed to represent these regions—they are automatically created.

Can this kind of automatic layout of regions can also be a limitation though? Authors should be allowed to place regions far apart, shouldn’t they? This question brings us to the next section.

Problem #3: confusing text flow

Specifications often start out with a motivational example to show how powerful the proposed functionality is and how easy it can be achieved. The first example of the CSS Regions specification is shown below:

The text flow moves from region 1, to 2, 3, and 4, following the arrows. Notice how the eyes of the reader will have to traverse sideways, in the opposite of the reading direction, from 3 to 4. These kinds of traversals are not common in newspaper design, and I will argue that they are confusing to readers and should be avoided. CSS Multi-column Layout cannot make text flow this way, and I consider that to be a feature.

In my (arguably quite memory-constrained) mind, it would be far better to put the figure (A) at the bottom of the page and stack the columns in the reading direction left to right. Like this:

In this design, the maximum length that the eye would have to traverse backwards is the length of the line. This design can easily be achieved in CSS Multi-column Layout. Thus, in my experience, CSS multi-column layouts can do most of the things that designers plan to use regions for. If you cannot achieve your preferred columns using CSS Multi-column Layout, you should probably reconsider it.

Amongst the problems discussed in this article, this is probably the one I’m least worried about; if enough users are confused, the design will change. But it seems wasteful to invest years of efforts to implement CSS Regions if most of the compelling use cases can be achieved through an existing mechanism.

Problem #4: verbosity

The motivational example from the Regions draft also has some sample CSS code attached. The CSS code is shown in an appendix, probably because it’s too long to display at the beginning of the document. The CSS code uses 26 lines (after removing comments and blank lines). In addition, there are seven lines of HTML code for the dummy elements, bringing the total to 33 lines.

How many lines would it take to encode the more intuitive design (shown in the figure above) using CSS Multi-column Layout? Three, it turns out:

article { columns: 20em }
h1 { column-span: 2 }
img { column-span: 2; float: bottom }

For this example, using CSS Regions is a magnitude more complex than using CSS Multi-column Layout. If one were to support one layout on small screens, and more columns on wider screens, the code size for using CSS Regions would grow quickly.

(I must add that my favored code examples in this piece use features not just from CSS Multi-column Layout, but also from CSS Figures, which add integer values to the column-span property, and top and bottom to the float property.)

Problem #5: code reuse

Returning to the article on CSS Regions, consider the top part of the formatted article. The #intro element discussed above is a region set to contain the introduction, shown in white on a dark background. Notice how the text flows from the dark box to the next region under it.

Do your eyes follow? Do you know where the introduction ends? Admittedly, the first sentence of Finnegan’s Wake isn’t a traditional introduction, but consider how this will be used for more traditional articles. Personally, I feel cheated when big-font introductions turn into small-font body text in the same sentence. As a reader, I’d like to know where the introduction starts and where it ends and believe it should end in a complete sentence. Most publications use my favored style, while some style a box of a certain size like in the above example. These publications will be tempted to try CSS Regions.

However, I don’t think they will be happy with using CSS Regions this way. It’s problematic to assign style to a box because authors do not know how many lines of text will fit into the box. A common problem with absolutely positioned elements is that the text doesn’t always fill the box as the author intends. Often there will be unused white space at the bottom of the element. The same will happen when authors start using CSS Regions to style the first (say) five lines of text; perhaps only four lines will fit and there will be a visual jump to the rest of the text.

A similar problem appears in the pullquote that appears in the right column:

The pullquote starts with “The oaks…” in the image above. The region it lives in has a size just big enough to hold the text. An authoring tool may compute the size of the box and create a custom-made stylesheet. However, in order for the document to be presented “correctly,” the text must remain unchanged (no translations, please!), the same fonts must be available (please do not turn off downloadable fonts!), and the user must not increase the minimum font size (please bring your magnifier!).

Stylesheets written this way will not be reusable, each new document will have its own.

Harmful?

CSS Regions were proposed by Adobe in 2011 and the company is still its main proponent. It’s laudable that Adobe takes the web seriously and that it brings proposals to W3C—certainly much better than pushing a proprietary technology like Flash. Its motivation is to sell authoring tools that generate CSS code. That’s good, too—the web needs good authoring tools and Adobe can make them. But CSS Regions, as currently proposed, will not improve the web. Rather, it brings presentational tags, verbose code, and per-document stylesheets.