Tags: layout

7

sparkline

Strong Layout Systems by Eric Meyer

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.

Tweakpoints

Mark has written down some thoughts on breakpoints in responsive designs. I share his concern that by settling on just a few breakpoints, there’s a danger of returning to the process of simply designing for some set canvases: here’s my “mobile” layout, here’s my “tablet” layout, here’s my “desktop” layout.

In my experience, not all breakpoints are created equal. Sure, there are the points at which the layout needs to change drastically in order for the content not to look like crap—those media queries can legitimately be called breakpoints. But then there are the media queries that are used to finesse page elements without making any major changes to the layout.

When I was working on Matter, for example, there was really only one major breakpoint, where the layout shifts from one column to two. That’s the kind of breakpoint that you can figure out pretty easily from the flow of your content; just resizing your browser window is usually enough to settle on the point that feels right. But there are lots of other media queries in the Matter stylesheet. Those are there to make smaller adjustments to margins, font sizes …the kind of changes that came about from testing on phones and tablets in the device lab.

It feels a bit odd to call them breakpoints, as though the layout would “break” without them. Those media queries are there to tweak the layout. They’re not breakpoints; they’re tweakpoints.

Media queries and multiple columns

By far the most common use of media queries is to execute CSS based on viewport width (using min-width or max-width). Lately there’s been more talk about using media queries based on height as well.

Paul talked about using min-height media queries to adjust content appearing above the fold. Owen Gregory wrote his superb 24 Ways article on using viewport proportions and device-aspect-ratio for media queries. Trent has documented his use of horizontal and vertical media queries to bump up the font size for wide and tall viewports.

One of the areas where I’ve found height-based media queries to be quite handy is in combination with another CSS3 module: multiple columns.

Splitting text over multiple columns is not something to be done lightly on a screen-based display. If the columns drop below the viewport then the user has to scroll down, scroll back up, scroll down again …you get the picture. It works fine in print but it’s not something that should be attempted on the web unless the entire text is visible at one time.

Well, with media queries we can get a pretty good idea of whether the text will fit on the viewport …assuming we know the length of the text.

Here’s an example (thanks to Space Ipsum for supplying the text). It splits the text into two columns if the viewport has enough width and height:

@media all and (min-width: 40em) and (min-height: 36em) {
    [role="main"] {
        column-count: 2;
        column-gap: 2em;
    }
}

If the viewport is wider still, the text can be split over three columns. In this case, the test for height can actually smaller because the text is spreading over a wider area, meaning the overall height of the text is shorter:

@media all and (min-width: 65em) and (min-height: 25em) {
    [role="main"] {
        column-count: 3;
        column-gap: 2em;
    }
}

The actual CSS is more verbose than that: vendor prefixes are still required. You can grab the example from Github if you want to have a play around with it.

Re-tabulate

Right after I wrote about combining flexbox with responsive design—to switch the display of content and navigation based on browser size—I received an email from Raphaël Goetter. He pointed out a really elegant solution to the same use-case that makes use of display:table.

Let’s take the same markup as before:

<body>
<div role="main">
<p>This is the main content.</p>
</div>
<nav role="navigation">
<p>This is the navigation.</p>
<ol>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>
</ol>
</nav>
</body>

The source order reflects the order I want on small-screen devices (feature phones, smart phones, etc.). Once the viewport allows it, I’d like to put that navigation at the top. I can do this by wrapping some display declarations in a media query:

@media screen and (min-width: 30em) {
    body {
        display: table;
        caption-side: top;
    }
    [role="navigation"] {
        display: table-caption;
    }
}

That’s it. It works much like box-orient:vertical with box-direction:reverse but because this is good ol’ CSS 2.1, it’s very well supported.

We can solve the other issue too: making those list items display horizontally on larger screens:

[role="navigation"] ol {
    display: table-row;
}
[role="navigation"] ol li {
    display: table-cell;
}

Once again, I’ve put a gist up on Github (get me! I’m like a proper computer nerd).

Update: And Remy has put it on JSbin so you can see it in action (resize the live preview pane).

So there you go: we’ve at least two different mechanisms in CSS to re-order the display of content and navigation in response to screen real-estate. The default is content first, navigation second—a pattern that Luke talked about in this interview with Jared:

Yeah, one of the design principles that I’ll be talking on the tour about, for mobile, is content first, navigation second; which is just really putting something up right away that somebody can engage with, and saving the pivoting and the navigating for later.

There’s, basically, UI patterns that you can use to make that happen. I’m still surprised at how many, both mobile websites and applications, the first thing they give you is a menu of choices, instead of content.

Don’t get me wrong, the menu’s important, and you can get to it, but it’s actually the content that the immediacy of mobile, and the fact that you’re probably on a slower network, and in some cases you’re even paying for your data transfers, right? Giving you a list of choices as your first time experience tends not to work so well.

Luke Wroblewski — Designing Mobile Web Experiences » UIE Brain Sparks on Huffduffer

Re-flex

I was in Minnesota last week for An Event Apart Minneapolis. A great time was had by all. Not only were the locals living up to their reputation with Amy and Kasia demonstrating that Kristina isn’t an outlier in the super-nice, super-smart Minnesotan data sample, but the conference itself was top-notch too. It even featured some impromptu on-stage acrobatics by Stan.

A recurring theme of the conference—right from Zeldman’s opening talk—was Content First. In Luke’s talk it was more than a rallying cry; it was a design pattern he recommends for mobile: content first, navigation second. It makes a lot of sense when your screen real estate is at a premium. You can see this pattern in action on the Bagcheck mobile site (a button at the top of screen is simply a link that leads to the fragment identifier for the navigation at the bottom).

Later on, Eric was diving deep into the guts of the CSS3 flexible box layout module and I saw an opportunity to join some dots.

Let’s say I’ve got a document like this with the content first and the navigation second:

<body>
<div role="main">
<p>This is the main content</p>
</div>
<nav role="navigation">
<p>This is the navigation</p>
</nav>
</body>

Using box-orient:vertical and box-direction:reverse on the body element, I can invert the display of those two children from the order they appear in the source:

body {
    display: box;
    box-orient: vertical;
    box-direction: reverse;
}

If I wrap that in a media query, I can get the best of both worlds: content first, navigation second on small screens; navigation first, content second on larger viewports:

@media screen and (min-width: 30em) {
    body {
        display: box;
        box-orient: vertical;
        box-direction: reverse;
    }
}

Works a treat (once you include the necessary -webkit and -moz prefixes).

I thought I’d take it a bit further. Suppose the navigation has a list of links:

<nav role="navigation">
<p>This is the navigation.</p>
<ol>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>
</ol>
</nav>

I could use flexbox to lay those items out horizontally instead of vertically once the viewport is large enough:

@media screen and (min-width: 30em) {
    [role="navigation"] ol {
        display: box;
        box-orient: horizontal;
    }
    [role="navigation"] li {
        box-flex: 1;
    }
}

Here’s the weird thing: in Webkit—Safari and Chrome—the list items reverse their direction: “baz, bar, foo” instead of “foo, bar, baz.” It seems that the box-direction value of reverse is being inherited from the body element, which I’m pretty sure isn’t the right behaviour. But it can be easily counteracted by explicitly declaring box-direction: normal on the navigation.

What’s a little trickier to figure out is why Firefox is refusing to space the list items equally. I’ve put a gist on Github if you want to take a look for yourself and see if you can figure out what’s going on.

Update: You can see it in action on JSbin (resize the view panel).

The new CSS3 layout modules and responsive design could potentially be a match made in heaven …something that Stephen has been going on about for a while now. Check out his talk at Mobilism earlier this year.

You’ll notice that he’s using a different syntax in his presentation; that’s because the spec has changed. In my example, I’m using the syntax that’s currently supported in Webkit, Gecko and Internet Explorer. And, as Eric pointed out in his talk, even when the newer syntax is supported, the older vendor-prefixed syntax won’t be going anywhere.

New Year’s Resolution

In a comment on Roger’s post about fixed and liquid layouts, Cameron wrote:

This issue seems to generate a heated debate every time it’s mentioned. I imagine one could pen an article with the headline “Fluid or fixed?” and nothing else, and yet dozens of comments would inevitably appear.

But rather than use that title, I couldn’t resist borrowing a pun from Andy, prompted by a post from Scrivs called What Resolution Will You Design for in 2007? (a classic example of the fallacy of many questions).

Now, firstly, we need to draw a distinction between monitor size and browser size. In other words, the difference between screen resolution and the viewport size:

There’s a real danger in thinking that “the numbers speak for themselves.” Numbers don’t speak for themselves; numbers need to be interpreted.

The numbers clearly show that monitor sizes and resolutions are getting bigger. The most common interpretation of that is more and more people have bigger displays. But an equally valid interpretation of the numbers is the range of displays is bigger than ever. It’s a subtle but important distinction. One interpretation focuses solely on the size of the highest numbers; the other interpretation focuses on the range of all the numbers.

The way I see it, the range is growing at both ends of the spectrum. Yes, desktop monitors are getting wider (though that doesn’t mean that viewports get any wider above a certain size) but handheld and gaming devices are likely to remain at the lower end of the scale. The Wii, for example, has a resolution of 640 x 480.

Mind you, the iPhone turns the whole question on its head with its scalable browsing. At MacWorld, Steve Jobs demonstrated this by visiting the New York Times, an unashamedly wide fixed-width website. On the Apple site, Wikipedia—a liquid layout— is shown fitting nicely on the display. The iPhone deals with both. Still, rather than letting my liquid layouts scale down to the iPhone’s width, I should probably start putting a min-width value on the body element.

Speaking of which…

A common argument against using liquid layouts is the issue of line lengths. On the face of it, this seems like a valid argument. Readability is supremely important and nobody likes over-long line lengths. But it’s not quite as simple as that when it comes to readability on screen compared to print, as Richard noted:

Surprisingly, I find short line lengths tiresome on screen; I don’t really subscribe to the empirical prescription of 7–10 words per line for comfortable reading. Most novels have 10–15 words per line and I think the upper region of that range is more appropriate for screen.

In any case, the idea that liquid layouts automatically means long line lengths on large screens is, I feel, a misconception. The problem is that a lot of the examples of liquid layouts aren’t very good and line lengths do expand without limit. But it doesn’t have to be that way.

In my opinion, the most important addition to Internet Explorer 7 is the max-width property. It means that we can now really start to look at creating fluid layouts within defined parameters, as demonstrated by Cameron in Andy’s book. In fact, I think we’re just scratching the surface of what’s possible in creating seamless adaptive layouts (and, more importantly, seamless adaptive page elements) using the dual power of max-width and min-width.

That still leaves Internet Explorer 6 and below. Should they get unbounded fluid layouts or should they get a fixed width fallback? The second is certainly an option using conditional comments, which is the Microsoft-approved way of dealing with rendering inconsistencies. I think that the lack of support for max-width certainly falls into that category. Call it transcending CSS if you will; I call it routing around damage on the designer’s network.

I want to hear what you have to say… if you’ve got something new to say. Let’s not just rehash the same old arguments that would inevitably appear had I simply asked “Fluid or fixed?”

Fixtorati

Technorati has been redesigned, or realigned if you prefer. It’s gone a bit gradient happy but overall, it’s quite a pleasing visual aesthetic.

For some reason though, they’ve chosen to lock the pages into a fixed width of 1024 pixels.

Now, I understand the reasoning behind fixed-width layouts. I can see the justification for wide fixed-width layouts on content-heavy sites like A List Apart (even if I disagree with it). But forcing users of what is fundamentally a web app to set their browser to a certain width seems counterproductive to me.

The content on Technorati is user-generated. Usually, that user is me. It has my favourites, my watchlist, and my search terms. I should be able to interact with that content in my way.

This is something that, as with so many things, del.icio.us gets just right. Upcoming is on the right track too. These sites allow me to interact with my data without putting me in a straitjacket.

Flickr is still avowedly fixed but the image-based, rather than text-based, nature of the data I store there makes this somewhat understandable.

Now, don’t misconstrue this as a tirade against 1024 pixel wide layouts. The problem would still exist in an 800 pixel wide design. Choosing an arbitrary number of pixels in which to serve up user-generated content is the issue here. On the one hand, Technorati is a very Web 2.0 sort of site, based on user-generated distributed content and collective wisdom. On the other hand, its visual design is grounded in a very Web 1.0 idea of top-down control and inflexibility.

I like Technorati a lot. It’s come on in leaps and bounds in the past couple of years. I’d like to use it every day. I’m even willing to put up with the oversize ads. But I resent the feeling that I should adjust my browsing environment to the needs of the site, rather than the other way around.