Eric is at An Event Apart in Atlanta talking about Strong Layout Systems. Following on from Brother Jeffrey’s presentation, he begins with a reading…
In the beginning Sir Tim created the server and the browser. And the web was without form. And the face of Tim moved over the web. Tim said “Let there be markup.” And there was markup. And he saw that it was good. And he divided structure from appearance.
That decision is quite striking. Think about other mediums. The structure of a book is bound to its appearance.
Here’s a screenshot, courtesy of Grant Hutchinson, of the preferences in the original Mosaic browser. You could define the appearance of any HTML element …as a user. As an author, you couldn’t do that. HTML didn’t support that: it created structure.
As with all creations, there was a fall. As usual, a reptile was involved. In this case it was Mozilla, known by its ancient name of Netscape. They added presentational elements like prompt and presentational attributes e.g. on the hr element. And then there was the table element. Inevitably, it was used for layout. David Siegel wrote the book on this, Creating Killer Websites. It was tables all the way down: tables inside of tables inside of tables, all to create visual appearance.
The backlash came from the Web Standards Project. It got dogmatic there for a while. But we got past that, and we started using CSS. The promise of CSS was visual presentation, for authors and users. We talk about “controlling” presentation with CSS, but remember that theoretically that can be over-ridden by user styles.
But CSS was an appearance system; not a layout system. It wasn’t that complex. You could print out all of CSS1. The only thing in it in any way suited for layout was floats …and that’s not what they were created for: it was basically the CSS equivalent of the align attribute that Netscape had introduced to HTML. So we used floats because that’s all we had. It wasn’t a layout system but we made it one anyway. There were a lot of bugs, but we dealt them in clever—sometimes deranged—ways.
For CSS2, they realised that designers really liked to lay things out (who knew?) so they introduced positioning. But you have to be careful with positioning. It was great …sort of. You can indeed position an element wherever you want …and overlap them.
The first major site to launch with CSS for positioning was Doug’s redesign of Wired.com (it didn’t use floats). The limitations of positioning forced us into certain design patterns. Note the footer on the old Wired site: it sits at the bottom of the central column, not the whole page. That was to avoid overlap. But Eric remembers talking to Doug and it turns out they actually wanted a full-width footer, but they had to work with the tools they had. Positioning lacked the equivalent of clear that you get with floats.
These were hacks. Hacks aren’t a bad thing; they’re often very clever. But hacks limit us. Neither floats nor positioning had the concept of equal height (but tables did).
We’re now getting to the point where can start to revisit our assumptions about what is and isn’t possible with CSS.
We’ve got viewport units: vh and vw—viewport height and viewport width (in percentages relative to the viewport, not the parent element). This is really useful for handheld devices. There’s also the vmin unit that you can use on font sizes so that text scales in relation to viewport size.
Flexible boxes is more commonly called flexbox. Take a horizontal navigation (in an unordered list) and declare it as a flexible box. Then declare that the elements within should “flex” to each use an equal amount of space. There’s a variant justify-content: space-around which will share out the space between the elements equally.
Flexbox comes out of XUL, Gecko’s layout language for browser chrome. This is real layout. It’s not a hack. As an author, you’re declaring how you want things to be laid out, and the browser does it. It’s a good feeling.
You can also use flexbox to make sure that elements within a shared parent have the same height. In fact, that’s the default behaviour. You can also get your flexible boxes to reflow instead of being trapped on the same line. The new “line” will also share out space for the elements equally.
You can set your flexible boxes with whatever units you want, and mix and match them: percentages and ems, for example. You can have flexible and fixed elements together.
Remember The Holy Grail of Layout on A List Apart? It followed soon after the One True Layout. Now you could do it with just a few quick flexbox declarations.
<header></header>
<main>
<nav></nav>
<article></article>
<aside></aside>
</main>
<footer></footer>
main { display: flex; }
nav { width: 13em; flex: none; }
article { width: auto; flex: none; }
aside { width: 20%; flex: none; }
You can also rearrange the visual ordering (using order). You could make the article appear as the third column within main even though it appears second in the markup. The structure is truly separated from the layout.
Flexbox alignments are really interesting, especially baseline, which will vertically align columns according to the first baseline in each column — very handy.
You aren’t restricted to horizontal layout: you can arrange things vertically. We finally get vertical centring.
Beyond flexbox, we have grids. They’re not quite as stable right now, but the basic idea is that you can set up grid lines to “control” page elements and the space between them: grid-definition-columns: (4em) gives you a repeating grid with a grid unit of four ems.
You can have flexbox inside grids and visa-versa: within a grid unit, you can still display: flex. Within a flexible box, you can define grid lines.
But please don’t go and read the grids specification right now. It’s an amalgamation of three different authors’ texts, one of whom has never written a spec before, and one of the examples is completely misleading about how grids work.
There’s a fraction unit—fr—that you can use to define widths, but you can also use it in combination with min-content which is based on the longest piece of content in a unit. This is complicated stuff and even Eric doesn’t quite get it completely. Maybe min-content is better for non-text content.
And remember you can mix and match these modules. Same with CSS regions. Regions aren’t here yet, but they will completely up-end the way we think about document structure: you put all of your content in one element, and you have some empty elements as well. Then you use CSS regions to define how the content from the first element flows into the others. Effectively your document has a structural portion and a skeleton layout portion.
These layout modules are truly new. You might think that we’re familiar with using CSS for layout, but that was always hacking: using tools for a purpose other than that for which they were created. This new modules were created specifically to allow us to create layouts. That really is new. And Eric can’t wait to see what we do with these new tools.