CSS Series: Part I, Regions

Hello, readers. I’m Jeff, the Senior User Interface Engineer at WaPo Labs, and this blog post is the beginning of what will hopefully be a fun and informative journey through the wilds of CSS. Oh no, not another acronym, you say. Oh yes — the Web is full of them, and this one stands for “Cascading Style Sheets,” a technology developed in the 90′s to make web pages like this one look pretty and, well, stylish. You could say CSS, along with HTML and JavaScript, is where designers and programmers meet and hang out. It’s quite the party.

I’ll be going over some primers on CSS later in the blog series, but this first post is about a relatively recent development in CSS that I’ve spent some time exploring called “CSS Regions,” which has the potential to make the Web more “print-like.” But first, a little background.

Style Sheets and the Separation of Presentation and Content

The introduction of Cascading Style Sheets (CSS) in 1996 brought the Web a giant leap closer to separating the content of a web page (text, images, etc.) from its presentation (visual layout). With content and styles contained in separate files, it’s possible to make changes to the “look and feel” of a web page without touching the HTML at all — and one can even switch between entirely different layouts by simply swapping style sheets.

This separation, however, isn’t perfect. While the main purpose of markup is to assign semantic meaning to content — such as defining a string of text as a heading or a paragraph — every HTML element contains an inherent visual layout, even if the visual aspect is minor, such as assigning inline or block-level behavior to a tag.

This behavior can be modified to a great extent using CSS, but the nested nature of HTML markup forces certain restrictions on the flow of the content and it’s location on the page, and CSS isn’t always up to the task of overcoming these restrictions. Absolute positioning only goes so far when you’re trying to move a sidebar weather widget to the header — at some point, you’re going to have to modify the HTML itself.

The “CSS Regions” Module

When I read about some of the new CSS modules currently in development at the W3C, I was intrigued by a spec called “CSS Regions” and its implications for getting around some of the aforementioned restrictions on visual layout. The goal of the spec is to control the way text and other content “flows” throughout a page, much like in traditional media.

Once the spec is mature, you’ll probably be seeing it in tablet reading experiences such as Flipboard and Google Currents. The module allows for some really amazing behavior, but what piqued my curiosity was the possibility of exploring how it might minimize the need to change markup when moving content around.

At WaPo Labs, we’re able to devote a certain amount of our time to such experiments, so I gave it a whirl. The results from my tinkering were mixed, largely because the spec for the module isn’t complete, and only a few browsers support it in its current form. Nevertheless, I discovered some interesting things.

First, Some Basics

When implementing CSS Regions, the first thing one needs to do is identify a container as a content source, or “flow,” from which content will flow into “regions” that are defined later. Unfortunately, this step is complicated by the fact that syntax varies among browsers and browser versions.

For example, in the build of Chrome I’m using at the moment (16.0.912.63), it’s necessary to apply the following rule to the source content container:

.kermit {
  -webkit-flow-into: gonzo;
}

where “gonzo” is an arbitrary name used to identify the new “flow” of content. The next step is to specify the “region” by applying the following rule to one or more elements on the page:

.fozzie, .miss-piggy, .animal {
  content: -webkit-from-flow('gonzo');
}

The content will flow from one container to the next. The order is determined by the order in which the regions appear in the DOM. Example:

Some Caveats to Remember: