<div id="wrapper">
	<header id="masthead" role="banner"></header>
	<div id="content"></div>
	<aside class="primary"></aside>
	<div id="footer"></div>
	<footer class="contentinfo" role="contentinfo"></footer>
</div>

We already talked about why I chose this structure and then dug into the header and aside elements. Let’s pick right up and move on to the main content div.

Content Div

There’s quite a bit going on inside this div so let’s first look at the general structure.

<div id="content">
	<article class="post">
		<header class="post-9 hentry"></header>
		<section></section>
		<footer class="meta"></footer>
		<section id="comments"></section>
	</article>
</div>

As an article should be self-contained content it probably seems intuitive that it would include a header, footer, and sections of content. The inclusion of the comments might seem a little odd and it was another place I went with my gut.

You could make the argument that comments on the post should be a separate article instead of being included in the main article.

When you currently subscribe to a blog you’re delivered posts, though typically not the comments. You could also subscribe to the comments, but then those are usually considered a different subscription and are delivered without the post.

The above is suggesting the use of 2 separate articles in html5 and perhaps that would have been the better choice.

Ask me again in a few weeks and I might recommend taking the comments out of the post article and placing them instead in another article (instead of a section) below the post article.

Header

As you’d expect the header begins with an h1 tag. I want to call your attention to a couple of other things.

<header class="post-9 hentry">
	<h1></h1>
	<small class="meta">
	<time datetime="2011-07-07" pubdate>Wednesday, July 7, 2011</time> <address class="vcard">by <a class="url n fn" rel="author" href="" title="View Steven Bradley's profile">Steven Bradley</a></address>	</small>
	<p class="intro"></p>
	<p></p>
</header>

First is that I’ve used the time and address tags. The the former because I was adding a date and the latter to mark up my name as an hCard.

The other thing to note is that this header closes with a couple of paragraphs of introductory text. It could have been included in a new section following the header, but sections typically (though not always) will include a header or at least a new heading.

Since these paragraphs are falling under the main h1 and are meant to be introductory text, it made more sense to me to include them here.

Section

Most of the post content follows the same pattern. Each time a new heading is encountered I set up a new section, with that heading and some paragraphs of text. The paragraphs could also be lists and blockquotes, etc.

<section>
	<h2></h2>
	<p></p>
	<section>
		<h3></h3>
		<p></p>
	</section>
	<section>
		<h3></h3>
		<p></p>
	</section>
	<p></p>
</section>

When the new heading is lower in the hierarchy its section is nested. h3 sections are nested inside h2 sections. Had I used an h4 it would have been nested inside the h3 that came before.

Headings that are siblings get their own section relative to the parent heading.

Footer

Footers are meant to include content describing the main content. Think meta information. Here I included a paragraph showing how the post was archived and then included a short author bio.

<footer class="meta">
	<p>This post is archived…</p>
	<section>
		<h1>About Steven Bradley</h1>
		<p></p>
	</section>
</footer>

Since author name and description are related I enclosed both inside a new sections.

As I could envision moving the author bio to other types of pages I used an h1. I wouldn’t rely on the outline algorithm currently, but here I was pretending it had better browser support in order to play around with it in the demo.

Comments

Since each comment is coded the same I’ll just include one in full in the code below. Each new article at the end would be a new comment. Above all the comments is a heading for the section.

Everything is enclosed in a section since comments on a post are clearly related. I debated whether or not the entirety of comments should be a single article instead of a section. I think you can make a good argument for that, especially as a full comment stream is often syndicated via rss.

<section id="comments">
	<h1> 3 Comments</h1>
	<article class="comment">
		<div class="comment-meta" id="comment-1">
			<a href="" rel="external nofollow">Homer Simpson</a>
			<img src="" alt="" class="avatar" />
			<time datetime="" pubdate></time>
		</div>
		<div class="comment-body">
			<p></p>
		</div>
	</article>
	<article class="comment"></article>
	<article class="comment"></article>
	<article class="comment"></article>
</section>

I decided to call it a section, though.

Part of that choice comes from looking at how others treated comments and part because it felt more like the individual comment was the self-contained unit as opposed to all the comments.

Explaining it now I’m thinking it would have made more sense to consider the entire comment stream as an article with each comment being a nested article within.

What’s inside each comment isn’t anything special at this point. I wrapped the comment meta and the comment body in divs. These probably should have been sections instead of divs as the content is related.

Footer Div

This is the footer div that includes the links and the ad. All of this information is tangential, much like the sidebar and so each is an aside.

Remember that we’re choosing these new semantic elements based on the content they enclose, not the location of the content within the document.

I probably should have chosen a different name for the id to avoid confusion with the html5 footer. A better choice might have been id=”subfooter”

<div id="footer">
	<aside class="sub-footer">
		<h1></h1>
		<p></p>
		<ul>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
		</ul>
	</aside>
	<aside class="sub-footer">
		<h1></h1>
		<p></p>
		<ul>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
		</ul>
	</aside>
	<aside class="advertising">
		<h1></h1>
		<a href=""><img src="" alt="" /></a>
	</aside>
</div>

Since the three different sets of content aren’t related I chose to wrap all three in a div instead of a section. The aside is enough to show that the content inside each is related to itself.

Once again I chose not to use a header element inside and just went with the h1. Whether or not headers are needed is something I still need to work out.

Footer

Finally we get the document footer. Since the content here is information about the entire page it’s enclosed in the main footer for the entire page.

<footer role="contentinfo" class="contentinfo">
	<p></p>
</footer>

After walking through all of the above code I’ll assume no additional explanation is needed here.

Above: The demo as viewed in Internet Explorer 7 on Windows XP

Additional Thoughts

This demo is really one of my first attempts at coding a page in html5. I learned quite a bit, made some observations, and raised a few questions for myself.

Overall it wasn’t too difficult to get used to html5. The elements themselves are easy to use and for the most part it isn’t too difficult to know when to use them. Of all of the new elements nav, aside, and footer created the least confusion for me.

It will take some time getting used to the new tags, especially when it comes to developing new best practices, but it was like that when moving from tables to divs and I suspect the transition will be easier this time around.

The header element while simple to use raised questions about how often to use it. Should each new group of sectioning content start with a header? Only when an hx element is present? Can it safely be left out? What advantages does it hold without more support for the outline algorithm?

The most confusing part was deciding when to use div, section, and article. The definitions of each seems clear enough, but in practice it can be hard to decide which is best to use at times. It’s not hard to see that I could redevelop this same demo and end up with a new structure of div, section, and article.

I suspect this is what you’ll find the most challenging and I’m providing some links to help you sort it out below.

However this really isn’t all that different from what goes on now. If you and I develop the same design we’ll likely structure things differently even when only using divs as our main block level element. There really isn’t a right or wrong way to use the 3 tags and accepting that will probably help clear away the confusion more than anything.

What we’ll likely see in the coming months and years is a series of best practices for using all of the new elements and we’ll each pick and choose which best practices work best for us.

After having worked through the demo I’m much more convinced that we can use these new semantic elements in real projects now.

Above: The demo as viewed in Internet Explorer 6 on Windows XP

Browsers

Throughout this 2 part post I’ve included some screenshots of the demo in Internet Explorer. For the most part they look pretty good. IE6 was the only time the demo looked off as you can see in the screenshot above and the one below.

However as poor as the demo looks in those images it’s really only a few minor tweaks to fix. Also as I’ve said a few times here I’ve dropped support for IE6 so I’m not really concerned with making those tweaks unless a client specifically requests it.

Unfortunately my Windows testing machine has been on the fritz lately and I wasn’t able to get good screenshots of how the demo looks in IE when Javascript is disabled.

I managed to grab screenshots where I had removed the link to the html5shiv. The IE6 screenshot is the last image in this post. I suspect that’s not how it really looks though.

Perhaps the divs I used were enough to keep the layout intact, but I expected the demo to look much worse with Javascript disabled. If someone can grab a screenshot and send it to me I’ll include it here.

My testing machine should be up and running again in a few days too so I’ll see if I can grab a screenshot as well.

Above: The bottom of the demo page as viewed in Internet Explorer 6 on Windows XP

Additional Resources

Here are some of the articles I read trying to sort out using divs, sections, and articles. This post by Oli Studholme, HTML5 structure—div, section & article, probably helped me the most with the following 3 questions and answers.

• Would the enclosed content would make sense on it’s own in a feed reader? If so use <article>
• Is the enclosed content related? If so use <section>
• Finally if there’s no semantic relationship use <div>

I also leaned on the articles below quite a bit.

• The section element read through the comments
• <section&gt: is not just a “semantic &lt:div&gt:”
• HTML5 test results You’ll see you aren’t alone in your confusion
• Article of doubt
• Sections and outlines of an HTML5 document
• HTML5 articles and sections: what’s the difference?

Above: My best attempt at collecting a screenshot in Internet Explorer with Javascript disabled. This is IE6 on Windows XP. I expect this image looks better than the reality.

Summary

Hopefully this 2 part walk through of my demo has helped make html5 sectioning elements easier to understand and even better I hope it’s convinced you to create your own demo page. You’ll understand these tags much, much better through actual use than reading about what I’ve done.

Start with a trip through some of the html5 boilerplate templates that are readily available and beginning with one as a shell, develop what might be a typical web page in your workflow.

At first I fell back to using divs as I do now, just to get some kind of structure in place. I then began replacing some of those divs with the new elements and rearranging a few things here and there as I iterated the development of the page.

It really won’t take long to get used to he new elements, but the only way that will happen is if you take the time to start using them.

For those of you who have started developing with html5 how have you handled the issue of using too many or not enough headers? Have you found it easier to decide when it’s best to use div, section, and article as you’ve worked with them more? Are there specific issues that continue to arise for you that I haven’t mentioned here?

Go to Source

<div id="wrapper">
	<header id="masthead" role="banner"></header>
	<div id="content"></div>
	<aside class="primary"></aside>
	<div id="footer"></div>
	<footer class="contentinfo" role="contentinfo"></footer>
</div>

We already talked about why I chose this structure and then dug into the header and aside elements. Let’s pick right up and move on to the main content div.

Content Div

There’s quite a bit going on inside this div so let’s first look at the general structure.

<div id="content">
	<article class="post">
		<header class="post-9 hentry"></header>
		<section></section>
		<footer class="meta"></footer>
		<section id="comments"></section>
	</article>
</div>

As an article should be self-contained content it probably seems intuitive that it would include a header, footer, and sections of content. The inclusion of the comments might seem a little odd and it was another place I went with my gut.

You could make the argument that comments on the post should be a separate article instead of being included in the main article.

When you currently subscribe to a blog you’re delivered posts, though typically not the comments. You could also subscribe to the comments, but then those are usually considered a different subscription and are delivered without the post.

The above is suggesting the use of 2 separate articles in html5 and perhaps that would have been the better choice.

Ask me again in a few weeks and I might recommend taking the comments out of the post article and placing them instead in another article (instead of a section) below the post article.

Header

As you’d expect the header begins with an h1 tag. I want to call your attention to a couple of other things.

<header class="post-9 hentry">
	<h1></h1>
	<small class="meta">
	<time datetime="2011-07-07" pubdate>Wednesday, July 7, 2011</time> <address class="vcard">by <a class="url n fn" rel="author" href="" title="View Steven Bradley's profile">Steven Bradley</a></address>	</small>
	<p class="intro"></p>
	<p></p>
</header>

First is that I’ve used the time and address tags. The the former because I was adding a date and the latter to mark up my name as an hCard.

The other thing to note is that this header closes with a couple of paragraphs of introductory text. It could have been included in a new section following the header, but sections typically (though not always) will include a header or at least a new heading.

Since these paragraphs are falling under the main h1 and are meant to be introductory text, it made more sense to me to include them here.

Section

Most of the post content follows the same pattern. Each time a new heading is encountered I set up a new section, with that heading and some paragraphs of text. The paragraphs could also be lists and blockquotes, etc.

<section>
	<h2></h2>
	<p></p>
	<section>
		<h3></h3>
		<p></p>
	</section>
	<section>
		<h3></h3>
		<p></p>
	</section>
	<p></p>
</section>

When the new heading is lower in the hierarchy its section is nested. h3 sections are nested inside h2 sections. Had I used an h4 it would have been nested inside the h3 that came before.

Headings that are siblings get their own section relative to the parent heading.

Footer

Footers are meant to include content describing the main content. Think meta information. Here I included a paragraph showing how the post was archived and then included a short author bio.

<footer class="meta">
	<p>This post is archived…</p>
	<section>
		<h1>About Steven Bradley</h1>
		<p></p>
	</section>
</footer>

Since author name and description are related I enclosed both inside a new sections.

As I could envision moving the author bio to other types of pages I used an h1. I wouldn’t rely on the outline algorithm currently, but here I was pretending it had better browser support in order to play around with it in the demo.

Comments

Since each comment is coded the same I’ll just include one in full in the code below. Each new article at the end would be a new comment. Above all the comments is a heading for the section.

Everything is enclosed in a section since comments on a post are clearly related. I debated whether or not the entirety of comments should be a single article instead of a section. I think you can make a good argument for that, especially as a full comment stream is often syndicated via rss.

<section id="comments">
	<h1> 3 Comments</h1>
	<article class="comment">
		<div class="comment-meta" id="comment-1">
			<a href="" rel="external nofollow">Homer Simpson</a>
			<img src="" alt="" class="avatar" />
			<time datetime="" pubdate></time>
		</div>
		<div class="comment-body">
			<p></p>
		</div>
	</article>
	<article class="comment"></article>
	<article class="comment"></article>
	<article class="comment"></article>
</section>

I decided to call it a section, though.

Part of that choice comes from looking at how others treated comments and part because it felt more like the individual comment was the self-contained unit as opposed to all the comments.

Explaining it now I’m thinking it would have made more sense to consider the entire comment stream as an article with each comment being a nested article within.

What’s inside each comment isn’t anything special at this point. I wrapped the comment meta and the comment body in divs. These probably should have been sections instead of divs as the content is related.

Footer Div

This is the footer div that includes the links and the ad. All of this information is tangential, much like the sidebar and so each is an aside.

Remember that we’re choosing these new semantic elements based on the content they enclose, not the location of the content within the document.

I probably should have chosen a different name for the id to avoid confusion with the html5 footer. A better choice might have been id=”subfooter”

<div id="footer">
	<aside class="sub-footer">
		<h1></h1>
		<p></p>
		<ul>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
		</ul>
	</aside>
	<aside class="sub-footer">
		<h1></h1>
		<p></p>
		<ul>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
			<li><a href=""></a></li>
		</ul>
	</aside>
	<aside class="advertising">
		<h1></h1>
		<a href=""><img src="" alt="" /></a>
	</aside>
</div>

Since the three different sets of content aren’t related I chose to wrap all three in a div instead of a section. The aside is enough to show that the content inside each is related to itself.

Once again I chose not to use a header element inside and just went with the h1. Whether or not headers are needed is something I still need to work out.

Footer

Finally we get the document footer. Since the content here is information about the entire page it’s enclosed in the main footer for the entire page.

<footer role="contentinfo" class="contentinfo">
	<p></p>
</footer>

After walking through all of the above code I’ll assume no additional explanation is needed here.

Above: The demo as viewed in Internet Explorer 7 on Windows XP

Additional Thoughts

This demo is really one of my first attempts at coding a page in html5. I learned quite a bit, made some observations, and raised a few questions for myself.

Overall it wasn’t too difficult to get used to html5. The elements themselves are easy to use and for the most part it isn’t too difficult to know when to use them. Of all of the new elements nav, aside, and footer created the least confusion for me.

It will take some time getting used to the new tags, especially when it comes to developing new best practices, but it was like that when moving from tables to divs and I suspect the transition will be easier this time around.

The header element while simple to use raised questions about how often to use it. Should each new group of sectioning content start with a header? Only when an hx element is present? Can it safely be left out? What advantages does it hold without more support for the outline algorithm?

The most confusing part was deciding when to use div, section, and article. The definitions of each seems clear enough, but in practice it can be hard to decide which is best to use at times. It’s not hard to see that I could redevelop this same demo and end up with a new structure of div, section, and article.

I suspect this is what you’ll find the most challenging and I’m providing some links to help you sort it out below.

However this really isn’t all that different from what goes on now. If you and I develop the same design we’ll likely structure things differently even when only using divs as our main block level element. There really isn’t a right or wrong way to use the 3 tags and accepting that will probably help clear away the confusion more than anything.

What we’ll likely see in the coming months and years is a series of best practices for using all of the new elements and we’ll each pick and choose which best practices work best for us.

After having worked through the demo I’m much more convinced that we can use these new semantic elements in real projects now.

Above: The demo as viewed in Internet Explorer 6 on Windows XP

Browsers

Throughout this 2 part post I’ve included some screenshots of the demo in Internet Explorer. For the most part they look pretty good. IE6 was the only time the demo looked off as you can see in the screenshot above and the one below.

However as poor as the demo looks in those images it’s really only a few minor tweaks to fix. Also as I’ve said a few times here I’ve dropped support for IE6 so I’m not really concerned with making those tweaks unless a client specifically requests it.

Unfortunately my Windows testing machine has been on the fritz lately and I wasn’t able to get good screenshots of how the demo looks in IE when Javascript is disabled.

I managed to grab screenshots where I had removed the link to the html5shiv. The IE6 screenshot is the last image in this post. I suspect that’s not how it really looks though.

Perhaps the divs I used were enough to keep the layout intact, but I expected the demo to look much worse with Javascript disabled. If someone can grab a screenshot and send it to me I’ll include it here.

My testing machine should be up and running again in a few days too so I’ll see if I can grab a screenshot as well.

Above: The bottom of the demo page as viewed in Internet Explorer 6 on Windows XP

Additional Resources

Here are some of the articles I read trying to sort out using divs, sections, and articles. This post by Oli Studholme, HTML5 structure—div, section & article, probably helped me the most with the following 3 questions and answers.

• Would the enclosed content would make sense on it’s own in a feed reader? If so use <article>
• Is the enclosed content related? If so use <section>
• Finally if there’s no semantic relationship use <div>

I also leaned on the articles below quite a bit.

• The section element read through the comments
• <section&gt: is not just a “semantic &lt:div&gt:”
• HTML5 test results You’ll see you aren’t alone in your confusion
• Article of doubt
• Sections and outlines of an HTML5 document
• HTML5 articles and sections: what’s the difference?

Above: My best attempt at collecting a screenshot in Internet Explorer with Javascript disabled. This is IE6 on Windows XP. I expect this image looks better than the reality.

Summary

Hopefully this 2 part walk through of my demo has helped make html5 sectioning elements easier to understand and even better I hope it’s convinced you to create your own demo page. You’ll understand these tags much, much better through actual use than reading about what I’ve done.

Start with a trip through some of the html5 boilerplate templates that are readily available and beginning with one as a shell, develop what might be a typical web page in your workflow.

At first I fell back to using divs as I do now, just to get some kind of structure in place. I then began replacing some of those divs with the new elements and rearranging a few things here and there as I iterated the development of the page.

It really won’t take long to get used to he new elements, but the only way that will happen is if you take the time to start using them.

For those of you who have started developing with html5 how have you handled the issue of using too many or not enough headers? Have you found it easier to decide when it’s best to use div, section, and article as you’ve worked with them more? Are there specific issues that continue to arise for you that I haven’t mentioned here?

Go to Source

Even as I coded the demo I could think of other possible ways to structure it and at times felt a sense of confusion over which element made the most sense to use.

Here’s the demo page, which you may want to refer to as you’re reading through this post. All the images in the post are also links to the demo.

Note: Because there’s a lot to cover I’ve split this post in two and will publish the second part on Thursday.

The Layout

To keep things simple I opted to create a 2 column fixed-width and centered layout that will likely look familiar. If you look at the demo or the image above you’ll note it includes the usual basics for a blog post.

• header
• content area
• sidebar
• footer

Note: The image above is a cropped version of the demo page. I cut out most of the middle in order to make the image small enough to fit here.

HTML5 Boilerplate

There’s not a lot to see here with the basic shell. Naturally I’m using the new html5 doctype. I’ve also defined the language as English and also defined the character set.

I’ve also included the html5shiv script for IE8 and below with a conditional comment.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="description" content="Demo for a typical blog post coded using new html5 semantic elements" />
<title>HTML5 Structural Semantics</title>
< link rel="stylesheet" href="style.css" >
<!--[if lt IE 9]>
	<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
</head>
<body>
</body>
</html>

I purposely kept the shell simple since I was mainly concerned with the new structural elements. There’s more you might want to and probably should include and I’ll refer you to the html5 boilerplate site for more and better information.

Additional Resources

Below are a few sources for html5 boilerplate code.

• HTML5 Mini Template
• html5 boilerplate
• The Official Guide to HTML5 Boilerplate
• A Basic HTML5 Template

The Presentation

Most of the css was added in a quick and dirty manner. It’s there to make the demo presentable and also to test how the page looks in older versions of Internet Explorer. It’s hardly the best code or all that interesting where this demo is concerned.

The one bit that’s most relevant for our current purpose is at the top of the page.

section, article, header, footer, nav, aside, hgroup {
	display: block;
}

If you remember we needed this code since our new elements have no default styles in some browsers.

The High Level HTML5 Structure

Let’s get to the good stuff. I wrapped everything inside the body with a wrapper div, which I used to set the width of the page and center it.

I chose to stick with a div here instead of using a section because the container is only meant for presentation. A section tag would indicate the content inside is related. Since different kinds of content will be inside, a div seems most appropriate.

<div id="wrapper">
	everything else here
</div>

Inside the wrapper the high level page structure is as follows:

<div id="wrapper">
	<header id="masthead" role="banner"></header>
	<div id="content"></div>
	<aside class="primary"></aside>
	<div id="footer"></div>
	<footer class="contentinfo" role="contentinfo"></footer>
</div>

The structure contains 3 of the new elements, probably where you’d expect them to be. The header element contains the logo, tagline, and navigation. The aside contains the rss and category information, and the footer contains the designed by credit and copyright.

The information just above the copyright may seem to make sense as a footer or at least a section, but if you look at the content, it isn’t really related. There are 3 distinct sections of content, hence the use of a div to enclose it all.

The post itself, the meta information, and the comments are all inside a content div. I’ll show the details next time, but directly inside this div is an article tag which also wraps everything

<div id="content">
	<article class="post">
		post, meta, comments here
	</article>
</div>

I could have left out the content div and moved it’s styles to the article, but I included both to allow for the possibility of other content like a trail of breadcrumb links. Those links might fall inside the div, but wouldn’t be part of the article.

You may have noticed that both the header and footer contain the role attribute. Roles exist for assisted technologies. While I’ve included roles in the demo I’ll hold off talking about them in this post and save the talk for another post where I can give it the attention it deserves.

Let’s continue by looking inside the 5 structural containers inside our wrapper div.

Header

The header element is fairly easy to understand and use. What you’ve been marking up till now as div id=”header” (or similar) you’ll now markup with the header element instead.

One adjustment with headers is that you can and likely will use more than one header in a document. (We’ll see this when we explore the other containers). Because we can have multiple headers it makes sense to give this one an id or class.

	<header id="masthead" role="banner">
		<div class="bar"></div>
		<a href=""><img id="logo" src="" alt="" /></a>
		<hgroup>
			<h1>html5 Web Design</h1>
			<h2>Building your website for the future</h2>
		</hgroup>
		<nav role="navigation">
			<ul id="main-nav">
				<li><a href="" title="">Home</a></li>
				<li><a href="" title="">About</a></li>
				<li><a href="" title="">Blog</a></li>
				<li><a href="" title="">Contact</a></li>
			</ul>
		</nav>
	</header>

Immediately inside is a div, which I used to create the thin black bar across the top. Since its only function is presentational a div seemed most appropriate. Next I’ve added a logo, which should look exactly as you’d expect.

I included both the site title and tagline as headings inside an hgroup. Currently I wouldn’t use headings for either, but I wanted to give hgroup a spin. In the future I think this will be the common practice.

Our main navigation is inside the header and as you would expect it’s marked up using the new nav element. Again I’ve added a role. Otherwise it should look as you would expect main navigation to be coded.

Aside

Let’s move to the right and the aside before getting to the content as the aside is a bit simpler.

Remember an aside is meant for tangential content. While the content here is certainly useful it could easily be removed without affecting the main content on the page.

The class name is arbitrary. There are other asides in the document and I decided this was the primary aside, hence the choice.

	<aside class="primary">
		<section class="rss">
			<a href=""><img src="images/rss-24x24.png" alt="" /> Subscribe</a>
		</section>
		<nav>
			<h3>Categories</h3>
			<ul>
				<li><a href="">CSS</a></li>
				<li><a href="">Web Design</a></li>
				<li><a href="">WordPress</a></li>
				<li><a href="">Blogging</a></li>
				<li><a href="">SEO</a></li>
			</ul>
		</nav>
	</aside>

Finally a section tag. Here we simply have some text and an image wrapped in a link that points to the feed. Clearly related stuff.

On a real page you might also include a subscriber count and an option to subscribe via email. Both would be related to the link we have here so again a section is the most appropriate.

Below the rss section is another nav element. Nav isn’t meant for every occurrence of a group of links, but because this is sub-navigation for the blog that would likely be included on multiple pages, it made sense to code it with the nav element.

You’ll notice the h3 inside the nav. Admittedly I wasn’t consistent in my use of hx tags in this demo. In some places I use h1s relying on an outline algorithm I know doesn’t work in most browsers and in other places I kept track of the hierarchy myself.

I also didn’t include a header inside. I could have wrapped the h3 like so.

<header>
	<h3>Categories</h3>
</header>

This was a gut call. As html5 becomes the de facto way to develop pages and sites I suspect most every hx tag will fall inside a header element. However it was hard to see any advantage to adding it here.

This is one of those places where I can’t say whether or not what I’ve done is the best practice. I think the html5 spec wants me to use header tags here, but again I didn’t see an advantage.

Let’s stop here and continue next time with the main content div.

Summary

Like I said at the top you really need to use the new elements in practice to understand them. Their definitions are relatively easy to grasp, but once coding you’ll be faced with some less than clear choices.

Over time I suspect we’ll have plenty of best practices to guide us. At the moment we’re mostly on our own to figure out when to use div, section, and article or whether or not we should include a header inside a section.

I’ll pick up where we left off next time, though of course the demo will still be there if you want to poke through my code and see how I set the page up. Again I’ll remind you my code isn’t necessarily right or the best. It’s simply what made the most sense to me as I developed the demo page.

Like many I’m still working much of this out for myself. Hopefully sharing my thoughts will help make it easier for you to work it out.

Go to Source

Unfortunately some of what we’ll look at below isn’t yet supported by browsers. Some of it will be, but not all. Still I think what’s here is important to understand with an eye toward the future.

Content Models

Before html5 we had two categories of elements, inline and block. With html5 we now have a more fine-grained set of categories with their own content models.

• Text-level semantics — what were previously inline tags
• Grouping content — block level elements like paragraphs, lists, and divs
• Forms — everything inside form tags
• Embedded content — images, video, audio, and canvas
• Sectioning content — the new structural tags described in my previous post

Currently to create a hierarchical outline of our content we use a set of h1–h6 tags. They work for the most part, but can break down at times. Consider the following:

<h1>Web Design</h1>
	<p>Some general info about web design</p>
	<h2>Layout</h2>
	<p>Info about layouts</p>
		<h3>Grids</h3>
		<p>Info about grids</p>
	<h2>Typography</h2>
	<p>Info about typography</p>
	<h2>Color</h2>
	<p>Info about color</p>
	<h2>Design Principles</h2>
	<ul>
		<li>List of</lI>
		<li>several different</lI>
		<li>design principles</lI>
	</ul>
<p>Where in the outline does this paragraph belong?</p>

The above would produce the following outline based on the headings.

• web design
  • layout
    • grids
  • typography
  • color
  • design principles

In general each paragraph below a heading belongs under that heading in the outline in the hierarchy, but do they have to?

Where in the outline does the very last paragraph belong? Is it under the Design Principles or does it belong under Web Design?

You can tell my intention based on the indentation, but a machine isn’t going to see that with the whitespace stripped and there’s no reason the code needed to be indented the way it is above.

Visually that last paragraph will look just like the one above it as well. Reading you wouldn’t really know which section it belongs to.

HTML5 helps solve the problem above.

Sectioning Content Model

The first tool html5 provides is the section tag we discussed last time. Using the section element we can rewrite the above as

<h1>Web Design</h1>
	<p>Some general info about web design</p>
	<section>
		<h2>Layout</h2>
		<p>Info about layouts</p>
			<h3>Grids</h3>
			<p>Info about grids</p>
		<h2>Typography</h2>
		<p>Info about typography</p>
		<h2>Color</h2>
		<p>Info about color</p>
		<h2>Design Principles</h2>
		<ul>
			<li>List of</lI>
			<li>several different</lI>
			<li>design principles</lI>
		</ul>
	</section>
<p>Where in the outline does this paragraph belong?</p>

Once again the outline produced is the same as we saw above, but now it’s much clearer where the last paragraph belongs. We can do better though. Let’s mix in the header element and better define the different sections of the document.

<h1>Web Design</h1>
	<p>Some general info about web design</p>
	<section>
		<header>
			<h2>Layout</h2>
		</header>
		<p>Info about layouts</p>
		<section>
			<header>
				<h3>Grids</h3>
			</header>
			<p>Info about grids</p>
		</section>
	</section>
	<section>
		<header>
			<h2>Typography</h2>
		</header>
		<p>Info about typography</p>
	</section>
	<section>
		<header>
			<h2>Color</h2>
		</header>
		<p>Info about color</p>
	</section>
	<section>
		<header>
			<h2>Design Principles</h2>
		</header>
		<ul>
			<li>List of</lI>
			<li>several different</lI>
			<li>design principles</lI>
		</ul>
	</section>
<p>Where in the outline does this paragraph belong?</p>

Once again the above html produces the same outline. So far not much is really new other than the addition of some new tags. We could have done the same thing by using divs instead of section and header.

So where’s the new stuff?

HTML5 Outline Algorithm

In html5 each sectioning element has its own self-contained outline. What that means is we can start each section with an h1 tag and the algorithm will figure out the overall outline.

<h1>Web Design</h1>
	<p>Some general info about web design</p>
	<section>
		<header>
			<h1>Layout</h1>
		</header>
		<p>Info about layouts</p>
		<section>
			<header>
				<h1>Grids</h1>
			</header>
			<p>Info about grids</p>
		</section>
	</section>
	<section>
		<header>
			<h1>Typography</h1>
		</header>
		<p>Info about typography</p>
	</section>
	<section>
		<header>
			<h1>Color</h1>
		</header>
		<p>Info about color</p>
	</section>
	<section>
		<header>
			<h1>Design Principles</h1>
		</header>
		<ul>
			<li>List of</lI>
			<li>several different</lI>
			<li>design principles</lI>
		</ul>
	</section>
<p>Where in the outline does this paragraph belong?</p>

Believe it or not the above html where every heading is an h1 still produces the same outline in html5.

• web design
  • layout
    • grids
  • typography
  • color
  • design principles

Under html 4 the outline would be

• web design
• layout
• grids
• typography
• color
• design principles

Quite a difference. It might seem somewhat strange to have every heading be an h1 tag, but it does have advantages. You won’t have to keep track of your overall hierarchy, only the hierarchy within a section.

Maybe not such a big deal with a single document, but it does allow our content to be more modular and portable, which will get to momentarily.

Other Sectioning Elements

Above I mentioned that the sectioning content model includes all the structural tags we talked about last time. It’s not only the section tag that creates its own self-contained outline.

Tags like aside, article, and nav also do the same.

While it wouldn’t be appropriate had I used article tags instead of section tags in the above code the same outline would have been produced.

The hgroup Element

Sometimes you may want to use headings so you can better show and style visual hierarchy, but you don’t want the heading to be part of the document outline.

hgroup allows us to do just that. For example say you have the following markup:

<hgroup>
	<h1>Main heading</h1>
	<h2>Tagline</h2>
</hgroup>

Only the h1 above would be included in document outline. The h2 wouldn’t be included. Only the first heading, regardless of how many are there would be included in the outline.

The hgroup element can only contain h1–h6 tags and it’s meant to be used for subtitles, alternative titles, and tag lines.

Do we need hgroup? The above could have been coded as:

<h1>Main heading</h1>
<p class="tagline">Tagline<p>

This would produce the same outline and allow for the same visual styles, however the hgroup probably adds more semantic meaning and certainly uses a bit less code.

In addition to using hgroup to hide some headings from the document outline there are a few elements that by default are invisible to the document element and are called sectioning roots.

• blockquote
• fieldset
• td

Even if you use headings inside the above elements those headings won’t be part of the document outline under html5.

Modular Content

The new outline algorithm helps us create content that is more modular. The idea of not needing to keep track of your hierarchy might not seem like such a big deal until you consider what happens when you move a piece of content around.

For example typical of many blogs is to display the title and a short paragraph of several posts on the main blog page. In the individual posts the headings would be marked up with an h1. On the main blog page you might have an h1 for the page and then have each of the blog post titles as an h2.

With the new outline algorithm you can move the post titles back and forth with the same h1 heading and let the outline algorithm figure out the hierarchy.

This makes any section of content more portable as we can mix it in with other content without worrying that it might break the hierarchy of the page.

While you’ll probably never have need you can now also structure a document with more than 6 levels. Ultimately we can now create an infinite amount of levels using the same h1–h6 elements in nested sections.

Scoped Styles

A new problem is created in being able to move content around from document to document and that’s in the styles that get applied to that content.

Our modular content will inherit the styles of the parent document, which may not be what we want. html5 offers a solution with the boolean scoped attribute that can be applied to the style element as seen below.

<article>
	<style scoped>
		h1 {styles here}
	</style>
	<h1></h1>
	<p></p>
</article>

In the above code the h1 of our article will be the scoped styles regardless of where the article is displayed. This allows us to move not only content, but the styles associated with that content easily.

Browser Support

In order to use the new semantic elements we defined those elements in our stylesheet as display: block to ensure they won’t break our layouts. We should now add the hgroup element.

section, article, header, footer, nav, aside, hgroup {
	display: block;
}

We’d of course need to create the element for IE as we did with the other elements or include the html5shiv script.

document.createElement('hgroup');

Now for the bad news. Browser support for the html5 outline algorithm is currently not good.

However the good news is you don’t have to use an h1 to start each new section. You can continue to use h2 and h3 tags inside sections to produce the outline you want.

We’ll lose the portability benefits until browsers are supporting the new algorithm, but we can start preparing for when they do offer support.

For now it’s probably better to stick with using headings as you always have, though it is safe to enclose your headings in the new semantic elements.

Summary

HTML5’s sectioning content model gives us greater control over the hierarchy of our documents. The new outline algorithm provides for an unlimited number of heading levels and helps make our content more modular and portable.

At the moment there’s limited browser support the the html5 outline algorithm, but we can still prepare for it while using h1–h6 tags as we do now.

We won’t be able to take advantage of some of the benefits the new outline algorithm will gives us, but we can prepare our documents for when browser support is more robust.

It will probably feel a little strange to markup a document with multiple h1 tags and leave it to the browser to sort out the hierarchy, but hopefully you can see the advantages in such an approach.

Go to Source

Recently I read Jeremy Keith’s excellent book, HTML5 for Web Designers from A Book Apart and now feel like I have a better understanding of how these tags should work.

This post is a further attempt to better understand things for myself and hopefully pass on some of that understanding to you.

Today I want to run through each of the new tags and briefly explain what each is meant to be used for. I’ll keep the code itself light in this post.

Note: Some of the elements below lead to a new content model for structuring documents. I’ll talk about more about content models on Thursday. Next week I’ll do my best to present some code for a typical blog post using these new html5 elements.

Text-Level Semantics Elements

There are two types of semantic tags introduced by html5, text-level and structural. Text-level semantics fall into what are currently inline elements.

Mark

The mark tag is used to to highlight or reference a run of text due to it’s relevance in some other context. Highlighting words in a document that a visitor searched for is a good example.

The mark tag is doesn’t attach any importance to the text like strong or em tags do, but it’s more semantically meaningful than the generic span tag.

It’s hard to think of many uses beyond searching, but I’m sure they exist. Perhaps you make a quote linkable and in the original document the text you quoted is highlighted in some way using the mark tag.

Time

Time as you would expect is used to markup temporal information. It can be used for dates, times, or combinations of the two.

<time datetime="14:00">2pm</time>
<time datetime="2011-07-14">July 14th, 2011</time>
<time datetime="2011-07-14T14:00">2pm on July 14th</time>

The datetime attribute isn’t necessary, but if it’s not used it’s value needs to be shown to the visitor.

<time>2011-07-14</time>

One obvious use for the time tag is with the hCalendar microformat.

<time class="dtstart" datetime="2011-07-14"> July 14th, 2011</time>

Meter

The meter tag is used to markup measurements, specifically a scalar measurement within a known range.

<meter>1 of 10</meter>
<meter>2 of 7</meter>

It could also be used to represent a fractional value like disk usage or percentage of a specific population.

It doesn’t represent an absolute scalar value of arbitrary range like your height or weight, unless of course you’re reporting heights or weights within a known range of heights or weights.

There are 6 attributes you can use with the meter tag.

• value
• min
• max
• high
• low
• optimum

Your batting average is <meter value=".340" min="0" max="1.000" low=".215" high=".367" optimum="1.000">.340</meter>

Extra points for baseball fans who know what .340, .215, and .367 signify.

Progress

The progress tag is used to markup values in the process of changing

Your download is <progress>55%</progress> complete

It has 3 attributes

• value
• min
• max

By itself it’s probably not that interesting, however when combined with the DOM and some scripting it can be used to dynamically update progress values.

Structural Semantic Elements

Structural elements are the block level elements we use to structure pages. Some of the tags below arose out of common web development usage for class names and ids.

Section

The section element represents a section of a document, typically one that includes a heading. It’s used to enclose a thematic grouping of content.

It’s similar to a div though it carries more semantic meaning since the content inside the section tags should be related. The key to choosing the semantic tag over a div is for the content to be related in some way.

Header

The header element represents the header of a section. It’s meant to be used as a container for a group of introductory content or set of navigational links.

While most websites currently have one header at the top of the page as a masthead, you can have multiple headers in a single html5 document. Usually you would use the header tag at the top of a document (as a masthead) or at the top of a section of content.

Getting used to multiple headers will probably be the most difficult adjustment.

Footer

Similar to the header, the footer element represents the footer for a section or document. Like the header tag there can be multiple footer tags in an html5 document.

A footer is more than content at the bottom. It should contain information about it’s containing element. Typical content you might include in a footer would be:

• Author information or bio
• Copyright information
• Links to related content

The above aren’t the only things you could include. Any metadata for the section could go in the footer tag. Remember that the footer tag isn’t meant to describe position within a document, but rather describe the data within part of a document.

Aside

The aside element represents content that is tangentially related to the main text of a document. It aligns with what we think of as a sidebar.

As with the other structural tags its not about position within a document, but rather its relationship to the content. An aside doesn’t have to be to the right or left as we typically think of a sidebar. It could be at the top, the bottom, or even in the middle of a section of content.

If the information could be removed without reducing the meaning of the overall content, the information is a good candidate for an aside. Pull quotes are good examples. Advertising another.

Nav

The nav element represents a section of a document that links to other documents or to parts within the document itself. It’s a section of navigational links.

It’s intended for major navigational information like a sitewide navigation bar or a subsection menu. It’s important to realize that not every group of links belongs inside the nav element.

The nav tag should typically be placed inside the header element and again it’s meant for major navigational information.

Article

The article element represents a section of content that forms an independent part of a document or site. It represents a section of self-contained content.

Can the content be syndicated as an rss feed? If yes it’s probably an article. The article tags covers the same use case as the hAtom microformat.

Potential sources for the article tag include:

• Blog post
• News story
• Comment
• Review
• Forum post

If the time element is used inside an article it can include the boolean pubdate attribute, however only one pubdate can be used inside each article.

While not intuitive the article tag can be used for things like self-contained widgets such as stock tickers, calculators, and clocks. An article doesn’t specifically have to be textual content. It’s the self-contained part that’s most important.

One point about all the tags above is they aren’t meant to replace every div in your document. The tags should be used where semantically appropriate. Some of your divs will get replaced with these new tags, though not all will. It comes down to the content being enclosed and choosing the most semantically meaningful tag.

The Difference Between Sections and Articles

One of the things I’ve found confusing about these new structural tags is the difference between a section and an article and when to use each. The answer seems to be a matter of interpretation and in some places the tags seem interchangeable.

The two tags are similar. The difference is that an article is self-contained. It can stand on it’s own. A section isn’t. You can have multiple sections inside an article and you can have multiple articles inside a section. You can nest sections within sections and articles within articles.

Ultimately you have to decide which is the most semantically appropriate for a given situation and I imagine as html5 falls into greater use we’ll see debates about the “right” way to use each along with a lot of meaningless arguing with anyone who doesn’t agree with your “right” way.

Note: I’ll have more to say about these 2 elements when we dive into some real code next week. Understanding their definitions is easy. Trying to decide when to use which in a document turns out to be a lot less easy.

Browser Support

Of course a big question is can and should you use these tags now. What kind of support exists in browsers for these new semantic tags?

Not all browsers are supporting these tags, however you can still use them today. Most browsers not named Internet Explorer allow you to create any element you like and let you style those elements how you want. They simply won’t give those tags any default styling.

If we consider all of the new structural tags they’re meant to act as block level elements so all we need to do is add the following:

section, article, header, footer, nav, aside {
	display: block;
}

Doing the above will keep your layout from breaking. You can then add any additional styles you’d like for your design. Browsers may not understand the additional semantic meaning of these tags, but so what.

Other machines that do understand the semantics will get that additional meaning and browsers will see these tags similar to how they see a div (without default styling).

IE8 and below won’t recognize the new tags. However IE will recognize new elements created in Javascript so we can create the new tags.

document.createElement('section');

You would do the same for each of the new elements or better use a conditional comment to link to Remy Sharp’s html5 shiv which will create them for you.

<!--[if IE]>
	<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->

Modernizer also include’s the html5 shiv so if you use Modernizer you don’t need to link to the html5 shiv as well.

The above css and javascript will cover most everyone, though not people using IE6–8 with Javascript disabled. Generally speaking that’s a small % of people. Depending on the audience of your site it may not be an issue for you. There’s also a workaround for IE with scripting disabled.

Know though that even those people will still see your content. They may not see the styles you apply to the tags and they may not get the extra semantics, but your content will still be there. whether or not that’s acceptable is up to you.

Additional Resources

There are many, many resources for html5 and more and more seem to appear every day. Here are a few I used while putting together this post.

• HTML5 For Web Designers
• HTML5 from WHATWG
• Section tags from WHATWG
• Dive Into HTML5
• Semantics in HTML 5
• html5 Doctor
• HTML Elements from W3C

Summary

HTML5 adds a number of new layers to html, including a new set of semantically meaningful elements. We can categorize these new tags as being either text-level or structural.

The new tags are fairly easy to understand, though as we’ll see next week some become more confusing to use in practice

Browser support isn’t technically there in the sense of understanding the new semantics, but with a workaround or two we can safely use the new elements for most, though not all cases, .

I’m leaning toward using these new semantic tags on my own projects, though I’ll probably hold off using them on most client sites without some additional workarounds for the moment.

How about you? Are you using html5 semantic elements and if so have you encountered any problems?

Go to Source

You can view demos of each of the methods below by clicking here. Clicking the images above each section will also take you to that specific demo.

Let’s start by first talking about something that doesn’t work as many expect. Understanding why vertical-align doesn’t always work will help us better understand vertical centering in general.

Vertical-Align

Horizontal centering with css is rather easy. When the element to be centered is an inline element we use text-align center on its parent. When the element is a block level element we give it a width and set the left and right margins to a value of auto.

With text-align: center in mind, most people look first to vertical-align in order to center things vertically. It seems logical and I know it was my first choice. If you’ve come from table based layout you likely used the valign attribute, which would also lead you to believe vertical-align is the way to go.

However valign only worked on table cells. Vertical-align is similar. It also applies to table cells and it works with some inline elements.

The values for vertical-align have meaning with respect to a parent inline element.

• With a line of text the values are relative to the line-height.
• With a table cell the values are relative to the table-height-algorithm, which usually means the height of the row.

Unfortunately vertical-align doesn’t apply to block-level elements like a paragraph inside a div, which is where most of us figure out it isn’t the be all solution to vertical centering.

All is not lost though, as we have other methods for centering block level elements and we can still use vertical-align where appropriate. Which method you choose will depend on what you’re trying to center relative to its container element.

Line-Height Method

This method will work when you want to vertically center a single line of text. All we need to do is set a line-height on the element containing the text larger than it’s font-size.

By default equal space will be given above and below the text and so the text will sit in the vertical center.

Most tutorials will also set the height on the element with the same value given to the line-height. I don’t think setting the height is necessary, but if line-height alone doesn’t work for you setting the height of the element will likely be the solution.

html

<div id="parent">
	<div id="child">Text here</div>
</div>

css

#child {
	line-height: 200px;
}

The above works in all browsers, however it will only work for a single line of text. If your text could wrap to a 2nd line you need to use a different method. The value of 200px above is arbitrary. You can use any value you want as long as it’s larger than the font-size that’s been set.

Centering an Image with Line-Height

What if the content you want centered is an image? Will this method work? The answer is yes with one additional line of css.

html

<div id="parent">
	<img src="image.png" alt="" />
</div>

css

#parent {
	line-height: 200px;
}
#parent img {
	vertical-align: middle;
}

You set the line-height as we did above (It’ll need to be greater than the height of the image) and then set vertical-align: middle on the image.

CSS Table Method

Above I mentioned that vertical-align applies to table cells which leads us to this method. We’ll display our elements as table and table cell and then use the vertical-align property to center the content.

Note: CSS tables are not the same as html tables.

html

<div id="parent">
	<div id="child">Content here</div>
</div>

css

#parent {display: table;}
#child {
	display: table-cell;
	vertical-align: middle;
}

We set the parent div to display as a table and the child div to display as a table-cell. We can then use vertical-align on the child div and set it’s value to middle. Anything inside this child div will be vertically centered.

Unlike the method above the content can be dynamic as the div will grow with what’s placed inside. The downside of this method is it doesn’t work in older versions of IE, though there is a fix, which is to add display: inline-block to the child element.

#child {
	display: inline-block;
}

• Flexible height vertical centering with CSS, beyond IE7
• CSS Vertical Centering

Absolute Positioning and Negative Margin

This method works for block level elements and also works in all browsers. It does require that we set the height of the element we want to center.

In the code below I’m centering the child both vertically and horizontally using this method.

html

<div id="parent">
	<div id="child">Content here</div>
</div>

css

#parent {position: relative;}
#child {
	position: absolute;
	top: 50%;
	left: 50%;
	height: 30%;
	width: 50%;
	margin: -15% 0 0 -25%;
}

We begin by positioning both parent and child divs. Next we set the top and left values of the child to be 50% each, which would be the center of the parent. However this sets the top left corner to be in the center so we’re not done.

We need to move the child up (by half its height) and to the left (by half its width) so it’s center is what sits in the center of the parent element. This is why we need to know the height (and here the width) of the child element.

To do that we give the element a negative top and left margin equal to half its height and width.

Unlike the first 2 methods this one is meant for block level elements. It does work in all browsers, however the content can outgrow its container in which case it will disappear visually. It’ll work best when you know the heights and widths of the elements.

• A demo using this method to center a block of text in the browser

Absolute Positioning and Stretching

As with the method above this one begins by setting positioning on the parent and child elements as relative and absolute respectively. From there things differ.

In the code below I’ve once again used this method to center the child both horizontally and vertically, though you can use the method for vertical centering only.

html

<div id="parent">
	<div id="child">Content here</div>
</div>

css

#parent {position: relative;}
#child {
	position: absolute;
	top: 0;
	bottom: 0;
	left: 0;
	right: 0;
	width: 50%;
	height: 30%;
	margin: auto;
}

The idea with this method is to try to get the child element to stretch to all 4 edges by setting the top, bottom, right, and left vales to 0. Because our child element is smaller than our parent elements it can’t reach all 4 edges.

Setting auto as the margin on all 4 sides however causes opposite margins to be equal and displays our child div in the center of the parent div.

Unfortunately the above won’t work in IE7 and below and like the previous method the content inside the child div can grow too large causing it to be hidden.

Equal Top and Bottom Padding

In the method above we allowed the browser to automatically set the margins of the child element so they would be equal. In this method we’ll do something similar and explicitly set the top and bottom padding of the parent to be equal.

html

<div id="parent">
	<div id="child">Content here</div>
</div>

css

#parent {
	padding: 5% 0;
}
#child {
	padding: 10% 0;
}

In the css above I’ve set top and bottom paddings on both elements. Setting it on the child will make sure the contents in the child will be vertically centered and setting it on the parent ensures the entire child is centered within the parent.

I’m using relative measurements to allow each div to grow dynamically. If one of the elements or it’s content needs to be set with an absolute measurement then you’ll need to do some math to make sure things add up.

For example if the parent was 400px in height and the child 100px in height we’d need 150px of padding on both the top and bottom.

150 + 150 + 100 = 400

Using % could throw things off in this case unless our % values corresponded to exactly 150px.

This method works anywhere. The downside is that depending on the specifics of your project you may need to do a little math. However if you’re falling in line with the idea of developing flexible layouts where your measurements are all relative you can avoid the math.

Note: This method works by setting paddings on the outer elements. You can flip things and instead set equal margins on the inner elements. I tend to use padding, but I’ve also used margins with success. Which you choose would depend on the specifics of your project.

Floater Div

This last method requires an empty div which is floated and used to control where our child element sits in the document flow. Notice the floater div comes before our child div in the html below.

html

<div id="parent">
	<div id="floater"></div>
	<div id="child">Content here</div>
</div>

css

#parent {height: 250px;}
#floater {
	float: left;
	height: 50%;
	width: 100%;
	margin-bottom: -50px;
}
#child {
	clear: both;
	height: 100px;
}

We float the empty div to the left (or right) and give it a height of 50% of the parent div. That causes it to fill up the entire upper half of the parent element.

Because this div is floated it’s removed from the normal document flow so we need to clear the child element. Here I’ve used clear: both, but you just need to clear in the same direction you floated the empty floater div.

The top edge of the child div should now be immediately below the bottom edge of the floater div. We need to bring the child element up by an amount equal to half it’s height and to do so we set a negative margin-bottom on the floater div.

This method also works across browsers. The downside is that it requires an empty div and that you know the height of the child element.

• How To Center Content Vertically Using CSS

Additional Resources

In the sections above I linked to articles specific to each method. Below are some resources that cover more than a single method for centering.

• Vertical Centering With CSS — covers all the methods above except for the padding method
• Two Simple Ways to Vertically Align with CSS — Covers absolute positioning and negative margins and the line height methods
• Vertical centering using CSS — Covers all methods except the floater div method and adds a few more.
• CSS tests and experiments — Contains a variety of css experiments. Search the page for the word vertical and you’ll find several vertical centering experiments, including the 2 links below.
• Centering (horizontally and vertically) an image in a box
• Shrink-wrap and Center

Summary

None of the methods above is complicated and I’m sure if you use each once or twice it’ll be easy to use again.

The difficultly if there is one is that none of the methods above is perfect for all occasions. The trick is to understand several of the above and use each appropriately.

Some of the methods work better for inline elements and others work better for block level elements. Some might work better with your preference for developing a layout and some don’t work in older versions of a certain browser we all know well.

Rarely do I vertically center elements in a design. When I do the methods I tend to use are the line-height method and the equal padding method. One or the other has always worked for my needs.

If neither worked I would reach for either the positioning or floater methods and save the table cell method as a last resort. In time we’ll be able to use the css3 flexible box layout module and forget about the methods above, but for now browser support isn’t quite there.

Do you use any of the above methods or do you use a different method I didn’t mention? Is there a vertical centering issue that none of the methods here address?

Go to Source

A few weeks ago Rosevita Warda posted Designing in the Open at 37 Signals. The gist of the post is that the more confident we feel in our design process, the more we show our work, resulting in more feedback that helps make us better designers.

This can be seen in the following 2 quotes from the post.

There’s a phase we go through in our maturity as designers. At first we don’t have a lot of confidence in our process, so we hide while we work.

When we get more confident a new phase opens up. We believe more in our process and we know that things are never perfect. So we start showing work earlier and start talking about our rationale at a given step.

I’m guessing most of you can identify with the first quote above. I know I can. Hopefully you can also identify with the second quote. I think I’m getting there.

The message is that designing more in the open leads to better work. The question then is how can we build our confidence so that we’re more willing to design in the open.

How to Improve Your Confidence as a Designer

Being confident in your work is not always an easy thing to do, especially where anything creative is involved.

The trick is to find a small measure of confidence and build from there.

Don’t Compare Yourself to the Best

It’s natural for us to compare our work to the work we want to create, but it comes with a price. You’re not supposed to be as good as the best when first starting so don’t let it get you down if your work isn’t as good as the work of your favorite designers.

Instead compare yourself to yourself. Are you doing better work today than you were 6 months ago? A year ago? Absorb the work of others to help yourself grow, but compare yourself only to yourself.

Identify Your Strengths and Weaknesses

If you lack confidence there’s a reason why. You’re likely focusing on the things you don’t do well. Focus instead on the things you can do well.

We all have strengths and weaknesses. Realize there are things you do well and take some confidence from them. Realize too there are things you need to work at and improve.

For me a strength was something as simple as trusting my eye. Perhaps I couldn’t create designs to make the world say wow, but I could at least see wow in the works of others and see that I wasn’t delivering it myself.

It might not seem like much, but it was enough to give me the confidence to keep at it.

Sharing Your Strengths

You have some strengths so play to them. Maybe you’re skills working with type aren’t great, but you’re good working with color. Maybe all you think you can do well is see the good in the work of others. Share that.

Share any aspect where you do feel some confidence and enter the process of designing in the open.

Improve Your Weaknesses

It’s normal to be hesitant in sharing things we don’t do well. Identify one weaknesses and work to improve it.

Do you struggle with color? Learn more about how others work with color. Study sites you like. Grab some books and learn the theory behind color. Find techniques others use for creating color schemes.

Choose one aspect of design to study and dive in.

Practice, Practice, Practice

Learning the theory is only one part of the equation. You need to practice the theory. Take that technique you learned for creating a color scheme and use it on your next project.

You have to practice in order to improve. I always strive to practice something new with each new site. I may have to fall back on something I know will work in order to get the job done, but not until after I’ve given something new a try.

Start Sharing More

As you gain more knowledge and experience with one aspect of design share more of that aspect. If you’re not yet ready to show your work write about it instead. Tell others what you’re doing and what’s working and what’s not working.

Create a simple demo showing how you approached the problem. You don’t have to share real projects to enter the process. Share what you can in any way you can.

Often on this blog I choose a subject I don’t know much about. Like most I’d prefer not to embarrass myself publicly so I put more into the learning and work harder so I can hopefully write something intelligently about the subject.

Be Open to Feedback

As you share more you’ll get more feedback both good and bad. You can’t selectively listen to only the good or only the bad. Listen to it all. Don’t let the good go to your head and don’t let the bad get you down.

When you disagree with a critique move on. When you think someone may be right explore deeper what they said and what you can learn from it.

Ultimately you have to decide the value of any feedback you receive, but to do that you need to be open to receiving it.

Offer Feedback to Others

A number of years ago I took a writing course where students would spend time critiquing each other’s work. Most thought the value was in the feedback they received. I found more value in offering feedback to others.

Instead of offering a few quick thoughts I would dig deep into what they wrote and offered opinions on how I thought they could improve their work.

Whether or not people listened to my feedback was irrelevant to my growth. I found that in critically thinking how to improve the work or others I was greatly learning to improve my own work as well.

Rinse and Repeat

You can never stop learning and improving. Even the best among us have more to learn and room for growth. Continue to identify areas for improvement and areas of strengths and keep sharing both as you feel comfortable.

Objectively listen to the feedback you receive and let it help you grow.

I know I’m making the above sound easier than it really is, but it does work. Each small step you take leads you closer to your greater goal. In time you’ll feel more confident about more of your process and you’ll find yourself less hesitant to share in general.

Summary

All creative people struggle with confidence at times. It’s the nature of doing work where the quality of results is part subjective.

It’s not just you or me. It happens to all of us. It leads many to hide their design process and work in secret, which only feeds into the lack of confidence you feel.

The more we design in the open, the more we’re willing to share and open ourselves to feedback, the better we get and the more confidence we gain.

You don’t need to share everything at once, but the sooner you enter the designing in the open process, the quicker you’ll improve as a designer.

Also know that while this post has specifically focused on design the ideas above can be applied to anything in your life where you lack confidence and want to improve.

Go to Source

How To Build A Responsive site

Believe it or not we’ve already covered all the technical details for building responsive sites over the last few weeks. In order to create a responsive site we need to use:

• Flexible grids — which are based on relative measurements, ideally elastic sites that are relative to something internal to the design. We want to be developing from the inside out. Content out, not canvas in.
• Flexible images — that can adapt to our adapting layout. We want to create images that can resize as the layout resizes while still looking good.
• Media queries — to serve different presentation (and possibly different content) to different device, OS, browser, screen width, etc

The last few weeks we’ve gone over the details of each of the above and I’ll refer you back to those posts for the details. Even better would be to take a look at the work of Ethan Marcotte.

Ethan is the person responsible for responsive web design and my posts, including this one have relied heavily on his work and writing.

• Responsive Web Design
• Example Site for Responsive Design
• Fluid Grids
• Fluid Images
• A Book Apart, Responsive Web Design

I can’t recommend the links above enough, particularly the last link, Ethan’s new book on responsive web design. Seriously it’s $9 for a digital copy. If you want to learn responsive design spend the $9 and read the book.

With the technical details covered elsewhere I want to spend the rest of this post with some thoughts about responsive design including some ideas for developing a responsive workflow.

InteractiveWall from Festo HQ on Vimeo.

Thoughts About Responsive Design

I’m only beginning my exploration of responsive design. I can’t offer advice based on experience at the moment so I’ve been leaning on the advice of others, mostly Ethan. I would however like to share some thoughts as one beginning the exploration.

A couple of months ago when I began talking about different css layouts. I had listed some pros and cons of responsive layouts and later added:

However in the end it’s browser and object detection. If history is a teacher developers will push toward standards over detection and device makers will become more consistent in how they render websites.

At the time I was a little too focused on the media query part (perhaps I was just reaching for cons to balance the pros in that post). I’d like to amend my previous thoughts.

The problem in the past with browser detection was how complicated it was and that it didn’t always work. Media queries don’t have those same issues.

I wasn’t entirely sold on responsive design then. I am now. I can now clearly see it as the way forward.

The Way Forward

Mark Boulton recently posted that responsive design is s shift in how people design websites.

He suggested that designers are still working out the details and eventually something else will come along leading to another shift, but this is the current path forward.

I completely agree. This is where web design is currently heading and if you ignore responsive design you stand a good chance of being left behind and designing sites that look out of date.

Is One HTML Document Enough?

In his book Ethan mentions that responsive design is serving one html document to countless browsers and devices to ensure the design is as portable as possible.

He also points out that not everyone agrees with this approach and their arguments mainly come down to 2 things.

• A device implies a context as different devices have different capabilities
• Visitor priorities and goals differ in different contexts

Because of the above some think serving different html documents to different devices is the better approach.

Both points above are important considerations, but they rest on assumptions that may or may not be true. Research suggests the most common use of mobile devices occurs in the home. The context probably isn’t as different as some might assume.

Viewing on a tablet likely doesn’t lead to significantly different goals and priorities than viewing in a browser, especially while leaning back on the couch. The context is probably more dependent on where a person is physically than the device used.

For some sites it will make sense to have a dedicated mobile version. For most it probably isn’t worth the extra effort and cost. Personally I think some of these changes in priority and context can be accounted for through responsive design.

I’m sure something will come along later that will be better, but I’m also sure this is the right path to walk right now. The technical details with improve and designers will find better ways to work with those details.

What might be even more important where responsive design is concerned is the thought process and workflow it inspires.

Developing a Responsive Workflow

In his book Ethan walks through what he considers a good responsive workflow and mentions the following.

• Identify breakpoints — Which devices are you designing for and what resolutions do they have?
• Prototyping — Design changes for device and resolution will be harder to show with comped images so move things to the browser sooner. Create a prototype and then refine it in the browser.
• Mobile first — Decide what’s most important for your audience and serve only what’s needed to the least capable devices instead of hiding things for that device.
• Progressive enhancement — – Scale your design up from the minimum instead of scaling it down from the maximum. Load content and code intelligently for each device and device characteristic

Identifying Breaking Points

Last week when discussing media queries I closed with a question about the breaking points in our designs. Where should we set those breaking points and how many should we set.

I don’t think there’s a single answer to either question. It will come down to the specifics of your design, audience, etc. However we can look at the sizes of the common devices people use to consider good values for our breakpoints.

• 320 px— smart phones in portrait mode
• 480 px — smart phones in landscape mode
• 600 px — smaller tablets like the Kindle (600 x 800) or Nook (600 x 1024)
• 768 px — tablet in portrait
• 1024 px — tablet in landscape and netbooks
• 1200 px — low end for widescreen displays
• 1600 px — widescreen displays

You wouldn’t set different media queries and css for each of the above, but you’d probably choose from the values above to set your own points of change.

The site Media Queries (a great site for responsive design examples) recommends using 4 breaking points as screen shots when submitting your responsive design. 320px, 768px, 1024px, 1600px.

Again how many and which you use really comes down to the specifics of your project and design.

Prototyping

In recent years there’s been input from the design and development community in regards to our general workflow for building sites. A big part of the workflow has usually been designing comps with pixel perfection in Photoshop, Fireworks, or similar. Many have begun to rethink that approach.

Remember we don’t have the constraint of the format to guide us. Tools used to design for the web need to be more flexible than their equivalents for print. You can’t see how a design responds in a single Photoshop comp.

Better is to take things to the browser sooner. Create a working prototype so you and clients can see how the design responds and keep iterating and refining.

That doesn’t mean we should ignore Photoshop or wireframing or anything else where we work solely in pixels. Instead it’s about moving to the browser as soon as possible.

MinneWebCon: Designing for Today’s Web from ccemedia on Vimeo.

Mobile First

The idea behind mobile first deserve its own post so understand what I’m saying here barely scratches the surface. The mobile first ideas come from Luke Wroblewski and below are two of his posts on the subject.

Above is a one of Luke’s presentations on mobile first. I’ve also included the PDF that goes with the presentation in the links below.

• Mobile First
• Mobile First Helps with Big Issues
• Today’s Web (PDF)

We’re trained to think browser on computer first and then remove or hide things for different devices. This is really the opposite approach we should take. We should start where things need to be more minimal.

Mobile first forces us to think about what absolutely needs to be included in a design and to serve them to the least capable devices. We should be scaling things up instead of reducing them down.

Progressive Enhancement

A natural next step from mobile first is progressive enhancement. Start with the minimum and build from there.

As part of this Ethan suggests our media queries should take on a slightly different form than how we’ve talked about them until now.

/* default styles */
	@media screen and (min-width: 320px)
/* small screen */
	@media screen and (min-width: 600px)
/* desktop */
	@media screen and (min-width: 1024px)
/* wide screen */
	@media screen and (min-width: 1200px)

Notice the change from max-width to min-width. Here we’re sending the least width the most necessary styles and from there building up as more can be included for wider screens.

We can also serve smaller devices smaller images and replace those images with larger versions as screen size increases. We might even choose to only add some content for wider screens and more capable devices.

Again much of this will come down to the specifics of your site and audience.

This overall approach is probably somewhat different than what most of you are used to. I know much of it is different for me. However it makes a lot of sense to approach web design this way and I’ve been slowly changing my own workflow.

Summary

Responsive design is something I think we all need to pay attention to. Mark Boulton is right. This is not a trend. It’s a shift in web design thinking.

Responsive design takes a number of best practices like elastic layouts and progressive enhancement and combines them into a new way to think about and build websites.

Once again the basics of responsive design come down to:

• flexible layouts
• flexible images
• media queries

None of the above is difficult. The hardest part will likely be changing your workflow and developing a responsive mindset.

I’m still learning to make these changes myself and I’m sure over time I’ll have more to say about everything we’ve been talking about these last few weeks.

Out of curiosity how many of you are currently building responsive sites or are looking to develop them? What have you found are their pros and cons? What have you found to be the easier and more difficult aspects of responsive design?

Go to Source

Safari users may be familiar with the Reader button that also strips away boilerplate and sometime in the fall iOS5 users will take that further with Reading List. You can add feed readers to the list of ways readers are absorbing content without design.

On the opposite end we have art direction, where pages are specifically designed based on the page copy, while still working with the overall brand of the site.

These things seem to be in opposition. One is adding design to content while the other is stripping it away.

As more people are turning to services like Readability and Instapaper some are drawing the conclusion that people don’t care about design. I disagree.

I want to talk about a couple of design principles that point toward people preferring design.

• Performance vs. Preference — the idea that the designs that help people perform optimally are often not the same designs that people find most desirable
• Aesthetic-Usability Effect — the idea that aesthetic designs are perceived as easier to use than less-aesthetic designs

After walking through these 2 principles I’ll bring the discussion back to art direction and design vs minimalist reading services.

Performance vs. Preference

The famous example of performance vs preference is the Dvorak keyboard seen above.

Developed in the 1930s the Dvorak keyboard has been shown to increase typing efficiency by roughly 30%. If you ask most people if they’d like to type 30% faster with fewer errors they’d all say yes.

• Qwerty keyboard — designed to prevent jamming of mechanical parts in typewriters
• Dvorak keyboard — designed to maximize typing efficiency

Are you currently using a Dvorak keyboard or the same qwerty keyboard most everyone else uses?

One or two of you might use Dvorak, but my guess is most are using qwerty. It’s the keyboard we’re all familiar with. It’s the one that comes with every computer by default.

Switching now would mean retraining our fingers and relearning how to type. Even with the knowledge that Dvorak is the better keyboard are you planning on getting one? Probably not.

The reasons people prefer one design over another are a combination of many factors, some of which have nothing to do with performance.

• Is it aesthetically pleasing?
• Does it make me feel better?
• Does it conform to my standard way of doing things?
• Do I need to relearn something to use it?

A better mousetrap isn’t necessarily the most popular mousetrap. When designing we need to consider as many factors as possible in regards to the preference of our audience. Better performance will play a role, likely a large one, but it isn’t the only factor.

To find out what people truly prefer we need to observe them interacting with our designs. What people say they want isn’t always what they really want. People are also generally poor at differentiating features they like from features that improve performance.

Think usability testing over focus groups.

Aesthetic-Usability Effect

In processing our visual surroundings we all form opinions and judgements that affect future visual processing. These quick and early perceptions are resistant to change and bias subsequent interactions.

Early visual impressions ultimately influence long-term use.

We also have a bias toward attractive things. We perceive attractive, aesthetically pleasing people and things more positively.

Because we feel more positive about an aesthetically pleasing design we find that design easier to use.

Whether or not the aesthetic design really is easier to use is irrelevant. We think it is and as a result we spend more times with it. We use it more and as a result learn to use it better.

In time the aesthetically pleasing design may really be more usable because of our extra experience and knowledge using it.

On the other hand a more usable design that’s aesthetically unappealing can suffer from a lack of acceptance and use. If no one is using your usable design how usable is it?

Aesthetic designs result in a positive emotional response. They make people more tolerant of mistakes and flaws and problems with the design.

We should create more aesthetically pleasing designs because they

• are perceived as easier to use
• are more readily accepted
• are used more often over time
• lead to more tolerance of design problems

The feelings of affection we have for more aesthetically pleasing designs can lead to product and brand loyalty. They can promote creative thinking and problem solving. Aesthetics can even communicate function.

Negative feelings about a design do the opposite. The can stifle creativity and lead to narrow thinking. This is especially true in stressful environments and often leads to a reduction in performance.

Making things beautiful has a great impact in making them more usable.

Art Direction vs Readability

So what about art direction? What about design? Are readers telling us they don’t care about aesthetics?

Services like Readability, Instapaper, and soon Reading List are gaining in popularity, however that doesn’t indicate that people don’t care about design. Reread the 2 principles described above and think about whether or not design is important.

Something doesn’t seem right. The design principles above tell us people should should prefer reading designed content in a browser, but more and more seem to prefer reading in a way that bypasses the browser.

There are a couple of explanations for this seeming incongruity.

• Services like Instapaper and Readability make reading more convenient, which isn’t really a question of visual design. Part of the growing success of these services is they allow us to read content when we have more time to read it.
• Where design is concerned most people have unfortunately been given poor design. The focus of the design of many sites is on anything but the content. The focus is on the ads, the brand, the calls-to-action, everything but the content it seems.

Consider how Readability presents content. It’s very well designed and quite beautiful in my opinion. Is it any wonder people choose it over reading many sites directly?

For designers the takeaway shouldn’t be that we need to strip away everything, though it’s probably a good start.

The takeaway should be that we need to create quality and aesthetically pleasing designs focused on what our audience wants, our content.

Create a better reading environment and your audience will be happy to read inside your design. They’ll gladly use services to mark something to be read later and then click through to your site to do the reading.

Summary

Design is important. It plays a large role in the success of any content, whether that content is an interesting article or sales copy to help sell a product.

With so much information online people are turning to services where they can read content later and often in a stripped down fashion. This isn’t a reaction to design. It’s a reaction to time constraints and bad design.

Principles like performance vs preference and the aesthetic-usability effect show us that design can have a great impact in what people prefer and in how easy a system is to use.

What we should be taking away from the popularity of Readability, Instapaper, and soon Reading List, isn’t that our visitors want less design. We should be realizing that they want more quality design.

Go to Source

All of these posts rely heavily on the work of Ethan Marcotte and so before getting started I want to point you again to some of Ethan’s writing on the subject.

• Responsive Web Design
• Example Site for Responsive Design
• Fluid Grids
• Fluid Images
• A Book Apart, Responsive Web Design

I highly recommend the last link above, which is Ethan’s new book on responsive design. If you buy the digital version (PDF, ePub, and mobi) it’ll only set you back $9, which will be money well spent.

Media Types

As I mentioned above media queries are a way to serve different css based on device and device characteristics.

For example we can send certain css to a browser on a laptop open 1200px wide and send different css to a mobile browser open to 480px and a third set of css to a tv screen displaying at 1024px.

We’ve actually been using a part of media queries for years, namely media types so let’s been there.

The html below should look familiar to you. We use it all the time to include a css file in an html document.

< link rel="stylesheet" type="text/css" href="core.css"  media="screen" / >

Note the media=”screen” at the end. That’s a media type. You may have written a print specific stylesheet at some point for which you’d use media=”print”

There are a variety of other media types you could use beyond screen and print.

• all — for all the media types below
• braille — for braille tactile feedback devices
• embossed — for paged braille printers
• handheld — for handheld devices like mobile phones
• print — for printed material
• projection — for projected presentations
• screen — for color computer screens
• speech — for speech synthesizers
• tty — for teletypes, terminals, and other devices with limited display capabilities
• tv — for televisions and television like devices

Media types are useful, but they aren’t enough. Not every device lists itself properly and realistically what works on one handheld device or tv might not work on another.

Enter media queries.

Media Queries

Building on top of media types the W3C added media queries. A simple media query looks like the following:

@media screen and (max-width: 1200px) {
	css here&hellip
}

It begins with the media type (in this case screen) and is followed by the query as a feature: value pair. Here we’re targeting browsers with a max-width of 1200px

The type and the query are joined by the “and” operator. We’ll see in a bit that we can chain this operator to target very specific devices and characteristics

Above we started the media query with @media, but there are actually 3 ways to include media queries.

• @media which is added in your css file — @media screen and (max-width: 1200px) {css here}
• as part of html link element —
• @import in .css — @import url(“my-style.css”) screen and (max-width: 1200px)

The @media method is probably the most common and it has the advantage of keeping all your css in a single css file. It’s likely what you’ll use most often in practice.

There are a baker’s dozen media features you can use with media queries summarized in the table below.

In the values above viewport is defined as the part of the screen/paper where the document is rendered and includes any scrollbar. The rendering surface defines the width of the screen.

Yeah, it’s confusing to me too. Typically though you’ll target the display area or viewport.

Chaining Media Queries

As I said above we can use the “and” operator to chain queries like so:

@media screen and (max-width: 1200px) and (orientation: landscape)

We can also use the “not” operator as in:

@media not projection and (max-width: 1200px)

to target devices other than projection with a max-with of 1200px. The “not” operator is evaluated last so the above is evaluated as:

@media not ( projection and (max-width: 1200px) )

There’s no specific “or” operator, but can imply “or” by using a comma.

@media screen and (min-width: 800px) and (orientation: landscape),
  @media screen and (max-width: 1200px)

The above would target both screens with a min-width of 800px in that are in landscape mode and screens with a max-width of 1200px.

The above queries aren’t necessarily those you would use in practice, but you can imagine how powerful and targeted this chaining can be.

A New Meta Tag

When Apple created mobile safari they also created a new meta tag attribute for it.

To display web pages mobile safari actually displays pages as they appear at 980px wide. It then shrinks down the page so it fits within the 320 x 480 display. The 980px is the viewport.

Other mobile browsers followed suit with the larger viewport and shrinking. We’d like things to be a little more consistent with the actual size of the device and fortunately we have the new meta tag.

<meta name="viewport" content="width=320" />

Instead of setting an absolute viewport size we can be more flexible and set

<meta name="viewport" content="initial-scale=1.0, width=device-width" />

The above basically sets the zoom level to 100%

Browser Support

Browser support for media queries is generally good, though as is often the case IE took awhile to catch up. Media queries are available in IE9, but for anything below we need to do a little extra to get them work.

There are some javascript libraries Ethan recommends we use.

• ss3-mediaqueries.js
• respond.js

Both will add support for media queries to older browsers.

Why Use Media Queries

Even flexible layouts can bend or worse break. Flexible layouts can resize and accommodate a variety of width ranges, but they can still fail or simply look and work less than ideal above and below certain widths.

A different design might also be more effective on different devices. For example:

• Using 3 columns on a widescreen browser, 2 columns on a tablet, and a single column on a mobile phone.
• Displaying different content to different devices. Not all would agree with this idea.
• Changing the proportions within a design as the size of the viewport changes.
• Reining in line lengths as the browser is opened wider.
• Adding or removing whitespace at different screen sizes.
• Creating different visual hierarchies dependent on device and screen size.

A variety of conditions beyond the above could lead us to modify our designs based on any of the devices or features we can target.

In the simple case of screen width a good choice is to allow our designs to be flexible throughout a range or widths and then modify the design for different sets of widths.

Of course this begs the question what ranges of widths should we use? What breaking points should we set? I’ll leave the question hanging until next week when we talk more about developing a responsive design workflow.

Summary

Media Queries are a great way to target different devices and even better different characteristics of different devices. And the best part is they’re intuitive and relatively easy to use.

They take the form of media type and media query (as a feature: value pair) and through the ability to chain operators allow us to build powerful and highly targeted queries.

Through media queries we can set a variety of points over which our flexible layout might bend and serve different css to prevent those bends from breaking and causing problems for our visitors.

By combining flexible layouts and flexible images and other media with media queries we have the ability to create designs that respond to the many different ways our audience might access and view our sites.

Next week we’ll take a look at responsive design and talk generally about how we should think about building a responsive workflow.

Go to Source

I’ve been wanting to create a full book review section of the site where I could offer more complete reviews and provide as much detail as I can to help you decide. Since I haven’t yet gotten around to creating that section hopefully this post will suffice for now.

Note: Below each book are links to Amazon and Barnes & Noble. The B&N links are affiliate links so if you buy I’ll make a couple of bucks. There are no affiliate links to the books on Amazon.

In most cases the prices are about the same at each store, though in a few cases the books at Amazon are significantly cheaper. While I’ve linked to the paperback copies some of these books also have digital versions.

Design Basics

The two books below are good as an introduction to design. They’re the first 2 books I read on the subject before I considered becoming a designer.

The Non-Designers Design Book
by Robin Williams

Just like the title says. If you’re a non-designer this is the book for you. My series of posts on design basics comes entirely from what I learned reading it.

The information here won’t make you the world’s greatest designer, but it will introduce you to some basic design principles that will take you from amateur designer and place you on the path to becoming a professional.

• Amazon
• Barnes & Noble

Design Basic Index
by Jim Krause

Jim Krause wrote a series of books to give practical information to designers. They’re meant to be able to look things up quickly. He has books on choosing a color scheme or finding a typeface in addition to this one.

Design Basic Index is filled with exercises and quick tips about different principles of design. It’s more in-depth in what it covers than the Non-Designers Design Book and will give you a good foundation for some the books mentioned below

• Amazon
• Barnes & Noble

Usability

Both of the books below have become classics and each has a follow-up book on my future reading list.

Don’t Make Me Think
by Steve Krug

Perhaps the bible of usability for non-usability experts. It focuses on web design and everything follows from a premise of not making your visitors think more than they have to in order to complete tasks.

It’s a quick read packed with information and lots of screenshot examples. Much of what’s in the book has now become common sense usability practice.

• Amazon
• Barnes & Noble

The Design of Everyday Things
by Donald Norman

This book is a little more in-depth about designing things to be usable. My series of posts on minimizing errors comes mainly from what’s written here.

Don Norman fills the book with plenty of real life stories of unusable and usable design that make the book enjoyable to read while sharing solid principles. After reading it you won’t look at ordinary objects quite the same way again.

• Amazon
• Barnes & Noble

Design Principles and Design Elements

Each of the books below focus on different design principles and/or working with design elements like lines and shapes. I’ve taken so many post ideas from the first book I couldn’t possibly list them all.

Universal Principles of Design
by William Lidwell, Kristina Holden, Jim Butler

This book is an attempt to begin a conversation about 125 different principles of design. Each principle is covered in a single page alongside a page of examples from the real world.

One of my favorite design books with all the different aspects it covers. The book isn’t about where to place a line or what shape to use to communicate something. Rather it deals with things like the psychology behind the attractiveness bias and Hick’s Law.

• Amazon
• Barnes & Noble

Design Elements: A Graphic Style Manual
by Timothy Samara

Design Elements walks through the different elements at a designer’s disposal, like form and space, point, line, surface, and volume, and then looks at both type and imagery.

My series of posts on the elements of design comes mainly from this book. It’s a great book for gaining a solid foundation of the different elements of design and how to go about using them.

• Amazon
• Barnes & Noble

The Elements of Graphic Design
by Alex White

This is a shorter book, but one packed with information. It covers many of the same topics as Design Elements above. Alex White has a unique take on things so you get a different perspective on a number of topics.

I learned quite a bit about working with space as well as working compositional balance into a design. My 7 components of design series was inspired by this book.

• Amazon
• Barnes & Noble

Visual Language

These books on visual language are about what different visual elements communicate. The latter 2 look deeply at the subject and consider how we physically and psychologically see and perceive the objects around us.

Visual Grammar
by Christian Leborg

This is a concise book that categorizes different visual objects and how they interact with each other. As the title implies it’s an attempt to create a visual grammar for the basic visual objects we use and their interactions with each other and with us.

My post on visual grammar comes from this book and I often referred to it while working on the elements of design series mentioned above.

• Amazon
• Barnes & Noble

Visual Thinking for Design
by Colin Ware

This is definitely not a quick read. It’s not a long book, but it gets very deep into things like how the eye works and how information is perceived and stored in memory.

There’s a good mix of theory and practical application on the subject of visual cognition.

This post on verbal and visual communication comes mainly from this book, with a little help from the one below.

• Amazon
• Barnes & Noble

Visual Language for Designers
by Connie Malamed

This book is similar to the one above in terms of subject. I think it was a little easier to read as it placed a little more focus on the practical.

I read both back to back so they mix a little in mind as to what was in each. Both are good reads if you’re interested in learning about how we react to our visual surroundings.

Both aim to help you visually communicate abstract ideas and messages.

This post on visual perception and memory comes from this book, with a little help from the one above.

• Amazon
• Barnes & Noble

Typography

I’ve mentioned a few times over the last year that I’ve been reading a lot about typography. The more I learn about type the more I realize how much more there is to know and how little I know the subject.

The Elements of Typographic Style
by Robert Bringhurst

This is the modern bible of typography. I’d bet it’s on the shelf of every designer who’s ever been interested in the subject. It’s probably the first book most buy about typography.

Bringhurst is a poet and the writing within shows that. The book is filled with practical information such as when and how to use things like em dashes and en dashes. It closes with brief discussions of many different typefaces and type designers.

• Amazon
• Barnes & Noble

Thinking with Type
by Ellen Lupton

Ellen Lupton’s book is divided into 3 sections, letter, text, and grid. Each section begins with an historical essay and then gets into more practical definitions of the subject.

The book is filled with visual examples of most everything discussed in the text, which helps to illustrate many of the principles.

• Amazon
• Barnes & Noble

Thinking in Type
by Alex White

Another book by Alex White. I bought this after enjoying the one mentioned above.

I like how Professor White comes at things from a different perspective at times giving me a new perspective in the process. For example this post on readability and legibility.

This is another book filled with visual examples illustrating all of the concepts discussed.

• Amazon
• Barnes & Noble

Detail in Typography
by Jost Hochuli

A very short book and yet one filled with so much information it’s a must read. I’m still not sure how it managed to fit so much in to so few pages.

It starts by looking at individual letters and works its way out to words, lines, linespacing, and the quality of type. Lots of information about micro-typography. This book really gets into the details.

• Amazon
• Barnes & Noble

Stop Stealing Sheep and Find out How Type Works
by Erik Spiekermann and E.M. Ginger

Every time I’ve seen Erik in a video online I’ve learned so much and reading this book was no different. A great introduction to typography and a very enjoyable read.

I recently read it after reading many of the other books in this section, but it’s probably a good first book on typography along with Bringhurst. There are fun and interesting stories in its pages as well as some great practical details about using type.

• Amazon
• Barnes & Noble

The Fundamentals of Typography
by Gavin Ambrose and Paul Harris

One of the things I liked about this book was it’s first chapter which contains a walk through of type through history. Some of the other books here also cover typographic history, but I think this was first time it was connected for me along a timeline.

The rest of the topics are similar to many of the other books listed here. It likely works better as an introduction to typography than as a detailed text.

• Amazon
• Barnes & Noble

Typographic Design: Form and Communication
by Rob Carter, Ben Day, and Phillip Meggs

Another recent read for me. It also has a good historical perspective before jumping in to things like typographic anatomy, syntax, legibility, grids, and beyond.

There are plenty of topics discussed in the book. I also enjoyed the design of the book itself as well as many of the examples it uses. I think this is also one of those classic texts used in classrooms.

• Amazon
• Barnes & Noble

Usually when writing about typography (such as the 2 posts below) I draw from several of the above books as many discuss the same topics, each with its own details and perspective.

• Counterpart and Counterpoint in Typographic Hierarchy
• Legibility And Readability In Typographic Design

Grids

Building on typography is the typographic grid, something I’m still trying my best to learn.

The first 3 books below are similar, which makes sense as they’re from the same author. Each is really a walkthrough of some ideas on grids and geometry along with student solutions to exercise problems. Each contains vellum overlays to show how certain designs were constructed.

I’ve come across reviews where people thought all 3 were more style than substance. I have to admit that at times reading each part of me felt the same. However in the end I enjoyed and learned from all 3 books.

If it means anything I did buy all 3 and have read through each more than once.

Grid Systems
by Kimberly Elam

This book introduces some exercises and then shows student solutions to those exercises. The idea of each is to place different shapes (rectangles and circles) on the page in interesting ways.

Some shapes are representative of lines of blocks of text. Solutions with actual text instead of their representative shapes are also shown.

• Amazon
• Barnes & Noble

Geometry of Design
by Kimberly Elam

This book discusses different geometric and mathematical systems like the golden ratio, for building grids.

It shows how to construct the different grid systems it discusses and shows them in practice in works of art and architecture. The idea is to help understand how different geometrical systems provide an aesthetic beauty to the works they’re used in.

• Amazon
• Barnes & Noble

Typographic Systems
by Kimberly Elam

This last once focuses on type, but I listed it here, because it deals with systems for organizing type on the page as opposed to typographic anatomy. Also it’s similar in form to the two other Kimberly Elam books above.

It works through 8 different systems for placing type on the page, including radial, grid, and modular systems.

One last word about this and the 2 books above. If you learn well through seeing abstract visuals you’ll probably like all 3. Each is less long text explanations and more quick intros with the visuals serving as the explanations.

• Amazon
• Barnes & Noble

Making and Breaking the Grid
by Timothy Samara

This book looks at designs that both use a grid and those that break out of it. I often pull it off the shelf just to look at the designs for inspiration. There are some absolutely beautiful examples inside.

Each of the two sections begins with a short intro followed by many examples of designs along with some explanation about how the design fits into a grid or breaks out of it. Each example also shows which grid is being used in the design.

The two post below were both taken directly from this book.

• Anatomy of a Typographic Grid
• 4 Types of Grids And When Each Works Best

• Amazon
• Barnes & Noble

Basics Design: Grids
by Gavin Ambrose and Paul Harris

This book looks into different grid elements like baselines and columns as well as talking about different grid usage ideas. There are plenty of examples of grid based designs throughout.

I preferred Samara’s book to this one, but enjoyed both. The approach here is different than Making and Breaking the Grid. There are some different topics covered and it also has some great examples of grid based design.

• Amazon
• Barnes & Noble

Ordering Disorder: Grid Principles for Web Design
by Khoi Vinh

Khoi Vinh’s book is the only one int his section that’s entirely focused on web design. Khoi is one of the people responsible for bringing a focus on grids to the online world.

This is a must read if you want to work with grids online. It helped answer a number of questions about how to develop a grid I had after reading the books above.

Khoi takes you through a working example constructing a basic grid and then developing several of the typical pages you’d find on any website using that grid.

If you had to pick 2 books from this section I’d go with Making and Breaking the Grid and this one.

• Amazon
• Barnes & Noble

Summary

There are obviously a lot of books above (23 I hope) and you might be wondering which to read first. If I mentioned a book as a must read or a bible it’s probably one I would recommend first.

Otherwise visit Amazon or the Barnes & Noble site and read some reviews or walk into a store and begin reading.

The majority of the books above I discovered through recommendations by other web designers. A few I found searching Amazon and a few I found searching the shelves at Barnes & Noble.

I know some of these books are available as eBooks for iPad, Kindle, or Nook and they should offer free samples. I’d like to tell you that you’ll love all of them, but I know we all have different tastes in reading material.

I can tell you that these are all books on my many bookshelves and I’ve read each and every one, some several times, and I often grab them as references.

If you have any books to recommend about design please share. I’m always looking for new books to read.

Go to Source

I’ve been wanting to create a full book review section of the site where I could offer more complete reviews and provide as much detail as I can to help you decide. Since I haven’t yet gotten around to creating that section hopefully this post will suffice for now.

Note: Below each book are links to Amazon and Barnes & Noble. The B&N links are affiliate links so if you buy I’ll make a couple of bucks. There are no affiliate links to the books on Amazon.

In most cases the prices are about the same at each store, though in a few cases the books at Amazon are significantly cheaper. While I’ve linked to the paperback copies some of these books also have digital versions.

Design Basics

The two books below are good as an introduction to design. They’re the first 2 books I read on the subject before I considered becoming a designer.

The Non-Designers Design Book
by Robin Williams

Just like the title says. If you’re a non-designer this is the book for you. My series of posts on design basics comes entirely from what I learned reading it.

The information here won’t make you the world’s greatest designer, but it will introduce you to some basic design principles that will take you from amateur designer and place you on the path to becoming a professional.

• Amazon
• Barnes & Noble

Design Basic Index
by Jim Krause

Jim Krause wrote a series of books to give practical information to designers. They’re meant to be able to look things up quickly. He has books on choosing a color scheme or finding a typeface in addition to this one.

Design Basic Index is filled with exercises and quick tips about different principles of design. It’s more in-depth in what it covers than the Non-Designers Design Book and will give you a good foundation for some the books mentioned below

• Amazon
• Barnes & Noble

Usability

Both of the books below have become classics and each has a follow-up book on my future reading list.

Don’t Make Me Think
by Steve Krug

Perhaps the bible of usability for non-usability experts. It focuses on web design and everything follows from a premise of not making your visitors think more than they have to in order to complete tasks.

It’s a quick read packed with information and lots of screenshot examples. Much of what’s in the book has now become common sense usability practice.

• Amazon
• Barnes & Noble

The Design of Everyday Things
by Donald Norman

This book is a little more in-depth about designing things to be usable. My series of posts on minimizing errors comes mainly from what’s written here.

Don Norman fills the book with plenty of real life stories of unusable and usable design that make the book enjoyable to read while sharing solid principles. After reading it you won’t look at ordinary objects quite the same way again.

• Amazon
• Barnes & Noble

Design Principles and Design Elements

Each of the books below focus on different design principles and/or working with design elements like lines and shapes. I’ve taken so many post ideas from the first book I couldn’t possibly list them all.

Universal Principles of Design
by William Lidwell, Kristina Holden, Jim Butler

This book is an attempt to begin a conversation about 125 different principles of design. Each principle is covered in a single page alongside a page of examples from the real world.

One of my favorite design books with all the different aspects it covers. The book isn’t about where to place a line or what shape to use to communicate something. Rather it deals with things like the psychology behind the attractiveness bias and Hick’s Law.

• Amazon
• Barnes & Noble

Design Elements: A Graphic Style Manual
by Timothy Samara

Design Elements walks through the different elements at a designer’s disposal, like form and space, point, line, surface, and volume, and then looks at both type and imagery.

My series of posts on the elements of design comes mainly from this book. It’s a great book for gaining a solid foundation of the different elements of design and how to go about using them.

• Amazon
• Barnes & Noble

The Elements of Graphic Design
by Alex White

This is a shorter book, but one packed with information. It covers many of the same topics as Design Elements above. Alex White has a unique take on things so you get a different perspective on a number of topics.

I learned quite a bit about working with space as well as working compositional balance into a design. My 7 components of design series was inspired by this book.

• Amazon
• Barnes & Noble

Visual Language

These books on visual language are about what different visual elements communicate. The latter 2 look deeply at the subject and consider how we physically and psychologically see and perceive the objects around us.

Visual Grammar
by Christian Leborg

This is a concise book that categorizes different visual objects and how they interact with each other. As the title implies it’s an attempt to create a visual grammar for the basic visual objects we use and their interactions with each other and with us.

My post on visual grammar comes from this book and I often referred to it while working on the elements of design series mentioned above.

• Amazon
• Barnes & Noble

Visual Thinking for Design
by Colin Ware

This is definitely not a quick read. It’s not a long book, but it gets very deep into things like how the eye works and how information is perceived and stored in memory.

There’s a good mix of theory and practical application on the subject of visual cognition.

This post on verbal and visual communication comes mainly from this book, with a little help from the one below.

• Amazon
• Barnes & Noble

Visual Language for Designers
by Connie Malamed

This book is similar to the one above in terms of subject. I think it was a little easier to read as it placed a little more focus on the practical.

I read both back to back so they mix a little in mind as to what was in each. Both are good reads if you’re interested in learning about how we react to our visual surroundings.

Both aim to help you visually communicate abstract ideas and messages.

This post on visual perception and memory comes from this book, with a little help from the one above.

• Amazon
• Barnes & Noble

Typography

I’ve mentioned a few times over the last year that I’ve been reading a lot about typography. The more I learn about type the more I realize how much more there is to know and how little I know the subject.

The Elements of Typographic Style
by Robert Bringhurst

This is the modern bible of typography. I’d bet it’s on the shelf of every designer who’s ever been interested in the subject. It’s probably the first book most buy about typography.

Bringhurst is a poet and the writing within shows that. The book is filled with practical information such as when and how to use things like em dashes and en dashes. It closes with brief discussions of many different typefaces and type designers.

• Amazon
• Barnes & Noble

Thinking with Type
by Ellen Lupton

Ellen Lupton’s book is divided into 3 sections, letter, text, and grid. Each section begins with an historical essay and then gets into more practical definitions of the subject.

The book is filled with visual examples of most everything discussed in the text, which helps to illustrate many of the principles.

• Amazon
• Barnes & Noble

Thinking in Type
by Alex White

Another book by Alex White. I bought this after enjoying the one mentioned above.

I like how Professor White comes at things from a different perspective at times giving me a new perspective in the process. For example this post on readability and legibility.

This is another book filled with visual examples illustrating all of the concepts discussed.

• Amazon
• Barnes & Noble

Detail in Typography
by Jost Hochuli

A very short book and yet one filled with so much information it’s a must read. I’m still not sure how it managed to fit so much in to so few pages.

It starts by looking at individual letters and works its way out to words, lines, linespacing, and the quality of type. Lots of information about micro-typography. This book really gets into the details.

• Amazon
• Barnes & Noble

Stop Stealing Sheep and Find out How Type Works
by Erik Spiekermann and E.M. Ginger

Every time I’ve seen Erik in a video online I’ve learned so much and reading this book was no different. A great introduction to typography and a very enjoyable read.

I recently read it after reading many of the other books in this section, but it’s probably a good first book on typography along with Bringhurst. There are fun and interesting stories in its pages as well as some great practical details about using type.

• Amazon
• Barnes & Noble

The Fundamentals of Typography
by Gavin Ambrose and Paul Harris

One of the things I liked about this book was it’s first chapter which contains a walk through of type through history. Some of the other books here also cover typographic history, but I think this was first time it was connected for me along a timeline.

The rest of the topics are similar to many of the other books listed here. It likely works better as an introduction to typography than as a detailed text.

• Amazon
• Barnes & Noble

Typographic Design: Form and Communication
by Rob Carter, Ben Day, and Phillip Meggs

Another recent read for me. It also has a good historical perspective before jumping in to things like typographic anatomy, syntax, legibility, grids, and beyond.

There are plenty of topics discussed in the book. I also enjoyed the design of the book itself as well as many of the examples it uses. I think this is also one of those classic texts used in classrooms.

• Amazon
• Barnes & Noble

Usually when writing about typography (such as the 2 posts below) I draw from several of the above books as many discuss the same topics, each with its own details and perspective.

• Counterpart and Counterpoint in Typographic Hierarchy
• Legibility And Readability In Typographic Design

Grids

Building on typography is the typographic grid, something I’m still trying my best to learn.

The first 3 books below are similar, which makes sense as they’re from the same author. Each is really a walkthrough of some ideas on grids and geometry along with student solutions to exercise problems. Each contains vellum overlays to show how certain designs were constructed.

I’ve come across reviews where people thought all 3 were more style than substance. I have to admit that at times reading each part of me felt the same. However in the end I enjoyed and learned from all 3 books.

If it means anything I did buy all 3 and have read through each more than once.

Grid Systems
by Kimberly Elam

This book introduces some exercises and then shows student solutions to those exercises. The idea of each is to place different shapes (rectangles and circles) on the page in interesting ways.

Some shapes are representative of lines of blocks of text. Solutions with actual text instead of their representative shapes are also shown.

• Amazon
• Barnes & Noble

Geometry of Design
by Kimberly Elam

This book discusses different geometric and mathematical systems like the golden ratio, for building grids.

It shows how to construct the different grid systems it discusses and shows them in practice in works of art and architecture. The idea is to help understand how different geometrical systems provide an aesthetic beauty to the works they’re used in.

• Amazon
• Barnes & Noble

Typographic Systems
by Kimberly Elam

This last once focuses on type, but I listed it here, because it deals with systems for organizing type on the page as opposed to typographic anatomy. Also it’s similar in form to the two other Kimberly Elam books above.

It works through 8 different systems for placing type on the page, including radial, grid, and modular systems.

One last word about this and the 2 books above. If you learn well through seeing abstract visuals you’ll probably like all 3. Each is less long text explanations and more quick intros with the visuals serving as the explanations.

• Amazon
• Barnes & Noble

Making and Breaking the Grid
by Timothy Samara

This book looks at designs that both use a grid and those that break out of it. I often pull it off the shelf just to look at the designs for inspiration. There are some absolutely beautiful examples inside.

Each of the two sections begins with a short intro followed by many examples of designs along with some explanation about how the design fits into a grid or breaks out of it. Each example also shows which grid is being used in the design.

The two post below were both taken directly from this book.

• Anatomy of a Typographic Grid
• 4 Types of Grids And When Each Works Best

• Amazon
• Barnes & Noble

Basics Design: Grids
by Gavin Ambrose and Paul Harris

This book looks into different grid elements like baselines and columns as well as talking about different grid usage ideas. There are plenty of examples of grid based designs throughout.

I preferred Samara’s book to this one, but enjoyed both. The approach here is different than Making and Breaking the Grid. There are some different topics covered and it also has some great examples of grid based design.

• Amazon
• Barnes & Noble

Ordering Disorder: Grid Principles for Web Design
by Khoi Vinh

Khoi Vinh’s book is the only one int his section that’s entirely focused on web design. Khoi is one of the people responsible for bringing a focus on grids to the online world.

This is a must read if you want to work with grids online. It helped answer a number of questions about how to develop a grid I had after reading the books above.

Khoi takes you through a working example constructing a basic grid and then developing several of the typical pages you’d find on any website using that grid.

If you had to pick 2 books from this section I’d go with Making and Breaking the Grid and this one.

• Amazon
• Barnes & Noble

Summary

There are obviously a lot of books above (23 I hope) and you might be wondering which to read first. If I mentioned a book as a must read or a bible it’s probably one I would recommend first.

Otherwise visit Amazon or the Barnes & Noble site and read some reviews or walk into a store and begin reading.

The majority of the books above I discovered through recommendations by other web designers. A few I found searching Amazon and a few I found searching the shelves at Barnes & Noble.

I know some of these books are available as eBooks for iPad, Kindle, or Nook and they should offer free samples. I’d like to tell you that you’ll love all of them, but I know we all have different tastes in reading material.

I can tell you that these are all books on my many bookshelves and I’ve read each and every one, some several times, and I often grab them as references.

If you have any books to recommend about design please share. I’m always looking for new books to read.

Go to Source

All the credit here belongs to Ethan Marcotte and I recommend his post on flexible images. I also highly recommend Ethan’s new book on responsive design.

Also Richard Rutter has set up a page experimenting with flexible images using max-width that’s worth checking out.

How to Create Flexible Images

Typically when adding an image to a web page we set a width and height using absolute measurements like ‘px’. Unfortunately this fixes the image size and is completely inflexible.

At one specific point the absolutely fixed image is probably the perfect size. However in all other cases it will either be too large or too small for the layout. Let’s consider the case where the image is larger than its container.

We already know how to keep elements from growing too large and that’s through the max-width property

img {
	max-width: 100%
}

And with that one line of code we’ll prevent our images from ever being larger than their containers. And since we’ve set the measurement in % the image can resize itself as its container resizes.

If an image is larger than it’s container it will be scaled back to be the same size as the container. If the image is smaller than the container the image will be its default size.

Modern browsers are good at maintaining proportions so the image will resize well as the layout resizes. This works not only with images, but with video and other media. We can refine the above css to be:

img, embed, object, video {
	max-width: 100%
}

And we’re done. This is all seeming too easy isn’t it? Unfortunately we’re not there yet. The above doesn’t quite work everywhere.

Internet Explorer 6

First up is IE6, which probably isn’t any surprise. It may also not be much of a problem depending on your site. IE6 is finally falling out of use so it’s up to you whether or not it’s worth supporting.

IE6 doesn’t support max-width, but it treats the width property similar to max-width. The simple fix then is to use a conditional comment targeting IE6 and then set the width to 100%.

This will force all images to be the same size as the container. It works great if the image is larger than the container, but for images meant to be smaller like thumbnails and icons the images will scale up and usually not look too good.

We could go through the trouble of wrapping each of these smaller images inside its own container and set additional css on the containers, but that’s probably more work than it’s worth.

You can also apply a fix using Microsoft’s expression() property, though it usually takes some trial and error to get the values you need correct.

For my part I’ve stopped developing for IE6 unless specifically requested and paid for by a client. On this site IE6 use has dropped to less than &frac12;%

Windows

We’ve either taken care of IE6 or ignored it, but we’re still not done. Unfortunately Windows the platform doesn’t scale images as well as it could. Resized images can look pretty bad due to a bug in the operating system.

Fortunately while the issue is with the platform it only affects a few specific versions of browsers.

The browsers in question are Firefox 2, and IE 7 and below. The issue doesn’t affect other modern browsers. It also appears as though the bug has been fixed in IE7 so we’re actually down to IE6 and FF2 as browsers we need to find a workaround for.

The solution for IE6 (again should you choose to support it) is to use Microsoft’s AlphaImageLoader filter.

You may be familiar with AlphaImageLoader since it’s also used in a fix for transparent .pngs on IE. Since it’s Microsoft specific though it won’t work with FF2.

I’m willing to concede that we probably don’t need to support FF2 and as I said above I’ve stopped supporting IE6 as well.

Odds are you probably aren’t going to support either of them so instead of presenting details of the fix here I’ll once again point you to Ethan’s post on flexible images, which includes a javascript fix and a few more details about the issue and solution.

Background Images

We’re close, but still not all the way to having flexible images everywhere. If you’ve noticed we’ve been talking about images directly in your html so far. What about background images declared in your css?

Vertically Repeated Images

A couple of weeks ago I posted 4 methods for creating equal height columns in css and the first of those methods was faux columns. In that method we set a fixed width background image on a container div and repeated it vertically to mimic the background behind the individual columns.

While in that post we used a fixed width image, the method can be extended to be a little more flexible, if we’re willing to apply a little math.

Let’s use the image from the faux columns post (seen above) as an example. The image was 960px wide and transitioned at 340px from the left edge. First we’ll use the hopefully familiar formula we used to create elastic grids.

target &divide context = result

340px ÷ 960px = 35.4167%

Now we know where our transition point is located relative to the edge.

Next we’ll create a much larger background image than we’ll reasonably need and once again do the math in reverse to determine where we need to set that transition point.

Let’s create an image that’s 3000px wide.

target ÷ 3000px = 35.4167%

Doing the math our target becomes 1062.5 px. Since we need to use integer values in Photoshop we’ll round up to 1063 px.

Finally we’ll set the image using the css background-position property.

background: url("background-image.png") repeat-y 35.4167% 0;

Our image can now scale with our layout while our transition point will always remain where we want.

The above works for vertically repeating background images, but it’s not truly flexible in the sense that we’ve created a fixed width image, just one much larger than we think we’ll ever need.

We’ll be ok as long as the layout doesn’t get wider than the image, but that may not always be the case.

Horizontally Repeating Images

If you have a small image that you’re using as a repeating background there shouldn’t be any issue. The image will repeat to fill up its container regardless of size.

Assuming the image is small enough horizontally or represents something that only changes vertically (think gradient on a navigation bar), the worst case is being off a couple of px at the edge, which is unlikely to be noticed by most.

Background-Size

CSS3 has a property called background-size, which would be perfect, but at the moment it’s not supported well enough to use in practice.

Next week we’ll talk about media queries, which will let us set different images over a range of layout widths. In time the combination of media queries and background-size will be our solution, but sadly not today.

Hiding Images with Overflow

Much of the time max-width alone will be enough to keep your layouts flexible. At times though your images won’t scale well because of the content of the image or perhaps it’s not really necessary to always show the entire image.

If we set overflow: hidden on a container around an image then as the container is resized smaller than the image, part of the image will be hidden. The image won’t be flexible, but it will preserve the integrity of your layout and allow it to remain flexible.

Most of the time max-width will be the better option, but depending on the content in the image it may also be ok to hide it instead of resizing it.

Image Replacement

There’s one last method which involves replacing images that might be useful when your image is complex enough that scaling it doesn’t work well and where hiding part of the image isn’t an option.

The solution is to use multiple images and serve different sized images under different conditions.

This is a server side method and instead of presenting it incorrectly here I’ll direct you to a post by Bryan Rieger on mobile image replacement with the details and even better a download with all the code you need.

Next week we’ll dive into media queries which also allow you to serve different images based on device and screen width among other things.

Summary

Being able to create flexible images is an important consideration when trying to create a flexible layout. What good is a flexible layout if the content inside forces the layout to be rigid?

For most cases all we need to do is set a max-width of 100% on our images (and media) to make them flexible. You’ll need a couple of fixes for IE6 and one for FF2 should you decide you need to support those browsers.

With vertically repeating background images we’ll create much larger images than necessary and use a little math to understand where to set transition points on the background-position property.

At times we can apply an overflow: hidden fix that will preserve the flexibility of our layout even if they don’t make our images any more flexible.

In time we’ll have browser support for the css3 background-resize property, but for now max-width: 100% and overflow: hidden should cover most cases.

Even with all of the above methods we don’t have a way to create flexible images 100% of the time. We are able to cover most practical cases and perhaps rethink our use of images in those few cases we can’t yet cover.

Next week we’ll continue with a discussion of media queries before wrapping up with some thoughts about responsive design.

Go to Source

The above is a tweet from about 3 years ago that recently came to my attention via Luke Wroblewski. It’s hardly controversial, however, I think the quote above can be taken too literally.

I want to offer a few thoughts about what we really need to know about content in order to begin developing a design concept.

First let me state I absolutely agree with the meaning behind Jeffrey’s statement and I think he too would agree his words are sometimes taken too literally. He said as much in a comment on his blog.

“Content” doesn’t mean “having all the copy.

I’m sure when you’re about to start a project for a client you ask early on for the content. If your clients are like many of mine you won’t get all the copy prior to starting the design and you’ll need to get more information from them.

Is it really necessary?

What You Need to Know About Content

Design is communication. Naturally we need to know what we’re trying to communicate in order to be able to communicate it effectively.

This is key to design.

Ideally we’ll have real content to work with. I’ll always ask for it and hope to get it as soon as possible. Realistically it almost never happens.

When you design specifically around prewritten content you have art direction. You have different designs for each piece of content.

While you may be art directing the content on a site, most of the time we’re creating a single design or several similar designs for different sections of the site.

Think about how you would design a blog. You can’t possibly have all the content in advance, because most of it won’t even be an idea as you’re designing. The very nature of a blog suggests the design has to come before most of the copy.

You can know in advance that future blogs posts will mostly be text heavy or that they’ll feature images or other media in some way. You should also know what the topic of the blog is.

Your design can know much about what that content will be long before the content is created. You may not be able to design a post specifically around its content, but you’ll have enough information to come up with a design for the blog as a whole.

We don’t need all the copy in advance. What we need to know is information about what that copy will be. We need to know things like:

• What is the site is about?
• What will the content be about?
• What type of content will be present (text, images, video, audio, etc)?
• Who is the audience for the content?
• Will the content be short, medium, or long form?
• How will people find the content?

What we need isn’t so much the exact copy as it is knowing the subject of the copy and associated information. We need a strong understanding of the nature of the content, but not the content itself.

The more information you have about the content prior to design, the more likely the design can turn out well, but again you don’t need to have the exact copy in order to design.

Not having all the copy doesn’t mean you know nothing about the content.

Planning Content

Knowing that we need some information about content, we need to at the very least set a plan for what the content will be. What should we plan for before design in order to be able to design effectively?

Ideally we’ll have a content strategy in place to define the purpose of the content and set out what the message we’re trying to communicate will be.

We want to plan for topics and ideas and how the content will relate to achieving site and business goals, marketing, and search engine optimization.

We want our content strategy to answer questions like:

• What content should be created
• Why create this content
• Who is the best person to create this content
• Where will this content be put to best use
• When should this content be published
• How will this content be created, text, image, video, etc.

Before designing we need to develop the information architecture for the site in order to design site navigation, help search engines find the content and help them understand it too.

When I’m entrusted with developing a content plan my process for content creation is to research the industry, brainstorm ideas, organize the potential pages, prune those pages, and revise by iterating the entire process again.

I’ve written in more detail about most of the above and have linked to those details throughout this post. The important thing to understand here is that planning content prior to design is not only important, but a requirement for effective design.

Do we need all the copy prewritten? No, but we do need to know as much as possible about what that copy will eventually be.

Summary

I realize I’m not saying anything new or profound here. This post is more a reminder that while you don’t need to have every bit of copy in order to create a design, you do need to have a lot of questions answered about the what the content will be.

It’s also a reminder that while most clients won’t ever deliver all the copy prior to you beginning the design that’s ok. You don’t need it.

Design in the absence of copy can still be design. Design in the absence of any knowledge of content is certainly decoration. Seldom though, do we have absolutely no knowledge about content.

We may not have all the details, but we almost always have some information about what the content will be, usually enough to develop a concept for the design, plan the site architecture, etc.

Do you insist on all the copy prior to designing? What information do you require at a minimum?

Go to Source

We previously talked about fluid layouts, which I defined as using measurements relative to the browser window. Moving from a fluid layout to an elastic layout is actually quite simple. In fact we only need to make one change to the css we previously used to make the layout change.

Before getting to the code let me say the definitions above aren’t necessarily used by all. When people talk about fluid layouts they sometimes mean any flexible layout. I’m defining things as:

• Flexible layout — any layout that uses relative measurements to allow the layout to resize under different conditions
• Fluid layouts — layouts with measurements relative to the browser window
• Elastic layouts — layouts with measurements relative to something internal to the design such as the size of the type

Both fluid and elastic layouts are flexible. Again not everyone would define these layouts this way. All three terms are often used to describe any layout that resizes itself.

As always if you prefer to skip the explanations below and jump right to the code you can view the demo layouts here.

The HTML

If you’ve been following along with this series of posts on creating css layouts this html should be old hat by now.

<div id="container">
	<div id="header">
		<p>Header</p>
	</div>
	<div id="content">
		<p>Main content</p>
	</div>
	<div id="sidebar">
		<p>Sidebar</p>
	</div>
	<div id="footer">
		<p>Footer</p>
	</div>
</div>

The only difference between what’s here and what we previously saw with the fluid layouts is the addition of the container div.

You can alternately use the body tag as the container. I’m using a dedicated container div as it’s been my practice and I’m unaware of any real advantages in using one method over the other.

The CSS

Most of this css should also be familiar by now. In fact part of the reason for this series of posts has been to let you see how similar and simple the code is for these different types of layouts.

In many ways this is the beauty of css. A few small changes in the code can have a significant impact on how the html structure is presented.

body {font-size: 1em}
#container {max-width: 75em; margin: 0 auto;}
#content {
	float:left;
	width:67%;
}
#sidebar {
	float:left;
	width:33%;
}
#footer {
	clear:both;
}

The only real difference here as compared to our fluid layouts is that we set the width of #container. Remember in the fluid layouts we used the body as the container.

In the fluid layouts we allowed the width of the body to be 100% of the browser width. Here I’ve set the max-width of #container to be 75em.

We’ve given the body a font-size of 1em, which will default to 16px in most browsers, so 75em is equal to 16 x 75 or 1200px.

I’m using max-width as opposed to width since it’s more flexible. This allows the layout to resize when the browser is open less than 1200px wide. Had we used width instead we’d see a horizontal scroll bar when the browser is open less then 1200px.

Everything else is the same as when we developed a fluid layout however that one small change to the width of the container changes what we’re measuring against.

If we continue deeper into the layout the width of the content is 67%. That 67% is measured against it’s parent, which is #container. #container is relative to the font-size and so #content is relative to the font-size too. Similar for #sidebar.

Elastic Grids

A couple of years ago Ethan Marcotte wrote an article for A List Apart on Fluid Grids. What Ethan referred to as fluid I’m calling elastic. I think Ethan now uses the more generic flexible grids.

Without getting into developing grids here, the basic idea for making grids elastic is to switch from using absolute measurements to using relative measurements like we’ve done above.

When setting up different grids it’s usually easier to think in terms of absolute measurements. Ethan offered a simple formula for then converting those measurements into relative ones to create the flexible grid.

target ÷ context = result

This is what we did above when we set the max-width on the container. Our result was 75em. Out target was 1200px. Our context was the 1em (or 16px) we set for the font-size of the body.

1200 (target) ÷ 16 (context) = 75 (result)

When we set widths on the content and sidebar divs our results are 67% and 33% respectively. While I didn’t show it here the targets were maximum widths of 800px and 400px.

800 ÷ 1200 × 100% = 67%

400 ÷ 1200 × 100% = 33%

The context for both was the width of the container div. When we set widths in % they’re relative to the width of the parent element.

Sounds relatively simple (no pun intended), but there’s a potential gotcha waiting.

If we specify any width in ‘em’ then the context is the font-size of that element. Above we specified #container in ‘em’ but since the font-size of the container is the same as the font-size of the body (its parent) there wasn’t a problem.

Had we changed the font-size of container to be 1.25 em (20px) then 75em would translate to a new measurement.

20 × 75 = 1500 = 16 × 75 × 1.25

You can play with the code and test this by changing the font-size on different divs to see what happens.

In the cases of #content and #sidebar where we set the width in % changing the font-size on either div won’t change anything (other than the font-size).

The context will still be the width of the parent as we’re using % for the measurement. For this reason I think it makes more sense to define your widths using %. Save ‘em’ for font-sizes, line-heights, and anything else vertical.

Again you can test this and see what happens.

As long as you remain aware of any changes in your context this shouldn’t cause any problems. However if you find your layout not looking right, this context change is probably a good place to start investigating why.

Summary

Developing flexible layouts with relative measurements should be a goal for web design as the format in which our designs live (the browser) will always be flexible.

Those measurements can be relative to the browser, which I’ve defined as fluid layouts or relative to something internal to the design, which I’ve defined as elastic layouts.

The names aren’t specifically important, but the concept is. It makes more sense to use measurements relative to something internal in the design.

It’s quite simple to move from a fluid layout to an elastic one. All it takes is changing the measurement of the outermost container from % to ‘em.’ Everything inside that container will then be relative to the design instead of the browser window. Inner containers can continue to be measured in %.

Taking it further and creating elastic grids we’ll use these same measurements. With some not too difficult math we can create grids that resize themselves as the text resizes.

If we also use max-widths in places instead of widths we have a layout that can resize itself as the browser resizes.

We’re almost done with this series of posts on css layouts. Next week we’ll consider flexible images and the following week we’ll look at media queries while we build toward a discussion of responsive layouts.

Go to Source

Good artists borrow great artists steal
— Pablo Picasso

I’m sure you’ve seen the above quote before. What does it really mean? Is it an ok from one of the world’s great artists to literally steal from others? Is it an excuse to ignore copyright? No and no. It’s a much deeper statement about the creative process.

Steal Like an Artist

What does it mean to steal like an artist? What was Picasso trying to say?

When you borrow something you plan on giving it back. At least you’re supposed to. When you steal something you make it your own. It’s the making it your own that Picasso was suggesting.

Great artists stealing doesn’t mean they copy the work of others and pass it off as their own. It means they so absorb the work and ideas of others that they can recombine everything with their own work and thoughts to create something truly theirs.

It’s a similar idea to the Medici effect, the idea of finding intersections at the crossroads of ideas in different disciplines and combining what you find into something new or unique to your discipline.

To make ideas your own you need to take them apart to understand how they were put together and why they were put together in a certain way. You have to assimilate and internalize those ideas so they mix with your own.

A few years ago I published a post about developing your voice as a blogger and suggested that your voice is what comes out after everything you take in is filtered through your thoughts and experiences.

Your voice as a writer, an artist, or a designer is the end product of this artistic theft Picasso talks about.

Your voice comes from filtering things through the sum of all your thoughts and experience. When you steal from other artists you do two things.

• Provide new source material to run through your filter
• Modify your filter for future source material

Vincent Van Gogh often referred to himself as a link in a chain. He saw his work as building on the work of those who came before him and leaving something behind for those who came after to build on top of.

In essence he stole from past masters, internalized what he took, reformed it as something of his own, and left it for others to then steal and continue the process.

How You Can Steal And Grow as a Designer

Assuming you’re on board with the idea of stealing as Picasso meant it here are a few ideas for how you can learn to steal better in order to grow as a designer.

• Collect ideas, inspiration, and techniques
• Set a path for your growth and see and collect everything along that path
• Seek quality over quantity
• Read, read, and read some more
• Look deeper at things. Take the time to understand how and why things work
• Live in the crossroads. Increase the probability of the Medici effect

Collect

Again the stealing part is about taking things in so your first step to steal and grow as a designer is to collect.

As Austin Kleon points out it’s not about collecting indiscriminately, but rather selectively. Much of what’s below is how to collect selectively.

Set a Path

Have you ever noticed once you become interested in some topic that you start noticing information about that topic wherever you go. I know when I start studying something like typography it seems like every magazine or blog post is about typefaces and line-height, and measure.

It’s not some mystical thing at work. It’s simply that you’re more attentive to the things you’re interested in.

It’s important to set the path for your collections. What finds its way into your consciousness is what you develop an interest in. Put a little thought into how you want to grow as a designer. Set a direction for yourself. You’ll discover yourself finding more things on that path to collect.

Seek Quality

You’re only going to be as good as the ideas and techniques you collect. Garbage in, garbage out. If you want to produce the best work you need to take in the best ideas.

What we collect and take in becomes the source material for what we create. The better the source material, the better the resulting end product.

Read, Read, Read

One of the best ways to collect ideas is to read the ideas of others. Again read selectively. Read those things you’re interested in and seek quality over quantity. Read the theory behind design to understand why different design principles work.

Look Deeper

When I first started learning to build websites I would stop whenever I found a site I liked and start pouring over the code. I’d look at how the html was structured and how the css presented that html. I’d ask myself why the designer had chosen to do things that way and think if there was a better way to accomplish the same thing.

When I didn’t have time to study the code at that moment, I’d bookmark the site and come back later to study it.

That’s still one of the best way to learn how to develop websites. Think of your favorite sites as your mentors. They’re all willing to tell you exactly how to develop a site of your own. Study their designs. Ask yourself why one design element is red or why another is off to the corner.

When you come across sites giving away snippets of code don’t just copy the snippet and paste it into your site. When you copy code like that you borrow it. You don’t make that code your own. You won’t understand how to apply that code to a different problem or how to fix it when it doesn’t work. You won’t own the code. It will own you.

Read the tutorial explaining how the code works or better yet study it on your own. You can certainly use the code without doing either, but again you won’t own it that way. You’ll be borrowing it.

Always look deeper than what’s on the surface in everything. You borrow the surface. When you dig deeper you steal what you unearth.

Live in the Crossroads

Don’t limit yourself to collecting from the world of design. Look beyond design for inspiration and ideas. Collect things from other disciplines and think how they might be applied to a design problem.

Be receptive to The Medici Effect (PDF)

Learn how other industries solve problems. Ask yourself if those solutions will work for some design problems you come across. Be open to taking in ideas that seem unrelated on the surface. Those ideas will modify your filter in unique and interesting ways.

Write more to be a better designer and design more to be a better writer. Learn a wider variety of things to see the commonalities between them.

Summary

Good artists borrow. They copy the techniques of others, but they never make those techniques their own. They never learn to apply them in ways beyond how they were originally presented.

Great artists steal. They internalize the ideas and techniques of others, mix them with everything else they have inside, and release them in new and interesting ways. By stealing they make those ideas and techniques their own.

Stealing in the sense Picasso meant isn’t about ripping off your fellow designers. It’s about learning what you can from them and filtering their ideas through yourself in order to build something new.

Be a link in the chain of design. Build on the ideas of others and leave behind something of yourself for other designers to build on.

In this way we all become better and we all push design further.

Go to Source

We generally don’t mean that we want the content inside each column to be of equal height. If that were the case there really isn’t a problem as the height of the columns will naturally be the same height.

What we really mean by equal height columns is having the columns look as though they’re of equal height when the content inside isn’t.

We can achieve that by making the css backgrounds behind the column appear to be of equal height. Ultimately we’re faking equal heights.

For those of you wanting to get directly to the demos and code you can click any of the images above the sections below and be taken to the appropriate demo.

Faux Columns

Faux columns have been around a long time. 2004 to be exact. For that same long time they were and maybe still are the deFacto method for creating columns of equal height.

It’s a simple trick using a background image that’s repeated vertically. An example of this repeating image is seen below. I’ve increase the height so you can see it.

The image is usually created as a single px in height and it’s width will match the width of your layout. Where one column becomes another in the layout, the faux column image will change as well.

The html

For this example we’ll use html that’s similar to what we’ve been working with the last few weeks, though I’ll skip the header and footer to focus on the columns.

<div id="container">
	<div id="sidebar">
		<p>Sidebar</p>
	</div>
	<div id="content">
		<p>Main content</p>
	</div>
</div>

You could use the body as the container, but I’m choosing to use a container div so you can see that this technique can work for setting up columns inside a part of your overall layout in addition to the overall layout itself.

The css

#container {
	width:960px;
	margin:0 auto;
	background: url("faux-columns.png") repeat-y;
	overflow: hidden
}
#sidebar {
	float:left;
	width:340px;
}
#content {
	float:left;
	width:620px;
}

The css here is pretty simple. Floating and setting widths on #sidebar and #content should be familiar to you by now as well as setting the width and margin on #container.

What’s new here is setting the faux-column background image on the container and using overflow: hidden on the container.

We need to set the overflow property to ensure the container div doesn’t collapse. Because everything inside is floated we need to force it back open.

The container will then always be the same height as the longer of the 2 columns and the background image will make it appear as though the shorter column is also the same height.

This method works best for fixed width layouts though it can work with more fluid layouts as well.

You also aren’t limited to a simple color change in backgrounds. Borders, shadows, patterns, etc. can be added by adding them in the appropriate place on the faux-column image.

For patterns you might choose to create an image more than 1px in height.

Pros:

• Easy to set up
• Work regardless of which column is the longer or shorter

Cons:

• Requires an image, which requires an additional http request
• Any change to the layout requires the image be reworked
• Need to know what your layout will look like in advance to create the image

Pseudo Columns

I’ve never cared for faux columns. Not because it’s a bad method, but because I have a thing about never using an image for a solid background color.

Because of that I developed my own method for achieving equal height columns, which for lack of a better term I’ll call pseudo columns.

It works similarly to faux columns as it involves setting a background on the container. It’s not a general approach to equal height columns and has a very limited use case, but when you encounter that use case it works well and easily.

The html

We’ll use the same html as the faux column method above.

<div id="container">
	<div id="sidebar">
		<p>Sidebar</p>
	</div>
	<div id="content">
		<p>Main content</p>
	</div>
</div>

Once again no header and footer so we can focus on the columns.

The css

The css is again quite simple. I’ve gone with a fluid layout here for variety, but you could just as easily set this up to be fixed width.

#container {
	background: #555;
	overflow: hidden
}
#content {
	float:left;
	width:75%;
	background:#eee;
}
#sidebar {
	float:left;
	width:25%;
	background:#555;
}

Other than using % instead of px, you’ll notice that here I’ve set the background colors on #content and #sidebar. You’ll only need to set it on whichever column will be longer, but here I’ve set it on both.

The main change from faux columns is instead of a background image we set a background color. It’s the same principle in that we’re allowing the background of the container to show through beneath the shorter columns.

The limitation is we need to know which column will be shorter in advance and ideally that same column would be shorter on every page of the site.

That sounds like a pretty big limitation, but I find in practice one of the two columns is usually shorter across most, if not all, pages and for those pages where it might not be the case, it’s easy enough to add a little more or less content to make it so.

Pros:

• Easy to set up
• Easy to maintain

Cons:

• Harder to implement on more than 2 or 3 columns
• Requires you know the relative heights of columns in advance
• Doesn’t work as well when different columns are longer or shorter on different pages

This method is far from perfect, but you might be surprised how often it can be applied in practice.

Borders and Negative Margins

This is a method I came across not too long ago on a Smashing Magazine article by Thierry Koblentz, though I later found an article by Alan Pearce on A List Apart written a few years ago detailing the same method.

It uses borders and negative margins to give the appearance of the equal height columns.

The html

Nothing new in the html here compared to what we’ve seen above. In his article Thierry uses the body as the container, but I’ll stick to using a container div as is my usual practice.

<div id="container">
	<div id="sidebar">
		<p>Sidebar</p>
	</div>
	<div id="content">
		<p>Main content</p>
	</div>
</div>

The css

The css is where things get interesting. The container is just being used to fix the width and center the layout. The interesting stuff happens on #content and #sidebar.

#container {
	width:960px;
	margin: 0 auto;
}
#content {
	float:left;
	width:700px;
	border-left: 260px solid #555;
}
#sidebar {
	float: left;
	width:260px;
	margin-right: -260px;
	position: relative;
}

All the background colors in this method are set on the #content column. We set it’s background as normal and then give it a left border equal to the width of the sidebar. We also set the border color to what we want the sidebar background to be.

If we stop here you’ll see both columns displayed where you want, however our border-left has pushed the actual sidebar off the page and we need to bring it back.

First we give the sidebar a negative right margin equal to its width (or the width of the left border of the content, which are the same). That will bring the sidebar back to where we want, but it still isn’t visible.

The problem is in the stacking order of the 2 divs. #container is sitting on top of #sidebar so we need to move #sidebar to the front. We do that by adding position: relative to the sidebar and now it’s content is visible.

Pros:

• Works regardless of which columns is longer or shorter
• Easy to set up once you understand how it works
• Easy to maintain

Cons:

• Sidebar width needs to be fixed as border-width only accepts absolute measurements
• Negative margins can potentially trip up some older versions of IE

I’d encourage you to read both articles I linked to above as they offer more details than I am here. Both contain code for using this method with a third column and Thierry’s article talks about setting up borders between the columns.

Offset Columns and Containers

This last method is one created by Matthew James Taylor. Of all the methods presented here this one will work under the most use cases.

I’ve saved it for the end since it’s a little more complex and you might need to read through it a few times to understand how it works.

The html

The html is similar to what we’ve seen above though you’ll note an extra container div to what we’ve seen before.

<div id="container-outer">
	<div id="container-inner">
		<div id="sidebar">
			<p>Sidebar</p>
		</div>
		<div id="content">
			<p>Main content</p>
		</div>
	</div>
</div>

As with the other methods we’ll use these containers to set background colors that will appear as though they belong to our columns.

The css

There’s a lot more going on here than what we’ve seen to this point. Both #sidebar and #content are floated left and given a width, but beyond that just about everything else is new.

The key to this method is the idea that a floated container will always be the same height as its floated content. By floating all of our columns inside all of the floated containers we ensure our container divs will always be equal in height to the tallest column.

#container-outer {
	float:left;
	overflow: hidden;
	background: #eee;
}
#container-inner {
	float:left;
	background: #555;
	position: relative;
	right:75%;
}
#sidebar {
	float: left;
	width: 25%;
	position: relative;
	left: 75%;
}
#content {
	float: left;
	width: 75%;
	position: relative;
	left: 75%
}

The first step here is to float both the columns and the containers. I have everything floated to the left, but the direction isn’t important. Use whatever direction you need for your layout.

The next step is setting backgrounds on the 2 container divs. Here I’ve set the background on the inner container to be the one we want on the sidebar and the outer container background to what we want on the main content.

If we stop here we’ll only see the background on the inner div since it’s higher in the stacking order than the outer div.

We need to a little css positioning to shift the inner div so it shows only where we want the sidebar to display. That will allow the background on the outer div to show through behind where we want the content column to display.

#container-inner {
	position: relative;
	right: 75%;
}

We position the inner column and then set it’s right value to be 75% which is the same as the width of our content column.

Our backgrounds are now in place, however the content of both columns has also shifted 75% to the left. We need to shift it back into place.

#sidebar {
    position: relative;
    left:75%
}
#content {
    position: relative;
    left:75%
}

Once again we use relative positioning and because the content in both columns has been shifted 75% to the left we need to shift it back 75% to the right. We do that by setting the left value to 75%.

Now everything is back where it should be.

Pros:

• Works regardless of which column is longer or shorter
• Works with any kind of layout (fixed, fluid, elastic, etc)
• Can handle as many columns as you want

Cons:

• A little more difficult to understand at first
• Requires additional and non-semantic container divs

Overall this is the most foolproof method and the one guaranteed to work for any use case. I’d encourage you to play around with this one to really understand it and read through Matthew’s article a few times.

Matthew’s article walks through a 3 column layout and he has demos for both 4 and 5 columns as well. I chose to present a 2 column layout in the hopes it would make the concepts easier to understand.

Additional Resources

By no means are these the only methods for creating equal height columns. Chris Coyier shared a several other methods on CSS Tricks a few months back that you may prefer over those presented here.

• Fluid Width Equal Height Columns

There are also plenty of other methods you can find with a little searching. Between this article and Chris’ I think most of the more common methods are covered.

Summary

Equal height columns are a desirable design trait, but they haven’t always been easy to create with css layouts. Ideally we’d be able to use something like height: 100% and be done with it, but for now we can use any of the methods mentioned above.

Faux columns are easy to set up, but they require an extra http request for the image and any change to the layout requires a new image.

Pseudo columns are even easier, but have a limited use case where the relative heights of both columns are known and consistent across pages.

Borders and negative margins are relatively easy to work with, require no foreknowledge of column heights and better adapt to multiple columns. They require one column be fixed width.

Offset columns and containers work across the most cases. They require no foreknowledge of column heights and can work with as many columns as you want. The method is a little more complex than the other methods.

In time I expect a much simpler standard css solution, but until then these 4 methods should suffice for your project.

Do you design equal height css column layouts often? What method for creating the columns to use when you do?

Go to Source

• Manuscript grid
• Column grid
• Modular grid
• Hierarchical grid

Ideally by the end of this post you’ll have a better idea why you might choose one type of grid over another for a particular project.

I’ll be referring to various grid parts throughout so if those parts are unfamiliar you may want to visit the anatomy of a grid post.

Manuscript Grid

Sometimes called a block grid or single column grid, the manuscript grid is the simplest grid structure. It’s mainly a large rectangular area taking up most of the space inside a format.

The primary structure is defined by large text blocks and margins, which position the block within the format. Its secondary structure defines the location and proportions of folios, footnotes, running headers, and other secondary information.

Manuscript girds are good for extensive and continuous blocks of text. They’re used in books and long essays and perhaps lend themselves well to blog posts. They aren’t limited to text though. Images can be used to fill the block.

By adjusting the margins designers can help create interest. More opportunity for this exists where two page spreads are used as in magazines or books, but even on a single page interest can be created through margins alone.

• Wider margins — lead to narrower text blocks, which helps focus the eye on the text and creates a sense of calm and stability.
• Narrower margins — force the text block to the edge of the format creating tension as the two near each other.

Asymmetrically placed text blocks add visual interest and leave a larger block of whitespace on one side to allow the eye to rest.

Because of the simplicity of manuscript grids, typography plays an important role in creating visual interest. Your choice of typeface, font-size, leading, measure, hierarchy, etc will make up most of your design choices.

Given the name we naturally associate manuscript grids with the printed page, however if you think of any fixed width layout it’s essentially one large block located within a format (the browser window).

Designers typically center these layouts, but with the above ideas in mind perhaps there are better places to locate your layout.

Column Grids

When people think of grids, especially online, they likely think of column grids. As you would expect column grids are made up by placing multiple columns within the format.

Column grids are good when discontinuous information needs to be presented.

For example you might have various asides, pull quotes, etc in your design, which can occupy different columns in the grid. One column might be reserved for text, another for images, and yet another for image captions.

Columns can be dependent on each other, independent from each other, and crossed over by design elements. This leads to a large amount of flexibility when organizing information on the page.

You can separate blocks of information by placing them in different columns and yet still show a connection between them. Perhaps text in one column and images and captions in different column next to the text the image relates to.

The width of a column should depend on some element internal to the design, most likely the size of the text.

A column should be able to accommodate a comfortable measure for reading and avoid excessive hyphenation at the end of lines. Too wide or narrow a column and reading becomes difficult.

Column Gutters

When the margins are wider than the gutters between columns the eye is guided inward and tension is eased. When margins are narrower than gutters the eye is directed outward and more tension is present.

There are no hard rules, but traditionally if the size of the gutter is x the margin is usually set to be 2x.

Flowlines can be used in column grids to help set the subordinate structure or to allow for unusual breaks in text and images. Hanglines and baselines can help establish where different elements will be positioned vertically within the columns.

Modular Grids

Modular grids are like column girds with the addition of horizontal divisions marked by rows. The columns and rows and the gutters between each create a matrix of cells or modules.

Modular grids are good for complex projects that require more control than a column grid can offer. Image galleries and shopping carts are likely candidates for modular grids.

Modular girds lend themselves to the design of tabular information such as charts, forms, navigation, schedules, and of course tables of data. They can help standardize the space in tables and help integrate tables with any surrounding text or images.

Each module in the grid can define a small chunk of information or adjacent modules can be combined to form fields or spatial zones each designated to hold a specific type of information.

Smaller modules allow for a more flexible grid with greater precision, but they can become confusing to work with. Imagine for example setting up a modular grid in which each modules is 1px by 1px. Lot’s of flexibility, but not much practical use.

Modules can be either horizontal or vertical and the proportion of a module can be determined in a variety of ways.

• Average width and height of a paragraph
• Average image size
• Ad unit size
• Type proportions like leading and measure

Margin proportions will ideally be considered at the same time as module and gutter proportions as each relates to and affects the others.

Large publishing systems that present information across a variety of formats often use modular grids to keep design proportions consistent. This can help a company maintain brand consistency.

Aside from their practical uses, modular grids have developed an aesthetic image.

Between 1950 and 1980 they became associated with an ideal social and political order that has its roots in rationalism. The Bauhaus and Swiss style celebrate objectivity, order, and minimalism and turned to modular grids to maintain clarity in form.

This order and clarity can be used to create additional meaning. For example it often conveys a technical or urban feeling and naturally communicates mathematical information.

Hierarchical Grids

Hierarchical grids are commonly found on the web. They’re based more on an intuitive placement of elements, which still conforms to the needs of the information.

Customized proportions are typically used in hierarchical grids instead of regularly repeated intervals. Column widths tend to vary as do the location of flowlines.

They can be thought of as loose organic grids. Development often begins by spontaneously placing design elements. Later a rational structure to coordinate those elements is determined.

Hierarchical grids are good when a project requires an odd grid that doesn’t easily fit one of the other grid types and can be used to unify disparate elements and create a superstructure for organizing them.

If you’ve designed sites where you carefully align elements to each other without using one of the previous 3 grid types, you’re probably approaching a hierarchical grid structure in your design.

Summary

The 4 grids above are the main types of grids you’ll encounter. Each has a different function as far as holding content and choosing the right grid to use should come down to the content for your specific project.

• Manuscript grids — are the simplest and they work well when presenting large continuous blocks of text or images.
• Column grids — work well when the information being presented is discontinuous and different types of information can be placed in different columns.
• Modular grids — work best for more complex problems where columns alone don’t offer enough flexibility. The introduce horizontal spaces between blocks of content.
• Hierarchical girds — can be used when none of the above grids will work to solve the problem. They tend to be created organically by first placing design elements on the page and then finding a rational structure for presenting those elements.

Hopefully everything above has helped you see that grids come in different varieties and more importantly when you might choose one grid type over another. Each can be the appropriate choice for a website as each allows for variety within the grid.

If you currently work with grids which type of grid to you use most frequently?

Go to Source

• Manuscript grid
• Column grid
• Modular grid
• Hierarchical grid

Ideally by the end of this post you’ll have a better idea why you might choose one type of grid over another for a particular project.

I’ll be referring to various grid parts throughout so if those parts are unfamiliar you may want to visit the anatomy of a grid post.

Manuscript Grid

Sometimes called a block grid or single column grid, the manuscript grid is the simplest grid structure. It’s mainly a large rectangular area taking up most of the space inside a format.

The primary structure is defined by large text blocks and margins, which position the block within the format. Its secondary structure defines the location and proportions of folios, footnotes, running headers, and other secondary information.

Manuscript girds are good for extensive and continuous blocks of text. They’re used in books and long essays and perhaps lend themselves well to blog posts. They aren’t limited to text though. Images can be used to fill the block.

By adjusting the margins designers can help create interest. More opportunity for this exists where two page spreads are used as in magazines or books, but even on a single page interest can be created through margins alone.

• Wider margins — lead to narrower text blocks, which helps focus the eye on the text and creates a sense of calm and stability.
• Narrower margins — force the text block to the edge of the format creating tension as the two near each other.

Asymmetrically placed text blocks add visual interest and leave a larger block of whitespace on one side to allow the eye to rest.

Because of the simplicity of manuscript grids, typography plays an important role in creating visual interest. Your choice of typeface, font-size, leading, measure, hierarchy, etc will make up most of your design choices.

Given the name we naturally associate manuscript grids with the printed page, however if you think of any fixed width layout it’s essentially one large block located within a format (the browser window).

Designers typically center these layouts, but with the above ideas in mind perhaps there are better places to locate your layout.

Column Grids

When people think of grids, especially online, they likely think of column grids. As you would expect column grids are made up by placing multiple columns within the format.

Column grids are good when discontinuous information needs to be presented.

For example you might have various asides, pull quotes, etc in your design, which can occupy different columns in the grid. One column might be reserved for text, another for images, and yet another for image captions.

Columns can be dependent on each other, independent from each other, and crossed over by design elements. This leads to a large amount of flexibility when organizing information on the page.

You can separate blocks of information by placing them in different columns and yet still show a connection between them. Perhaps text in one column and images and captions in different column next to the text the image relates to.

The width of a column should depend on some element internal to the design, most likely the size of the text.

A column should be able to accommodate a comfortable measure for reading and avoid excessive hyphenation at the end of lines. Too wide or narrow a column and reading becomes difficult.

Column Gutters

When the margins are wider than the gutters between columns the eye is guided inward and tension is eased. When margins are narrower than gutters the eye is directed outward and more tension is present.

There are no hard rules, but traditionally if the size of the gutter is x the margin is usually set to be 2x.

Flowlines can be used in column grids to help set the subordinate structure or to allow for unusual breaks in text and images. Hanglines and baselines can help establish where different elements will be positioned vertically within the columns.

Modular Grids

Modular grids are like column girds with the addition of horizontal divisions marked by rows. The columns and rows and the gutters between each create a matrix of cells or modules.

Modular grids are good for complex projects that require more control than a column grid can offer. Image galleries and shopping carts are likely candidates for modular grids.

Modular girds lend themselves to the design of tabular information such as charts, forms, navigation, schedules, and of course tables of data. They can help standardize the space in tables and help integrate tables with any surrounding text or images.

Each module in the grid can define a small chunk of information or adjacent modules can be combined to form fields or spatial zones each designated to hold a specific type of information.

Smaller modules allow for a more flexible grid with greater precision, but they can become confusing to work with. Imagine for example setting up a modular grid in which each modules is 1px by 1px. Lot’s of flexibility, but not much practical use.

Modules can be either horizontal or vertical and the proportion of a module can be determined in a variety of ways.

• Average width and height of a paragraph
• Average image size
• Ad unit size
• Type proportions like leading and measure

Margin proportions will ideally be considered at the same time as module and gutter proportions as each relates to and affects the others.

Large publishing systems that present information across a variety of formats often use modular grids to keep design proportions consistent. This can help a company maintain brand consistency.

Aside from their practical uses, modular grids have developed an aesthetic image.

Between 1950 and 1980 they became associated with an ideal social and political order that has its roots in rationalism. The Bauhaus and Swiss style celebrate objectivity, order, and minimalism and turned to modular grids to maintain clarity in form.

This order and clarity can be used to create additional meaning. For example it often conveys a technical or urban feeling and naturally communicates mathematical information.

Hierarchical Grids

Hierarchical grids are commonly found on the web. They’re based more on an intuitive placement of elements, which still conforms to the needs of the information.

Customized proportions are typically used in hierarchical grids instead of regularly repeated intervals. Column widths tend to vary as do the location of flowlines.

They can be thought of as loose organic grids. Development often begins by spontaneously placing design elements. Later a rational structure to coordinate those elements is determined.

Hierarchical grids are good when a project requires an odd grid that doesn’t easily fit one of the other grid types and can be used to unify disparate elements and create a superstructure for organizing them.

If you’ve designed sites where you carefully align elements to each other without using one of the previous 3 grid types, you’re probably approaching a hierarchical grid structure in your design.

Summary

The 4 grids above are the main types of grids you’ll encounter. Each has a different function as far as holding content and choosing the right grid to use should come down to the content for your specific project.

• Manuscript grids — are the simplest and they work well when presenting large continuous blocks of text or images.
• Column grids — work well when the information being presented is discontinuous and different types of information can be placed in different columns.
• Modular grids — work best for more complex problems where columns alone don’t offer enough flexibility. The introduce horizontal spaces between blocks of content.
• Hierarchical girds — can be used when none of the above grids will work to solve the problem. They tend to be created organically by first placing design elements on the page and then finding a rational structure for presenting those elements.

Hopefully everything above has helped you see that grids come in different varieties and more importantly when you might choose one grid type over another. Each can be the appropriate choice for a website as each allows for variety within the grid.

If you currently work with grids which type of grid to you use most frequently?

Go to Source

These aren’t the only 2 hybrid layouts, but hopefully they point the way toward techniques you can use to create your own hybrid layouts.

As always if you simply want the code here are the demos

• Fixed content and fluid background
• 2 column fluid layout with max-width
• 3 column fluid layout with max-width

Fixed Width Content, Fluid Background

The trick to this layout is to use container divs around each row of content within our layout.

This allows us to use the inner div for fixing the width and centering what’s within while allowing the the outer div to stretch from edge to edge in the browser.

By setting backgrounds on the outer div we give the appearance that the layout is fluid, while we maintain control over the content itself. In a sense we create a layout within the layout. This inner layout is fixed, while the outer layout is fluid.

The HTML

The html below is similar to the fixed width layouts we’ve previously discussed.

<div id="header-container">
	<div id="header">
		<p>Header content here</p>
	</div>
</div>
<div id="page">
	<div id="content">
		<p>Main content</p>
	</div>
	<div id="sidebar">
		<p>Sidebar</p>
	</div>
</div>
<div id="footer-container">
	<div id="footer">
		<p>Footer: </p>
	<div>
</div>

The difference is that in the fixed-width layouts we wrapped everything with a single container div. Here we’re wrapping each row of content with a container.

Both header and footer are wrapped with a container div and since the content and sidebar are meant to be displayed next to each other (on a single row in the layout) a single container is used around both.

You might note that while #header and #footer are inner divs, #page is apparently an outer div. We’ll actually use the body as the outer div for #page instead of adding an additional #page-container div.

These multiple container divs are the key to this layout.

The CSS

If you’ve been following along with this series of posts on css layouts most of this css should also be familiar, though there are some new things which we’ll talk about below.

#header-container, #footer-container {background: #777;}
#page, #header, #footer {
	width:960px;
	margin:0 auto;
}
#content {
	float:left;
	width:620px;
}
#sidebar {
	float:left;
	width:340px;
}
#footer-container {
	clear:both;
}

#content and #sidebar are exactly the same as in the fixed width layouts we’ve seen before. Here I’ve cleared #footer-container instead of #footer, but that’s not really new. The new stuff is the css at the top.

Previously we had a single container div that fixed the width and centered the content. Here we have three, #page, #header, and #footer. Note that we’re fixing and centering the inner divs. Remember #page is the inner div with body being its container.

By default #header-container and #footer-container have a width that’s 100% of the body, which is what we want. All we really need to do is set backgrounds on each.

Since our footer and header divs have no background applied to them the background of their containers will show through. Similarly we can set a background on the body. I didn’t set it here since I want the body and the #page row to be white, which they will be by default.

As long as we don’t set a backgrounds on the divs holding the content the background of their containers will show through giving the appearance of fluidity.

Additional Thoughts

While this layout does create a more fluid feel to a fixed width layout, the downside is the extra html used for all the container divs and that the fluid feel is something of an illusion as most of the design is still fixed.

Still it’s a nice compromise between fixed and fluid layouts.

Note: Soh Tanaka has a slightly different method for achieving this same layout. The basic idea is the same, but Soh uses two classes, one fluid and one fixed. To control the layout you apply the appropriate class to the appropriate div.

I’d encourage you to read his post on achieving liquid background with fixed content.

The minor downside to his method is it leaves behind non-semantic class names in your html, which you may or may not be comfortable doing.

Rearranging Columns

Rearranging columns is exactly the same as it was for the fixed width and fluid layouts. Depending on how many columns and how you have things set up in your html it’s simply a matter of changing float directions for most cases.

For the cases when floats alone won’t do we need to use a small bit of relative and absolute positioning to achieve the desired column order.

Since we’ve been over it before I won’t cover the details here and instead point you to the 3 column fixed width layout post where the details are discussed.

Fluid Layout With Max Width Content

The second hybrid layout we’ll look at starts with a fluid layout and uses max-width values to keep the lines of text from growing too long for comfortable reading.

The HTML

The html is exactly the same we used when developing fully fluid layouts.

<div id="header">
	<p>Header</p>
</div>
<div id="content">
	<p>Content</p>
</div>
<div id="sidebar">
	<p>Sidebar</p>
</div>
<div id="footer">
	<p>Footer</p>
</div>

There’s really nothing new in the html.

The CSS

The css should also look familiar. It’s the same we used when developing fluid layouts with one addition.

#content {
	float:left;
	width:67%;
}
#sidebar {
	float:left;
	width:33%;
}
#footer {
	clear:both;
}
#content p, #sidebar p {max-width: 75%}

The addition is the last line above where we’ve set all paragraphs inside the content and the sidebar to have a max-width of 75% of its parent container.

The amount is somewhat arbitrary. I chose 75% since it works well with the demo and the resolution of my laptop. What you use in practice would depend on your particular layout and audience.

You aren’t limited to setting max-width on paragraphs, however, since we’re mainly setting it to prevent lines of text from growing too long, paragraphs are probably the best place.

As headers and footers usually hold different kinds of content I didn’t set max-width inside either of them here. You might depending on the specifics of your design. The key is setting a max-width wherever content can grow to wide.

Additional Thoughts

In setting max-widths on our fluid layout we’re combating one of the prime downsides of fully fluid layouts, that of text lines growing too long. I set the max-width in % here, but on larger monitors this could still lead to overly long line lengths.

For this reason it might make more sense to use px instead of %. Of course using absolute measurements moves us away from fluid design.

Another point to note is that by setting a max-width on the content we create a greater amount of internal whitespace in the design. The larger the browser the more space will be present between blocks of content.

In the demo I gave additional padding to the content and sidebar to help balance out the additional space in the design, though it’s hardly a perfect solution.

Overall using max-width is a nice way to achieve a fluid layout while still retaining a measure of control over the layout of the content.

Summary

Both fixed width and fully fluid css layouts have their pros and cons. Hybrid layouts are an attempt to rein in some of the cons while keeping the pros.

A layout where the content is fixed and the background is fluid attempts to make fixed width layouts appear more fluid than they really are. They maintain control over the layout of the content, while adding fluidity to the background.

A fluid layout with max-width selectively applied attempts to rein in the possibility of longer lines of text while still allowing the overall design to be fluid and resize itself when the browser window is resized.

These aren’t the only hybrid layout solutions, but they are among the more common. Hopefully the techniques shown here will help you develop your own hybrid layouts when needed.

Go to Source

• Manuscript grid
• Column grid
• Modular grid
• Hierarchical grid

Ideally by the end of this post you’ll have a better idea why you might choose one type of grid over another for a particular project.

I’ll be referring to various grid parts throughout so if those parts are unfamiliar you may want to visit the anatomy of a grid post.

Manuscript Grid

Sometimes called a block grid or single column grid, the manuscript grid is the simplest grid structure. It’s mainly a large rectangular area taking up most of the space inside a format.

The primary structure is defined by large text blocks and margins, which position the block within the format. Its secondary structure defines the location and proportions of folios, footnotes, running headers, and other secondary information.

Manuscript girds are good for extensive and continuous blocks of text. They’re used in books and long essays and perhaps lend themselves well to blog posts. They aren’t limited to text though. Images can be used to fill the block.

By adjusting the margins designers can help create interest. More opportunity for this exists where two page spreads are used as in magazines or books, but even on a single page interest can be created through margins alone.

• Wider margins — lead to narrower text blocks, which helps focus the eye on the text and creates a sense of calm and stability.
• Narrower margins — force the text block to the edge of the format creating tension as the two near each other.

Asymmetrically placed text blocks add visual interest and leave a larger block of whitespace on one side to allow the eye to rest.

Because of the simplicity of manuscript grids, typography plays an important role in creating visual interest. Your choice of typeface, font-size, leading, measure, hierarchy, etc will make up most of your design choices.

Given the name we naturally associate manuscript grids with the printed page, however if you think of any fixed width layout it’s essentially one large block located within a format (the browser window).

Designers typically center these layouts, but with the above ideas in mind perhaps there are better places to locate your layout.

Column Grids

When people think of grids, especially online, they likely think of column grids. As you would expect column grids are made up by placing multiple columns within the format.

Column grids are good when discontinuous information needs to be presented.

For example you might have various asides, pull quotes, etc in your design, which can occupy different columns in the grid. One column might be reserved for text, another for images, and yet another for image captions.

Columns can be dependent on each other, independent from each other, and crossed over by design elements. This leads to a large amount of flexibility when organizing information on the page.

You can separate blocks of information by placing them in different columns and yet still show a connection between them. Perhaps text in one column and images and captions in different column next to the text the image relates to.

The width of a column should depend on some element internal to the design, most likely the size of the text.

A column should be able to accommodate a comfortable measure for reading and avoid excessive hyphenation at the end of lines. Too wide or narrow a column and reading becomes difficult.

Column Gutters

When the margins are wider than the gutters between columns the eye is guided inward and tension is eased. When margins are narrower than gutters the eye is directed outward and more tension is present.

There are no hard rules, but traditionally if the size of the gutter is x the margin is usually set to be 2x.

Flowlines can be used in column grids to help set the subordinate structure or to allow for unusual breaks in text and images. Hanglines and baselines can help establish where different elements will be positioned vertically within the columns.

Modular Grids

Modular grids are like column girds with the addition of horizontal divisions marked by rows. The columns and rows and the gutters between each create a matrix of cells or modules.

Modular grids are good for complex projects that require more control than a column grid can offer. Image galleries and shopping carts are likely candidates for modular grids.

Modular girds lend themselves to the design of tabular information such as charts, forms, navigation, schedules, and of course tables of data. They can help standardize the space in tables and help integrate tables with any surrounding text or images.

Each module in the grid can define a small chunk of information or adjacent modules can be combined to form fields or spatial zones each designated to hold a specific type of information.

Smaller modules allow for a more flexible grid with greater precision, but they can become confusing to work with. Imagine for example setting up a modular grid in which each modules is 1px by 1px. Lot’s of flexibility, but not much practical use.

Modules can be either horizontal or vertical and the proportion of a module can be determined in a variety of ways.

• Average width and height of a paragraph
• Average image size
• Ad unit size
• Type proportions like leading and measure

Margin proportions will ideally be considered at the same time as module and gutter proportions as each relates to and affects the others.

Large publishing systems that present information across a variety of formats often use modular grids to keep design proportions consistent. This can help a company maintain brand consistency.

Aside from their practical uses, modular grids have developed an aesthetic image.

Between 1950 and 1980 they became associated with an ideal social and political order that has its roots in rationalism. The Bauhaus and Swiss style celebrate objectivity, order, and minimalism and turned to modular grids to maintain clarity in form.

This order and clarity can be used to create additional meaning. For example it often conveys a technical or urban feeling and naturally communicates mathematical information.

Hierarchical Grids

Hierarchical grids are commonly found on the web. They’re based more on an intuitive placement of elements, which still conforms to the needs of the information.

Customized proportions are typically used in hierarchical grids instead of regularly repeated intervals. Column widths tend to vary as do the location of flowlines.

They can be thought of as loose organic grids. Development often begins by spontaneously placing design elements. Later a rational structure to coordinate those elements is determined.

Hierarchical grids are good when a project requires an odd grid that doesn’t easily fit one of the other grid types and can be used to unify disparate elements and create a superstructure for organizing them.

If you’ve designed sites where you carefully align elements to each other without using one of the previous 3 grid types, you’re probably approaching a hierarchical grid structure in your design.

Summary

The 4 grids above are the main types of grids you’ll encounter. Each has a different function as far as holding content and choosing the right grid to use should come down to the content for your specific project.

• Manuscript grids — are the simplest and they work well when presenting large continuous blocks of text or images.
• Column grids — work well when the information being presented is discontinuous and different types of information can be placed in different columns.
• Modular grids — work best for more complex problems where columns alone don’t offer enough flexibility. The introduce horizontal spaces between blocks of content.
• Hierarchical girds — can be used when none of the above grids will work to solve the problem. They tend to be created organically by first placing design elements on the page and then finding a rational structure for presenting those elements.

Hopefully everything above has helped you see that grids come in different varieties and more importantly when you might choose one grid type over another. Each can be the appropriate choice for a website as each allows for variety within the grid.

If you currently work with grids which type of grid to you use most frequently?

Go to Source

These aren’t the only 2 hybrid layouts, but hopefully they point the way toward techniques you can use to create your own hybrid layouts.

As always if you simply want the code here are the demos

• Fixed content and fluid background
• 2 column fluid layout with max-width
• 3 column fluid layout with max-width

Fixed Width Content, Fluid Background

The trick to this layout is to use container divs around each row of content within our layout.

This allows us to use the inner div for fixing the width and centering what’s within while allowing the the outer div to stretch from edge to edge in the browser.

By setting backgrounds on the outer div we give the appearance that the layout is fluid, while we maintain control over the content itself. In a sense we create a layout within the layout. This inner layout is fixed, while the outer layout is fluid.

The HTML

The html below is similar to the fixed width layouts we’ve previously discussed.

<div id="header-container">
	<div id="header">
		<p>Header content here</p>
	</div>
</div>
<div id="page">
	<div id="content">
		<p>Main content</p>
	</div>
	<div id="sidebar">
		<p>Sidebar</p>
	</div>
</div>
<div id="footer-container">
	<div id="footer">
		<p>Footer: </p>
	<div>
</div>

The difference is that in the fixed-width layouts we wrapped everything with a single container div. Here we’re wrapping each row of content with a container.

Both header and footer are wrapped with a container div and since the content and sidebar are meant to be displayed next to each other (on a single row in the layout) a single container is used around both.

You might note that while #header and #footer are inner divs, #page is apparently an outer div. We’ll actually use the body as the outer div for #page instead of adding an additional #page-container div.

These multiple container divs are the key to this layout.

The CSS

If you’ve been following along with this series of posts on css layouts most of this css should also be familiar, though there are some new things which we’ll talk about below.

#header-container, #footer-container {background: #777;}
#page, #header, #footer {
	width:960px;
	margin:0 auto;
}
#content {
	float:left;
	width:620px;
}
#sidebar {
	float:left;
	width:340px;
}
#footer-container {
	clear:both;
}

#content and #sidebar are exactly the same as in the fixed width layouts we’ve seen before. Here I’ve cleared #footer-container instead of #footer, but that’s not really new. The new stuff is the css at the top.

Previously we had a single container div that fixed the width and centered the content. Here we have three, #page, #header, and #footer. Note that we’re fixing and centering the inner divs. Remember #page is the inner div with body being its container.

By default #header-container and #footer-container have a width that’s 100% of the body, which is what we want. All we really need to do is set backgrounds on each.

Since our footer and header divs have no background applied to them the background of their containers will show through. Similarly we can set a background on the body. I didn’t set it here since I want the body and the #page row to be white, which they will be by default.

As long as we don’t set a backgrounds on the divs holding the content the background of their containers will show through giving the appearance of fluidity.

Additional Thoughts

While this layout does create a more fluid feel to a fixed width layout, the downside is the extra html used for all the container divs and that the fluid feel is something of an illusion as most of the design is still fixed.

Still it’s a nice compromise between fixed and fluid layouts.

Note: Soh Tanaka has a slightly different method for achieving this same layout. The basic idea is the same, but Soh uses two classes, one fluid and one fixed. To control the layout you apply the appropriate class to the appropriate div.

I’d encourage you to read his post on achieving liquid background with fixed content.

The minor downside to his method is it leaves behind non-semantic class names in your html, which you may or may not be comfortable doing.

Rearranging Columns

Rearranging columns is exactly the same as it was for the fixed width and fluid layouts. Depending on how many columns and how you have things set up in your html it’s simply a matter of changing float directions for most cases.

For the cases when floats alone won’t do we need to use a small bit of relative and absolute positioning to achieve the desired column order.

Since we’ve been over it before I won’t cover the details here and instead point you to the 3 column fixed width layout post where the details are discussed.

Fluid Layout With Max Width Content

The second hybrid layout we’ll look at starts with a fluid layout and uses max-width values to keep the lines of text from growing too long for comfortable reading.

The HTML

The html is exactly the same we used when developing fully fluid layouts.

<div id="header">
	<p>Header</p>
</div>
<div id="content">
	<p>Content</p>
</div>
<div id="sidebar">
	<p>Sidebar</p>
</div>
<div id="footer">
	<p>Footer</p>
</div>

There’s really nothing new in the html.

The CSS

The css should also look familiar. It’s the same we used when developing fluid layouts with one addition.

#content {
	float:left;
	width:67%;
}
#sidebar {
	float:left;
	width:33%;
}
#footer {
	clear:both;
}
#content p, #sidebar p {max-width: 75%}

The addition is the last line above where we’ve set all paragraphs inside the content and the sidebar to have a max-width of 75% of its parent container.

The amount is somewhat arbitrary. I chose 75% since it works well with the demo and the resolution of my laptop. What you use in practice would depend on your particular layout and audience.

You aren’t limited to setting max-width on paragraphs, however, since we’re mainly setting it to prevent lines of text from growing too long, paragraphs are probably the best place.

As headers and footers usually hold different kinds of content I didn’t set max-width inside either of them here. You might depending on the specifics of your design. The key is setting a max-width wherever content can grow to wide.

Additional Thoughts

In setting max-widths on our fluid layout we’re combating one of the prime downsides of fully fluid layouts, that of text lines growing too long. I set the max-width in % here, but on larger monitors this could still lead to overly long line lengths.

For this reason it might make more sense to use px instead of %. Of course using absolute measurements moves us away from fluid design.

Another point to note is that by setting a max-width on the content we create a greater amount of internal whitespace in the design. The larger the browser the more space will be present between blocks of content.

In the demo I gave additional padding to the content and sidebar to help balance out the additional space in the design, though it’s hardly a perfect solution.

Overall using max-width is a nice way to achieve a fluid layout while still retaining a measure of control over the layout of the content.

Summary

Both fixed width and fully fluid css layouts have their pros and cons. Hybrid layouts are an attempt to rein in some of the cons while keeping the pros.

A layout where the content is fixed and the background is fluid attempts to make fixed width layouts appear more fluid than they really are. They maintain control over the layout of the content, while adding fluidity to the background.

A fluid layout with max-width selectively applied attempts to rein in the possibility of longer lines of text while still allowing the overall design to be fluid and resize itself when the browser window is resized.

These aren’t the only hybrid layout solutions, but they are among the more common. Hopefully the techniques shown here will help you develop your own hybrid layouts when needed.

Go to Source

Most of the information in this post comes from Timothy Samara’s book Making and Breaking the Grid.

Anatomy of a Grid

Grids act as guides for the placement of elements in a design. No matter how simple or complex, grids share some common parts, each fulfilling a specific function. Not every one of these parts needs to be present in every grid.

A little further down the page I’ve added an image showing these common grid parts, which you hopefully find helpful as you read through their descriptions below.

Format

The format is the area in which the design sits. In a book or magazine the format is the page. On a website the format is the browser window.

The format defines the live area of a design where type, images, and other media are present.

Margins

Margins are the negative space between the edge of the format and the outer edge of the content.

The proportions of margin help to establish the overall tension (or lack of tension) in a composition. The smaller the margin the more tension is created.

Larger margins create more whitespace and help focus attention on the positive space of the design. Larger margins also help the eye find a place to rest and can be a good area to place subordinate information.

Flowlines

Flowlines are horizontal lines that break the space into horizontal bands. They can be used to help guide the eye across the page and can be used to impose starting and stopping points for text and images to be aligned.

When elements are aligned to the top of a flowline it’s called a hangline as the elements appear to hang from the line.

Type is often aligned to a series of flowlines equally spaced down the page called baselines. The base of the type sits on the line, hence the term. Aligning type to a baseline can help establish a vertical rhythm in a design.

Modules

Modules are individual units of space that are separated by regular intervals. Modules are the basic building blocks of grids. When repeated they create columns and rows.

Ideally the width of a module will be based on the measure of a line of text. The height would be based on some multiple of the type’s leading or line-height.

The upper left corner of a module is considered to be the active corner and the lower right corner, the passive corner.

Spatial Zones

Spatial zones are fields of adjacent modules. Each field can be assigned a specific function within the design.

A long horizontal field might be used to place long horizontal images. A long vertical field might be used for long blocks of text. A large rectangular field might be used for video.

Design elements will often be placed inside a field or spatial zone as opposed to a single module.

Columns

Columns are vertical bands of modules. There can be any number of columns in a grid. More columns leads to more flexibility, but can also make the grid difficult to work with.

Column widths can be equal or they can vary across a grid.

Rows

Rows are the horizontal equivalent of columns. Online it’s harder to plan for rows as the height of the format is often inconsistent and dynamic.

On some pages your design may call for a fixed height, though on most pages your design is allowed grow vertically with the content.

Gutters

Gutters are the spaces separating modules either vertically or horizontally. Typically we think of gutters as the space between columns, but they are also the space between rows.

The minimum width or height of gutters should be an ‘em’ though this should usually be larger to better separate columns from columns and rows from and rows. The height of horizontal gutters should be based on the leading or line-height of the type.

Folio

Folios are created when page numbers are placed consistently in the margin, usually above or below the composition.

Running Header or Footer

A running header is a guide at the top to indicate your position in a manuscript. You’d find information like title, chapter title, section title, author, etc located here. A running footer is then this information is placed at the bottom of the format.

Markers

Markers are placement indicators for subordinate or consistently appearing information. Markers can be used to denote the location of folios, page numbers, etc.

These last 3 are more commonly found as described in print, but there’s no reason they couldn’t also be used on a website.

For example blog posts aren’t usually given page numbers, but they often display the publication date. When present the date is usually shown at the top of the post, but there’s no reason it couldn’t be included in a running header or as a substitute for the page numbers of a folio.

Summary

As more and more web designers are looking to employ girds on the sites they design it makes sense for us to learn the language of grids in order to better understand them and to better talk to each other about them.

When many people talk about grids online there’s often a focus on columns and to a lesser extent baselines. There are more parts to grids though than columns and baselines.

Hopefully the diagram above along with the definitions in this post will give you a foundation for the common language of grids to help you further understand explore using grids in your own work.

Go to Source

Most of the information in this post comes from Timothy Samara’s book Making and Breaking the Grid.

Anatomy of a Grid

Grids act as guides for the placement of elements in a design. No matter how simple or complex, grids share some common parts, each fulfilling a specific function. Not every one of these parts needs to be present in every grid.

A little further down the page I’ve added an image showing these common grid parts, which you hopefully find helpful as you read through their descriptions below.

Format

The format is the area in which the design sits. In a book or magazine the format is the page. On a website the format is the browser window.

The format defines the live area of a design where type, images, and other media are present.

Margins

Margins are the negative space between the edge of the format and the outer edge of the content.

The proportions of margin help to establish the overall tension (or lack of tension) in a composition. The smaller the margin the more tension is created.

Larger margins create more whitespace and help focus attention on the positive space of the design. Larger margins also help the eye find a place to rest and can be a good area to place subordinate information.

Flowlines

Flowlines are horizontal lines that break the space into horizontal bands. They can be used to help guide the eye across the page and can be used to impose starting and stopping points for text and images to be aligned.

When elements are aligned to the top of a flowline it’s called a hangline as the elements appear to hang from the line.

Type is often aligned to a series of flowlines equally spaced down the page called baselines. The base of the type sits on the line, hence the term. Aligning type to a baseline can help establish a vertical rhythm in a design.

Modules

Modules are individual units of space that are separated by regular intervals. Modules are the basic building blocks of grids. When repeated they create columns and rows.

Ideally the width of a module will be based on the measure of a line of text. The height would be based on some multiple of the type’s leading or line-height.

The upper left corner of a module is considered to be the active corner and the lower right corner, the passive corner.

Spatial Zones

Spatial zones are fields of adjacent modules. Each field can be assigned a specific function within the design.

A long horizontal field might be used to place long horizontal images. A long vertical field might be used for long blocks of text. A large rectangular field might be used for video.

Design elements will often be placed inside a field or spatial zone as opposed to a single module.

Columns

Columns are vertical bands of modules. There can be any number of columns in a grid. More columns leads to more flexibility, but can also make the grid difficult to work with.

Column widths can be equal or they can vary across a grid.

Rows

Rows are the horizontal equivalent of columns. Online it’s harder to plan for rows as the height of the format is often inconsistent and dynamic.

On some pages your design may call for a fixed height, though on most pages your design is allowed grow vertically with the content.

Gutters

Gutters are the spaces separating modules either vertically or horizontally. Typically we think of gutters as the space between columns, but they are also the space between rows.

The minimum width or height of gutters should be an ‘em’ though this should usually be larger to better separate columns from columns and rows from and rows. The height of horizontal gutters should be based on the leading or line-height of the type.

Folio

Folios are created when page numbers are placed consistently in the margin, usually above or below the composition.

Running Header or Footer

A running header is a guide at the top to indicate your position in a manuscript. You’d find information like title, chapter title, section title, author, etc located here. A running footer is then this information is placed at the bottom of the format.

Markers

Markers are placement indicators for subordinate or consistently appearing information. Markers can be used to denote the location of folios, page numbers, etc.

These last 3 are more commonly found as described in print, but there’s no reason they couldn’t also be used on a website.

For example blog posts aren’t usually given page numbers, but they often display the publication date. When present the date is usually shown at the top of the post, but there’s no reason it couldn’t be included in a running header or as a substitute for the page numbers of a folio.

Summary

As more and more web designers are looking to employ girds on the sites they design it makes sense for us to learn the language of grids in order to better understand them and to better talk to each other about them.

When many people talk about grids online there’s often a focus on columns and to a lesser extent baselines. There are more parts to grids though than columns and baselines.

Hopefully the diagram above along with the definitions in this post will give you a foundation for the common language of grids to help you further understand explore using grids in your own work.

Go to Source

Since much of what we’ll do here simply builds on what we’ve done before I won’t go into every detail for developing fully fluid layouts. Instead I’ll direct you to the previous posts and focus here on what’s new and different.

• 2 column fixed with layout
• 3 column fixed width layout

On the bright side since we’ll skip some of the previously covered details we’ll develop both 2 and 3 column fluid layouts in one post. If you’d prefer to jump directly to the code here’s a link to the demos.

Let’s start with the 2 column liquid layout.

The HTML

If you’ve been following along with this series the html below should look very familiar. It’s the same html we used to create a 2 column fixed width layout with one exception.

<div id="header">
	<p>Header</p>
</div>
<div id="content">
	<p>Main content</p>
</div>
<div id="sidebar">
	<p>Sidebar</p>
</div>
<div id="footer">
	<p>Footer</p>
</div>

I’ve removed the container div that wrapped the header, content, sidebar, and footer divs. If you remember the purpose of the container div was to fix the width and then center everything in the browser.

Since we don’t need to do either here, we no longer need that container div. Things are already simpler. Nice.

The CSS

Again this should be very familiar if you’ve been following along. There are only a few differences from what we’ve already seen.

body {
	margin:0
}
#content {
	float:left;
	width:67%;
}
#sidebar {
	float:left;
	width:33%;
}
#footer {
	clear:both;
}

Naturally since we removed the container div from the html there’s no container in the css.

The first new css is to set the margin to 0 on the body. By default the body will have some margin pushing it away from the browser edge. We want our layout to be right up against the edge so we reset the margin to 0.

The next difference is we’re specifying widths in % as opposed to px. Since we want our layout to adapt to the size of the browser we have to use a relative measurement instead of a fixed measurement.

If you remember the post on the pros and cons of various css layouts I said that fluid/liquid layouts are relative to the browser. That’s why we’re using %. Units like ‘em’ are also relative, but they’re relative to the size of the font, which is internal to the design.

There’s really nothing else new here. Just as we did with the fixed width layouts, we’ve floated both columns to the left (we could also float the sidebar to the right) and cleared the footer in both directions.

As with the fixed width layouts we can change the location of columns by changing the direction of the floats.

#content {float: right}
#sidebar {float: left}

Gotchas

The potential gotcha is in using % as a measurement. Odds are you’ll want to set some padding or margins on different divs within the layout, and you’ll likely reach first for px. You might try to do the same with other measurements in your design as well.

However as soon as you start adding absolute units like px you’re moving away from a fluid layout. The idea with fluid/liquid layouts is to have all measurements be relative to the browser window so they can resize in proportion as the window is resized.

You also need to watch that % add up to 100%. It’s natural to want 3 columns to have the same width, which would be 33%, but then you’re missing 1%. Better to have two 33% columns and one 34% column. Not a big deal, but something to remember.

I should also note that like the fixed width layouts what’s presented here won’t create columns of equal height. The columns in the demo have equal heights, because I’ve explicitly set them to be equal. In practice the column height will change based on what’s inside each.

I’ll have a post on creating layouts with columns of equal height in a couple of weeks.

3 Column Liquid Layout

If you’ve understood how we set up fixed width layouts and also understood what changed above to make the 2 column fixed layout a 2 column fluid layout, you should already understand how to create a 3 column fluid layout.

I’ll spare you further explanation and simply present the code.

The HTML

<div id="header">
	<p>Header</p>
</div>
<div id="primary">
	<p>Primary Sidebar</p>
</div>
<div id="content">
	<p>Main content</p>
</div>
<div id="secondary">
	<p>Seconday Sidebar</p>
</div>
<div id="footer">
	<p>Footer</p>
</div>

The CSS

#primary {
	float: left:;
	width:25%;
}
#content {
	float:left;
	width:50%;
}
#secondary {
	float:left;
	width:25%;
}
#footer {
	clear:both;
}

Nothing here should be new. If the above isn’t making sense please refer back to the fixed width layout posts and the little bit of explanation for the 2 column layout above.

When it comes to moving columns around you might remember that we needed to use positioning on one of the 3 columns.

The same applies here, though we have to remember to set the value of left as a % instead of px. We’ll also set the body to position relative since we’re no longer using a container div.

Otherwise the explanation for moving columns is exactly the same as it was for the 3 column fixed width layout.

As a reminder for rearranging the columns.

• When divs are floated in the same direction they’ll display in the same order as they appear in the html. The first div will either be the leftmost or rightmost column depending on whether things are floated left or right.
• When two divs are floated in one direction and the third is floated in the opposite direction, the lone div will appear either leftmost or rightmost (depending on the float direction) and the other two divs will be displayed (in their floated direction) in the order they appear in the html.
• When neither of the above works you order the columns by floating the two outside columns left and right and then using positioning on the column in the middle and giving it a left value equal to the width of the left column.

Feel free to ask questions in the comments below if you need further explanation or even better look for the detailed explanation in the 3 column fixed width layout post.

A Word of Caution About Fluid/Liquid Layouts

When I first talked about the pros and cons of different css layouts I mentioned a few about liquid layouts that I’d like to bring up again.

With fluid layouts you give up a lot of control over your design. In some respects that’s how the web should work. We should be giving more control to our audience. However there are times when maintaing control over certain aspects of a design is important.

A major drawback to fluid layouts is that in allowing everything to resize you allow the measure or length of a line of text to resize without any minimum or maximum. That can and does leads to lines of text either too long or too short, which can be uncomfortable to read.

It also means other design elements start reflowing around the text in sometimes unpredictable ways. One way to counter this is by setting some min and max widths.

Unfortunately that kind of goes against the point of having the layout be fully liquid and it can also lead to too much or too little whitespace within your design.

While I think creating designs that are more fluid and adaptable to the different ways our sites and pages will be be viewed is a goal we should strive for, I don’t care much for fully fluid layouts and can’t remember the last time I used one.

I also think that our fluid designs should be relative to something internal to the design and not external to the browser and we’ll get to those designs when we talk about elastic layouts.

Summary

Once again here’s a link to the demos.

As with the fixed width layouts, the html and css here are rather simple. If you understood how to build the former you shouldn’t have any problems with the liquid layouts here. The concepts are pretty much the same.

All we’ve done differently with the fluid layouts is remove the container div (which we used to fixed the width and center the layouts) and to use relative units of measurement (%) instead of absolute units of measurement (px).

It should also be relatively simple for you to add a 4th or 5th column to your fluid layout. Again it’s the same concepts we’ve already seen.

As I’ve done in the previous posts I’ll encourage you to play around with the code here and see what you can do with it. You need to practice making this code do your bidding before you can truly understand how it works

We’ll continue this series with hybrid layouts, which we’ll find are also surprisingly familiar to what we’ve already seen.

Go to Source

Since much of what we’ll do here simply builds on what we’ve done before I won’t go into every detail for developing fully fluid layouts. Instead I’ll direct you to the previous posts and focus here on what’s new and different.

• 2 column fixed with layout
• 3 column fixed width layout

On the bright side since we’ll skip some of the previously covered details we’ll develop both 2 and 3 column fluid layouts in one post. If you’d prefer to jump directly to the code here’s a link to the demos.

Let’s start with the 2 column liquid layout.

The HTML

If you’ve been following along with this series the html below should look very familiar. It’s the same html we used to create a 2 column fixed width layout with one exception.

<div id="header">
	<p>Header</p>
</div>
<div id="content">
	<p>Main content</p>
</div>
<div id="sidebar">
	<p>Sidebar</p>
</div>
<div id="footer">
	<p>Footer</p>
</div>

I’ve removed the container div that wrapped the header, content, sidebar, and footer divs. If you remember the purpose of the container div was to fix the width and then center everything in the browser.

Since we don’t need to do either here, we no longer need that container div. Things are already simpler. Nice.

The CSS

Again this should be very familiar if you’ve been following along. There are only a few differences from what we’ve already seen.

body {
	margin:0
}
#content {
	float:left;
	width:67%;
}
#sidebar {
	float:left;
	width:33%;
}
#footer {
	clear:both;
}

Naturally since we removed the container div from the html there’s no container in the css.

The first new css is to set the margin to 0 on the body. By default the body will have some margin pushing it away from the browser edge. We want our layout to be right up against the edge so we reset the margin to 0.

The next difference is we’re specifying widths in % as opposed to px. Since we want our layout to adapt to the size of the browser we have to use a relative measurement instead of a fixed measurement.

If you remember the post on the pros and cons of various css layouts I said that fluid/liquid layouts are relative to the browser. That’s why we’re using %. Units like ‘em’ are also relative, but they’re relative to the size of the font, which is internal to the design.

There’s really nothing else new here. Just as we did with the fixed width layouts, we’ve floated both columns to the left (we could also float the sidebar to the right) and cleared the footer in both directions.

As with the fixed width layouts we can change the location of columns by changing the direction of the floats.

#content {float: right}
#sidebar {float: left}

Gotchas

The potential gotcha is in using % as a measurement. Odds are you’ll want to set some padding or margins on different divs within the layout, and you’ll likely reach first for px. You might try to do the same with other measurements in your design as well.

However as soon as you start adding absolute units like px you’re moving away from a fluid layout. The idea with fluid/liquid layouts is to have all measurements be relative to the browser window so they can resize in proportion as the window is resized.

You also need to watch that % add up to 100%. It’s natural to want 3 columns to have the same width, which would be 33%, but then you’re missing 1%. Better to have two 33% columns and one 34% column. Not a big deal, but something to remember.

I should also note that like the fixed width layouts what’s presented here won’t create columns of equal height. The columns in the demo have equal heights, because I’ve explicitly set them to be equal. In practice the column height will change based on what’s inside each.

I’ll have a post on creating layouts with columns of equal height in a couple of weeks.

3 Column Liquid Layout

If you’ve understood how we set up fixed width layouts and also understood what changed above to make the 2 column fixed layout a 2 column fluid layout, you should already understand how to create a 3 column fluid layout.

I’ll spare you further explanation and simply present the code.

The HTML

<div id="header">
	<p>Header</p>
</div>
<div id="primary">
	<p>Primary Sidebar</p>
</div>
<div id="content">
	<p>Main content</p>
</div>
<div id="secondary">
	<p>Seconday Sidebar</p>
</div>
<div id="footer">
	<p>Footer</p>
</div>

The CSS

#primary {
	float: left:;
	width:25%;
}
#content {
	float:left;
	width:50%;
}
#secondary {
	float:left;
	width:25%;
}
#footer {
	clear:both;
}

Nothing here should be new. If the above isn’t making sense please refer back to the fixed width layout posts and the little bit of explanation for the 2 column layout above.

When it comes to moving columns around you might remember that we needed to use positioning on one of the 3 columns.

The same applies here, though we have to remember to set the value of left as a % instead of px. We’ll also set the body to position relative since we’re no longer using a container div.

Otherwise the explanation for moving columns is exactly the same as it was for the 3 column fixed width layout.

As a reminder for rearranging the columns.

• When divs are floated in the same direction they’ll display in the same order as they appear in the html. The first div will either be the leftmost or rightmost column depending on whether things are floated left or right.
• When two divs are floated in one direction and the third is floated in the opposite direction, the lone div will appear either leftmost or rightmost (depending on the float direction) and the other two divs will be displayed (in their floated direction) in the order they appear in the html.
• When neither of the above works you order the columns by floating the two outside columns left and right and then using positioning on the column in the middle and giving it a left value equal to the width of the left column.

Feel free to ask questions in the comments below if you need further explanation or even better look for the detailed explanation in the 3 column fixed width layout post.

A Word of Caution About Fluid/Liquid Layouts

When I first talked about the pros and cons of different css layouts I mentioned a few about liquid layouts that I’d like to bring up again.

With fluid layouts you give up a lot of control over your design. In some respects that’s how the web should work. We should be giving more control to our audience. However there are times when maintaing control over certain aspects of a design is important.

A major drawback to fluid layouts is that in allowing everything to resize you allow the measure or length of a line of text to resize without any minimum or maximum. That can and does leads to lines of text either too long or too short, which can be uncomfortable to read.

It also means other design elements start reflowing around the text in sometimes unpredictable ways. One way to counter this is by setting some min and max widths.

Unfortunately that kind of goes against the point of having the layout be fully liquid and it can also lead to too much or too little whitespace within your design.

While I think creating designs that are more fluid and adaptable to the different ways our sites and pages will be be viewed is a goal we should strive for, I don’t care much for fully fluid layouts and can’t remember the last time I used one.

I also think that our fluid designs should be relative to something internal to the design and not external to the browser and we’ll get to those designs when we talk about elastic layouts.

Summary

Once again here’s a link to the demos.

As with the fixed width layouts, the html and css here are rather simple. If you understood how to build the former you shouldn’t have any problems with the liquid layouts here. The concepts are pretty much the same.

All we’ve done differently with the fluid layouts is remove the container div (which we used to fixed the width and center the layouts) and to use relative units of measurement (%) instead of absolute units of measurement (px).

It should also be relatively simple for you to add a 4th or 5th column to your fluid layout. Again it’s the same concepts we’ve already seen.

As I’ve done in the previous posts I’ll encourage you to play around with the code here and see what you can do with it. You need to practice making this code do your bidding before you can truly understand how it works

We’ll continue this series with hybrid layouts, which we’ll find are also surprisingly familiar to what we’ve already seen.

Go to Source

What Are Semantics

Before we get to semantic html we should quickly define semantics.

semantics (adj.)

• of or relating to meaning, especially in language
• the meaning or relationship of meanings of a sign or set of signs

When people say they want to make something more semantic, they simply want to make that thing more meaningful.

What is Semantic HTML?

Semantic html is using html to reinforce structural meaning. It’s about using tags, class names, and ids that reinforce the meaning of the content within the tags.

When content is a paragraph of text you mark it up with paragraph tags. When you have a list of items you use list tags. If there’s some order to the list items you use an ordered list and when the order isn’t important you use an unordered list.

Each of the tags mentioned is semantic since they describe the content inside the tag.

Semantic html is also about using tags in the right way. A blockquote exists to hold a quote inside, not because some bit of text needs to be indented.

How something looks has nothing to do with what it means. It’s why we separate html and css. The former is for structure and meaning, while the latter is for how we present that structure and meaning.

Say you write an article with a main heading and several subheadings. You could easily place each of the headings in a div, add a class or id, and style those divs in any way you’d like.

We could for example style the following html to visually show our main heading and subheadings:

<div class="big-and-bold">
<div class="not-quite-so-big-and-bold">
<div class="small-and-thin">

Visually each of those headings could communicate hierarchy through size and weight. You could clearly communicate the meaning of each heading to your audience through presentation.

However anyone or anything viewing the html alone wouldn’t have this meaning communicated to them. Your hierarchy could be inferred by comparing all those divs, but there’s no real hierarchy there.

<div class=”big-and-bold”> tells us absolutely nothing meaningful about the content inside the div. It only suggests what the content will look like.

An <h1> tag on the other hand clearly says this is the most important heading on the page. This is the top of the hierarchy.

Most people, who aren’t web developers, designers or SEOs, probably aren’t going to view your article by looking at your html directly. Since you can visually communicate meaning to your audience why is semantic html important?

Why Semantic HTML is Important

Semantic html is an additional layer of communication. When you use semantic html you communicate more than when you use non-semantic html. Isn’t that pretty much the point of what we do? Communicate.

Real people looking only at how your page displays may never get that additional communication, but machines will.

Machines like screen readers and feed readers and search engines. Providing that extra meaning allows those machines to translate the meaning for real people.

Semantic html is important because it’s:

• Clean — It’s easier to read and edit, which saves time and money during maintainence.

  Imagine adding the non-semantic class=”red” to a span of text. Later you decide that text should be green. That’s going to be confusing to someone editing the html at a later date.

  Better would be to use something like class=”price” (assuming the content is a price on an ecommerce site). You could then change the color from red to green to blue to orange without confusing what that content is.

• More accessible — It can be better understood by a greater variety of devices. Those devices can then add their own style and presentation based on what’s best for the device.

  A screen reader could raise and lower volume to communicate the hierarchy of your h1-h6 tags for example since you’ve clearly indicated a hierarchy.

  The more meaningful the structure of your content, the better different tools can make use of your content.

• Search engine friendly — This is still debatable as search engines rank content and not code, but search engines are making greater use of things like microformats to understand content.

  Google can read the hreview microformat and can use the data to create richer snippets below search results.

  They could potentially rank pages they know to be reviews higher when someone is specifically searching for a review.

I’m sure you’ve seen arguments for why it’s better to use css than tables to layout a website. One reason is semantics.

An html table is meant to house data, the kind of stuff you’d place in a spreadsheet. Using table for layout confuses the communication.

Just as you wouldn’t create a slide for a presentation by placing images and text in spreadsheet cells you shouldn’t do the same inside html tables.

You might have a slide that features data in a spreadsheet, just as you might create a web page that features data in a table, but you wouldn’t try to design every slide using a spreadsheet.

Is it OK to Use Non-Semantic HTML?

Many would answer no. Some might think I’m crazy for even asking the question.

Since semantic html is communicating more than non-semantic html it would seem to make sense to always use semantic html. But are there times when non-semantic html might actually make development easier?

Consider css grid frameworks, which typically include class names like grid_1 or container_12. They aren’t semantic.

A class name like container_12 indicates a 12 column grid, but what happens later when you want to change the site to a 16 column grid or a 4 column grid.

Classes like grid_1 don’t exactly help screen readers or search engines understand content either. They aren’t describing the content. They’re describing the presentation of content.

At the same time those class names can be very meaningful to a designer who works with grids. At a glance the underlying grid structure of the design is readily apparent.

Grid frameworks generally help speed development time as well so there are benefits to using them. Yet some would say we should never use them because of the lack of semantics

Where do we draw the line?

Good class names should never need to change, however the presentation of a website sometimes does change. When structure and presentation are mixed as in class=”red” or class=”grid_5″ we have to:

• Change structure to change presentation
• Confuse style and structure such as styling class=”red” to be green
• Leave behind classes in html that are no longer styled at all

One solution is to use frameworks like Compass, Scaffold and Sass to convert our non-semantic code to semantic code.

Doing so we gain the benefits of working with grid based class names during development and then convert our code to semantic markup for the live site.

Like most design decisions there’s always a tradeoff. We have to weigh the good and bad and decide which is best to use for a given project.

I’m still mixed on how semantic my code needs to be. All things being equal we should always choose the semantic option, but all things are seldom equal.

At times I think the benefits of some non-semantic html as in the grid based class names are worth the loss of semantic meaning. I do think we should strive to write semantic code. I don’t think non-semantic code is as evil as some would suggest.

Ask me in 6 months though and I may easily have changed my mind. If you have arguments for or against the use of semantic code please share.

Summary

Communication is the central task of web designers. Most of the time we think of communication in terms of the words we use and the visuals we create, but it also extends to the code we write.

Semantics are about meaning. Writing semantic code means writing more meaningful code. We should strive to write html that describes content and not the presentation of that content.

class=”red” is always a bad idea, but what about class=”grid_4″? Is all non-semantic markup bad or is it ok at times and under certain circumstances?

My best answer is we should do our best to write semantic code, but we shouldn’t obsess over it. Similar to how we should do our best to write valid code though not worry about an invalid line here or there? Again I haven’t entirely made up mind about this.

Where do you stand. Should all code be semantic? Is it ok to be non-semantic at times? What do you consider best practice?

Go to Source

What Are Semantics

Before we get to semantic html we should quickly define semantics.

semantics (adj.)

• of or relating to meaning, especially in language
• the meaning or relationship of meanings of a sign or set of signs

When people say they want to make something more semantic, they simply want to make that thing more meaningful.

What is Semantic HTML?

Semantic html is using html to reinforce structural meaning. It’s about using tags, class names, and ids that reinforce the meaning of the content within the tags.

When content is a paragraph of text you mark it up with paragraph tags. When you have a list of items you use list tags. If there’s some order to the list items you use an ordered list and when the order isn’t important you use an unordered list.

Each of the tags mentioned is semantic since they describe the content inside the tag.

Semantic html is also about using tags in the right way. A blockquote exists to hold a quote inside, not because some bit of text needs to be indented.

How something looks has nothing to do with what it means. It’s why we separate html and css. The former is for structure and meaning, while the latter is for how we present that structure and meaning.

Say you write an article with a main heading and several subheadings. You could easily place each of the headings in a div, add a class or id, and style those divs in any way you’d like.

We could for example style the following html to visually show our main heading and subheadings:

<div class="big-and-bold">
<div class="not-quite-so-big-and-bold">
<div class="small-and-thin">

Visually each of those headings could communicate hierarchy through size and weight. You could clearly communicate the meaning of each heading to your audience through presentation.

However anyone or anything viewing the html alone wouldn’t have this meaning communicated to them. Your hierarchy could be inferred by comparing all those divs, but there’s no real hierarchy there.

<div class=”big-and-bold”> tells us absolutely nothing meaningful about the content inside the div. It only suggests what the content will look like.

An <h1> tag on the other hand clearly says this is the most important heading on the page. This is the top of the hierarchy.

Most people, who aren’t web developers, designers or SEOs, probably aren’t going to view your article by looking at your html directly. Since you can visually communicate meaning to your audience why is semantic html important?

Why Semantic HTML is Important

Semantic html is an additional layer of communication. When you use semantic html you communicate more than when you use non-semantic html. Isn’t that pretty much the point of what we do? Communicate.

Real people looking only at how your page displays may never get that additional communication, but machines will.

Machines like screen readers and feed readers and search engines. Providing that extra meaning allows those machines to translate the meaning for real people.

Semantic html is important because it’s:

• Clean — It’s easier to read and edit, which saves time and money during maintainence.

  Imagine adding the non-semantic class=”red” to a span of text. Later you decide that text should be green. That’s going to be confusing to someone editing the html at a later date.

  Better would be to use something like class=”price” (assuming the content is a price on an ecommerce site). You could then change the color from red to green to blue to orange without confusing what that content is.

• More accessible — It can be better understood by a greater variety of devices. Those devices can then add their own style and presentation based on what’s best for the device.

  A screen reader could raise and lower volume to communicate the hierarchy of your h1-h6 tags for example since you’ve clearly indicated a hierarchy.

  The more meaningful the structure of your content, the better different tools can make use of your content.

• Search engine friendly — This is still debatable as search engines rank content and not code, but search engines are making greater use of things like microformats to understand content.

  Google can read the hreview microformat and can use the data to create richer snippets below search results.

  They could potentially rank pages they know to be reviews higher when someone is specifically searching for a review.

I’m sure you’ve seen arguments for why it’s better to use css than tables to layout a website. One reason is semantics.

An html table is meant to house data, the kind of stuff you’d place in a spreadsheet. Using table for layout confuses the communication.

Just as you wouldn’t create a slide for a presentation by placing images and text in spreadsheet cells you shouldn’t do the same inside html tables.

You might have a slide that features data in a spreadsheet, just as you might create a web page that features data in a table, but you wouldn’t try to design every slide using a spreadsheet.

Is it OK to Use Non-Semantic HTML?

Many would answer no. Some might think I’m crazy for even asking the question.

Since semantic html is communicating more than non-semantic html it would seem to make sense to always use semantic html. But are there times when non-semantic html might actually make development easier?

Consider css grid frameworks, which typically include class names like grid_1 or container_12. They aren’t semantic.

A class name like container_12 indicates a 12 column grid, but what happens later when you want to change the site to a 16 column grid or a 4 column grid.

Classes like grid_1 don’t exactly help screen readers or search engines understand content either. They aren’t describing the content. They’re describing the presentation of content.

At the same time those class names can be very meaningful to a designer who works with grids. At a glance the underlying grid structure of the design is readily apparent.

Grid frameworks generally help speed development time as well so there are benefits to using them. Yet some would say we should never use them because of the lack of semantics

Where do we draw the line?

Good class names should never need to change, however the presentation of a website sometimes does change. When structure and presentation are mixed as in class=”red” or class=”grid_5″ we have to:

• Change structure to change presentation
• Confuse style and structure such as styling class=”red” to be green
• Leave behind classes in html that are no longer styled at all

One solution is to use frameworks like Compass, Scaffold and Sass to convert our non-semantic code to semantic code.

Doing so we gain the benefits of working with grid based class names during development and then convert our code to semantic markup for the live site.

Like most design decisions there’s always a tradeoff. We have to weigh the good and bad and decide which is best to use for a given project.

I’m still mixed on how semantic my code needs to be. All things being equal we should always choose the semantic option, but all things are seldom equal.

At times I think the benefits of some non-semantic html as in the grid based class names are worth the loss of semantic meaning. I do think we should strive to write semantic code. I don’t think non-semantic code is as evil as some would suggest.

Ask me in 6 months though and I may easily have changed my mind. If you have arguments for or against the use of semantic code please share.

Summary

Communication is the central task of web designers. Most of the time we think of communication in terms of the words we use and the visuals we create, but it also extends to the code we write.

Semantics are about meaning. Writing semantic code means writing more meaningful code. We should strive to write html that describes content and not the presentation of that content.

class=”red” is always a bad idea, but what about class=”grid_4″? Is all non-semantic markup bad or is it ok at times and under certain circumstances?

My best answer is we should do our best to write semantic code, but we shouldn’t obsess over it. Similar to how we should do our best to write valid code though not worry about an invalid line here or there? Again I haven’t entirely made up mind about this.

Where do you stand. Should all code be semantic? Is it ok to be non-semantic at times? What do you consider best practice?

Go to Source

There will be some new concepts when we try to move the columns around for which I’ll offer a more detailed explanation.

For those who prefer to skip the explanation here’s a demo of what we’ll be building and you can view the source for the code.

The HTML

As with the 2 column layout, the html for a 3 column layout is rather simple. In fact the only real difference is one additional div for our third column.

<div id="container">
        <div id="header">
		<p>Header</p>
	</div>
	<div id="primary">
		<p>Primary Sidebar</p>
	</div>
	<div id="content">
		<p>Main content</p>
	</div>
	<div id="secondary">
		<p>Secondary Sidebar</p>
	</div>
	<div id="footer">
		<p>Footer</p>
	</div>
</div>

Instead of using sidebar-1 and sidebar-2 I’m calling the sidebars primary and secondary. You’re free to call them whatever works best for you.

One point to make about the html is the order of the divs. If you remember last week we moved the columns simply by changing the direction of floated divs. We’ll do the same here, but that alone won’t allow us to reorder the columns in all possible ways.

I’ll get to the details in a bit, but with 3 columns there are 6 potential ways to order those columns. We can achieve 4 of those 6 ways just by changing the direction of the floats. For the last 2 we’ll need to use some relative and absolute positioning.

The CSS

Once again the css is rather simple and should be familiar if you read the previous post. And just as with the 2 column demo I’ve stripped away css that’s only there to make the demo more presentable. Here’s the css we need for this layout

#container {
	width: 960px;
	margin: 0 auto;
}
#primary {
	float: left;
	width: 240px;
}
#content {
	float: left;
	width: 480px;
}
#secondary {
	float: left;
	width: 240px;
}
#footer {
	clear: both;
}

There really isn’t anything new here when compared to the 2 column layout. We’ve used our container div to center everything on the page and floated our columns to the left. Lastly we cleared the footer.

If you need explanation about what’s going on please see that explanation in the 2 column layout post.

While I’ve floated all 3 divs to the left, you could also float the rightmost column to the right. In this case that would our #secondary div.

I typically float all columns in the same direction, though I think it’s more common to float the rightmost div to the right. Like I mentioned last week, I’m unaware of either being better or worse.

Floating everything in one direction made it easier for me to understand when I first started working with floats and now it’s become habit.

Rearranging the Columns

The first way to rearrange columns is to reorder their divs in the html. When first developing a site you’ll likely structure your html how you want the columns to display on the page.

There will be times though when you want to move the columns around after the site is live or because you want to the columns to have different orders on different pages without having to change the html.

Fortunately we can rearrange the columns through css alone and doing so will hopefully make for a good learning experience.

I mentioned above there were 6 possible ways we could order the 3 columns.

• primary, content, secondary
• secondary, content, primary
• content, secondary, primary
• primary, secondary, content
• secondary, primary, content
• content, primary, secondary

Not the most logical order to list them I admit, but there’s a reason why I’ve listed them this way.

The first order above (primary, content, secondary) we’ve already coded. The next 3 on the list we can get to by changing float directions. For the last two we’ll need to mix in some positioning.

Secondary, Content, Primary

When we float all 3 columns in the same direction they will always display in the same order they appear in the html. That will be true regardless of whether we float all 3 to the left (as we’ve done above) or to the right.

If we float all 3 divs to the right we’ll get the reverse order of how they appear in the html, which is all we need to achieve this column order.

The easiest way then to have all 3 columns display in the same sequential order as they appear in the html is to float all 3 in the same direction either left or right.

Primary, Secondary, Content

To get the next two layouts on the list we’ll change the direction of a single float so it’s in the opposite direction of the other two.

When we float any 2 of the 3 columns in one direction and float the third in the opposite direction, the one floated opposite will sit at the outermost edge in the direction it’s floated.

If we want to move our main content div to the right we’ll float our main content to the right and keep primary and secondary floated to the left.

As you might expect the two sidebars display to the left of the content in the order they appear in the html. In our case the primary column will be leftmost and the secondary column will appear to it’s right.

Content, Secondary, Primary

Similarly if we want our primary column to be the rightmost column we float it to the right and float the other 2 columns to the left.

Again if 2 columns are floated in one direction and the third is floated opposite the opposite will display at the far end of the same direction it’s floated and the other 2 columns will display in the order seen in the html.

Secondary, Primary, Content

Unfortunately we need to do more than change float directions to get the last 2 orders.

Let’s think for a moment about how we might go about setting up this column order. Since we want the main content column to be rightmost let’s start by floating it to the right.

One of our 3 columns is now where want. We’re left needing to swap the order of the primary and secondary columns.

Your first instinct might be to float the primary column to the right, but that will place it to the right of the main content. What we need to do is add some positioning. Fortunately we don’t need to add a lot.

I won’t be able to offer a full explanation for how positioning works here so I’ll direct you to my post on understanding css positioning if you need a more detailed explanation for why the following works.

First we’ll add relative positioning to our container div

#container {position: relative}

This won’t affect our #container div at all, but it will allow us to position columns relative to the container div. If we skip this we’ll be positioning columns relative to the body of our html.

Next we’ll remove the float and add absolute positioning to the primary sidebar.

#primary {position: absolute}

If we stop here something strange happens. Our primary column hasn’t moved, but our secondary column seems to have vanished.

By default our primary column will have a value of 0 for it’s left property, which keeps it right where it was. However by changing from a float to position the primary column no longer holds the secondary column to its right.

Our secondary column is now hiding behind our primary column. Understanding why is a matter of understanding the css stack and the z-index property.

We need to move the primary column further to the right, which will also reveal the secondary column. We do so by increasing the value of left to be equal to the width of the secondary column

#primary {left: 240px}

And now all 3 columns are displaying exactly where we want.

Content, Primary, Secondary

To get our last layout we need to reverse the order of the columns we just set up above.

Here we want the content on the left and the secondary column on the right so let’s switch the direction of the floats for both.

Not bad. We’re almost there. In fact the only problem at this point is the primary div isn’t far enough to the right. We just need to alter it’s left value to match the width of the content.

#primary {left: 480px}

and we’re done.

We used the same basic concept in both of the above orders.

The column we wanted to be furthest left we float left. The column we wanted to be furthest to the right we float right. For the column we want in between we used absolute positioning and gave it a left value equal to the width of the leftmost column.

We also made sure to add relative positioning to the container div.

Note: Like our 2 column layout this won’t create columns of equal height as it appears in the demo. The columns have equal height because I set their heights to the same value. Creating equal height columns is something for another time, though I promise to write a post about how before too long if you’re interested.

Summary

Setting up the css for a 3 column layout isn’t really any harder than setting up the css for a 2 column layout. The same principle of floating all the columns in the same direction applies.

If you’ve understood this and the last post you should now be able to create 4 and 5 column layouts as well.

What’s a little trickier is rearranging the columns. We changed the float direction of columns to achieve several column layouts and used positioning to get to a couple more.

If you’ve been following along you now have several different methods for setting up multi-column css layouts regardless of how many columns and regardless of the order those columns appear in your html.

I’d encourage you to play around. Change floats and position different columns. Try adding a 4th column and see how you can reorganize all of them.

In this and the last post I’ve given you some instructions for moving blocks around on a web page. Spend some time moving those blocks around. The more you experiment on your own, the greater you’ll understand how and why this all works.

Next week I’ll continue with fully fluid layouts. The principles will be very much the same as they are here with one key difference.

Go to Source

There will be some new concepts when we try to move the columns around for which I’ll offer a more detailed explanation.

For those who prefer to skip the explanation here’s a demo of what we’ll be building and you can view the source for the code.

The HTML

As with the 2 column layout, the html for a 3 column layout is rather simple. In fact the only real difference is one additional div for our third column.

<div id="container">
        <div id="header">
		<p>Header</p>
	</div>
	<div id="primary">
		<p>Primary Sidebar</p>
	</div>
	<div id="content">
		<p>Main content</p>
	</div>
	<div id="secondary">
		<p>Secondary Sidebar</p>
	</div>
	<div id="footer">
		<p>Footer</p>
	</div>
</div>

Instead of using sidebar-1 and sidebar-2 I’m calling the sidebars primary and secondary. You’re free to call them whatever works best for you.

One point to make about the html is the order of the divs. If you remember last week we moved the columns simply by changing the direction of floated divs. We’ll do the same here, but that alone won’t allow us to reorder the columns in all possible ways.

I’ll get to the details in a bit, but with 3 columns there are 6 potential ways to order those columns. We can achieve 4 of those 6 ways just by changing the direction of the floats. For the last 2 we’ll need to use some relative and absolute positioning.

The CSS

Once again the css is rather simple and should be familiar if you read the previous post. And just as with the 2 column demo I’ve stripped away css that’s only there to make the demo more presentable. Here’s the css we need for this layout

#container {
	width: 960px;
	margin: 0 auto;
}
#primary {
	float: left;
	width: 240px;
}
#content {
	float: left;
	width: 480px;
}
#secondary {
	float: left;
	width: 240px;
}
#footer {
	clear: both;
}

There really isn’t anything new here when compared to the 2 column layout. We’ve used our container div to center everything on the page and floated our columns to the left. Lastly we cleared the footer.

If you need explanation about what’s going on please see that explanation in the 2 column layout post.

While I’ve floated all 3 divs to the left, you could also float the rightmost column to the right. In this case that would our #secondary div.

I typically float all columns in the same direction, though I think it’s more common to float the rightmost div to the right. Like I mentioned last week, I’m unaware of either being better or worse.

Floating everything in one direction made it easier for me to understand when I first started working with floats and now it’s become habit.

Rearranging the Columns

The first way to rearrange columns is to reorder their divs in the html. When first developing a site you’ll likely structure your html how you want the columns to display on the page.

There will be times though when you want to move the columns around after the site is live or because you want to the columns to have different orders on different pages without having to change the html.

Fortunately we can rearrange the columns through css alone and doing so will hopefully make for a good learning experience.

I mentioned above there were 6 possible ways we could order the 3 columns.

• primary, content, secondary
• secondary, content, primary
• content, secondary, primary
• primary, secondary, content
• secondary, primary, content
• content, primary, secondary

Not the most logical order to list them I admit, but there’s a reason why I’ve listed them this way.

The first order above (primary, content, secondary) we’ve already coded. The next 3 on the list we can get to by changing float directions. For the last two we’ll need to mix in some positioning.

Secondary, Content, Primary

When we float all 3 columns in the same direction they will always display in the same order they appear in the html. That will be true regardless of whether we float all 3 to the left (as we’ve done above) or to the right.

If we float all 3 divs to the right we’ll get the reverse order of how they appear in the html, which is all we need to achieve this column order.

The easiest way then to have all 3 columns display in the same sequential order as they appear in the html is to float all 3 in the same direction either left or right.

Primary, Secondary, Content

To get the next two layouts on the list we’ll change the direction of a single float so it’s in the opposite direction of the other two.

When we float any 2 of the 3 columns in one direction and float the third in the opposite direction, the one floated opposite will sit at the outermost edge in the direction it’s floated.

If we want to move our main content div to the right we’ll float our main content to the right and keep primary and secondary floated to the left.

As you might expect the two sidebars display to the left of the content in the order they appear in the html. In our case the primary column will be leftmost and the secondary column will appear to it’s right.

Content, Secondary, Primary

Similarly if we want our primary column to be the rightmost column we float it to the right and float the other 2 columns to the left.

Again if 2 columns are floated in one direction and the third is floated opposite the opposite will display at the far end of the same direction it’s floated and the other 2 columns will display in the order seen in the html.

Secondary, Primary, Content

Unfortunately we need to do more than change float directions to get the last 2 orders.

Let’s think for a moment about how we might go about setting up this column order. Since we want the main content column to be rightmost let’s start by floating it to the right.

One of our 3 columns is now where want. We’re left needing to swap the order of the primary and secondary columns.

Your first instinct might be to float the primary column to the right, but that will place it to the right of the main content. What we need to do is add some positioning. Fortunately we don’t need to add a lot.

I won’t be able to offer a full explanation for how positioning works here so I’ll direct you to my post on understanding css positioning if you need a more detailed explanation for why the following works.

First we’ll add relative positioning to our container div

#container {position: relative}

This won’t affect our #container div at all, but it will allow us to position columns relative to the container div. If we skip this we’ll be positioning columns relative to the body of our html.

Next we’ll remove the float and add absolute positioning to the primary sidebar.

#primary {position: absolute}

If we stop here something strange happens. Our primary column hasn’t moved, but our secondary column seems to have vanished.

By default our primary column will have a value of 0 for it’s left property, which keeps it right where it was. However by changing from a float to position the primary column no longer holds the secondary column to its right.

Our secondary column is now hiding behind our primary column. Understanding why is a matter of understanding the css stack and the z-index property.

We need to move the primary column further to the right, which will also reveal the secondary column. We do so by increasing the value of left to be equal to the width of the secondary column

#primary {left: 240px}

And now all 3 columns are displaying exactly where we want.

Content, Primary, Secondary

To get our last layout we need to reverse the order of the columns we just set up above.

Here we want the content on the left and the secondary column on the right so let’s switch the direction of the floats for both.

Not bad. We’re almost there. In fact the only problem at this point is the primary div isn’t far enough to the right. We just need to alter it’s left value to match the width of the content.

#primary {left: 480px}

and we’re done.

We used the same basic concept in both of the above orders.

The column we wanted to be furthest left we float left. The column we wanted to be furthest to the right we float right. For the column we want in between we used absolute positioning and gave it a left value equal to the width of the leftmost column.

We also made sure to add relative positioning to the container div.

Note: Like our 2 column layout this won’t create columns of equal height as it appears in the demo. The columns have equal height because I set their heights to the same value. Creating equal height columns is something for another time, though I promise to write a post about how before too long if you’re interested.

Summary

Setting up the css for a 3 column layout isn’t really any harder than setting up the css for a 2 column layout. The same principle of floating all the columns in the same direction applies.

If you’ve understood this and the last post you should now be able to create 4 and 5 column layouts as well.

What’s a little trickier is rearranging the columns. We changed the float direction of columns to achieve several column layouts and used positioning to get to a couple more.

If you’ve been following along you now have several different methods for setting up multi-column css layouts regardless of how many columns and regardless of the order those columns appear in your html.

I’d encourage you to play around. Change floats and position different columns. Try adding a 4th column and see how you can reorganize all of them.

In this and the last post I’ve given you some instructions for moving blocks around on a web page. Spend some time moving those blocks around. The more you experiment on your own, the greater you’ll understand how and why this all works.

Next week I’ll continue with fully fluid layouts. The principles will be very much the same as they are here with one key difference.

Go to Source

“The power of the golden section to create harmony arises from its unique capacity to unite different parts of a whole so that each preserves its own identity and yet blends into the greater pattern of a single whole.”
— György Dóczi, The Power of Limits

Golden section proportions can be found in both nature and man-made structures. They exist in the proportions of human beings, the growth patterns of plants, animals, and insects, and structures like Stonehenge and the Parthenon.

Golden section proportions are also present in Greek art, writing, and architecture, and in the spiral shape of shells.

Whether we’ve been genetically programmed to like them or we find them pleasing due to all the examples around us, the golden section has clearly been a part of nature and human creation throughout history.

We have a preference toward objects that use golden proportions.

What is the Golden Ratio?

The golden ratio is one where the ratio of the smaller segment to the larger segment is the same as the larger segment to the sum of both segments. This is more easily seen in a simple diagram.

The golden ratio or divine proportion is a visual representation of the golden number Phi (Φ) which is approximately 1.618.

The Fibonacci Sequence

The mathematics behind the golden ratio is heavily connected to the Fibonacci Sequence. If you’re unfamiliar with the fibonacci sequence, it begins by definition with the numbers 0, 1 and then each successive number in the sequence is the sum of the previous two numbers.

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55…

I’ll spare you the deep mathematics talk (we’ll just do a bit of division), since what we’re mainly interested in is how the sequence relates to the golden section.

If you take any number in the sequence and divide it by the previous number the result approximates Phi or the golden ratio.

With early numbers in the sequence this may not appear to be true, but as we continue along the sequence the division approaches 1.618 rather quickly.

• 2/1 = 2.0
• 3/2 = 1.5
• 5/3 = 1.67
• 8/5 = 1.6
• 13/8 = 1.625
• 21/13 = 1.615
• 34/21 = 1.619
• 55/34 = 1.6176

As you might expect the Fibonacci sequence is also found in art and nature. Some have argued that Virgil used the sequence in the poetry of the Aenid. It’s found in the musical compositions of Mozart.

Vitruvious, da Vinci, and Durer used it to create divine proportions of man.

The ratio of the numbers 13/8 are found in pine cone spirals and the ratio of numbers 34/21 are found in the spiral of a sunflower.

Many biological growth patterns approach the golden section instead of being exact in the same way the Fibonacci Sequence approaches the golden section ratio.

Golden Section Shapes

When people think of shapes with golden section ratios they typically think of a golden rectangle where one side divided by the other is 1.618. However, a variety of mathematics can be applied to different layouts and a variety of shapes can be constructed from golden section proportions.

You can create golden rectangles, triangles, ellipses, pentagrams, and spirals. Think outside the box or in this case outside the golden rectangle. Click the image above to see how some golden shapes can be constructed.

How to Use the Golden Section in Design

Hopefully some of the above has convinced you of the aesthetic qualities of golden section proportions. Now how do you actually apply these principles in your design and when might you use them?

The first use of the golden section is when creating a grid for your design. Let’s consider a simple case of a two column layout with a fixed width of 960px. This is a rather standard layout and width.

• 960 px / 1.618 = 593 px
• 960 px – 593 px = 367 px

From the above our content column would be 593 px and our sidebar would be 367 px. An even better approach if we’d like our design to be fluid would be to use % or em as a measurement.

If we stick with 960 px for the overall width of our layout and assume a default font size of 16px then:

• 960px / 16px = 60em (total width)
• 60 * 61.8% = 37 em (larger section)
• 60em – 37 em = 23 em (smaller section)

• 60 / 37 = 1.62
• 37 / 23 = 1.61

Not exactly Phi, but very close.

Mark Boulton has an excellent post running you through constructing an adaptive gird this way as well as providing the css to make it happen. Mark links to a simple demo in his article and you can see a more realistic demo here.

The above is all about dividing your page horizontally using the golden ratio. Dividing the page vertically is another matter.

In print design you can control both the height and width of the page. In web design the height of the page tends to vary based on the content. You could set an absolute height if you want, though it’s generally not practical.

Where it might be more appropriate to use the golden section in web design is to create buttons using golden section proportions or look to different sections of your page and see if a golden ratio will work when deciding what size they should be.

For example on many home pages the main content will leave out the second column and create a single column for the one page. Your content area could use a height of 593 px (assuming a 960 px width layout) and become a golden section rectangle.

Other shapes you add to your design (ellipses, triangles) could be constructed as golden section shapes. You could use the golden ratio when setting width and height of any images you include in your design.

Essentially any place where the dimensions of an element will be fixed a golden shape can be created.

Below are links to resources and tutorials to help you build golden section grids:

• Illustrator: Golden Section
• Grid Templates from The Grid System
• PSD Template for the Golden Grid
• Golden Section plugin for various image editing programs
• O rule + golden proportion for calculating the gutter in the grid
• Golden Grid system generator

Another interesting application for the golden section is in setting up a typographic scale. Tim Brown recently described how he set up a modular scale based on the golden ratio in a recent post for A List Apart titled More Meaningful Typography.

The Rule of Thirds: A Simplified Golden Section

Consider again the Fibonacci sequence, particularly the early numbers in the series. Using the numbers 2 and 3 from the series we get a simple approximation of the golden section as 1.667. (2/3), which leads us to the rule of thirds.

A 2-column website could make use of this rule of thirds to have a content area 2/3 the width of the whole and a sidebar 1/3 the width. It’s similar to what we did above without all the math.

The rule of thirds is often applied to images in order to create more interest. By dividing an image into thirds both horizontally and vertically you create a grid of 9 rectangles.

You want to align important elements of the image around the central rectangle, ideally at any of the 4 corners of that rectangle. This creates tension and adds interest and energy to your composition.

The image above is one I captured in Cooperstown, NY, just down the road from the Baseball Hall of Fame. In the original picture the lighthouse is centered horizontally and it’s hardly a great image.

I cropped it so the lighthouse aligns along the right edge of the central rectangle and the horizon aligns along the bottom edge of the same rectangle. The cropped image while, still not one that will win any awards is much stronger than the original.

Mouse over the image to see the “rule of thirds” grid.

Again with web design we might not be able to do this for our entire layout, since our height is likely a variable. However the rule of thirds can be particularly effective when used to crop images for maximum impact.

You could also use the rule of thirds for placing elements within a fixed dimension section of your layout such as the single column home page layout described above.

Summary

Phi (φ), the Fibonacci sequence, and the golden ratio are seen again and again in nature as well as in art, architecture, music, and design.

Whether we’re genetically predisposed to find golden proportions aesthetically pleasing or we’ve simply trained ourselves over history to find it so, there’s no denying golden sections show up again and again in nature and many man-made structures.

The next time you’re considering a grid for a website design think about the golden section and how you might use it. You don’t want to arbitrarily force golden proportions into your design, however they can make for pleasing proportions.

Consider using them for geometrical and organic constructions, particularly those involving rhythm and harmony among multiple elements.

Your visitors may not know why they find your site attractive, but they will likely respond favorably to golden section proportions in your design.

Go to Source

If you prefer to skip the explanation and get right to the code you can view the source of the demo. Note that I’ve added some extra css just to make the demo more presentable.

The HTML

The html for this layout is rather simple as you can see below.

<div id="container">
	<div id="header">
		header content here
	</div>
	<div id="content">
		main content here
	</div>
	<div id="sidebar">
		sidebar content here
	</div>
	<div id="footer">
		footer content here
	</div>
</div>

We have a single div for each of the 4 main areas of the layout — header, content, sidebar, and footer. All four divs are wrapped inside a container div, which we’ll use to center and set the width of the page.

One thing to note is the structure of the html above follows the structure of the page itself. The header comes first in both and the footer comes last. The content area div is before the sidebar.

Later in this post I’ll offer two ways to change the layout above so the sidebar is to the left of the content. One of those ways is as simple as changing a single word in the css.

The CSS

If you’ve already viewed the source code of the demo you’ll note the css like the html is rather simple. In fact most of that css has been added solely to make the demo a little more presentable.

Here’s all the css you need for this layout minus the stuff to make the demo more presentable.

#container {
	width:960px;
	margin:20px auto;
}
#content {
	float:left;
	width:620px;
}
#sidebar {
	float:left;
	width:340px;
}
#footer {
	clear:both;
}

If you combine this css with the html above you’ll have a 2 column layout that’s 960px wide. Let’s walk through the css one div at a time.

#container — We’re using the container div so we can set the overall width of the layout (960px) and then center the layout on the page.

The 20px top and bottom margin is arbitrary. I added it to give the demo a little room to breathe. The magic is done by setting auto on the left and right margins, which when combined with an explicit width, centers the layout on the page

Some people prefer not to use a container div and instead use the body tag as the container. I like using a separate container div, but either will work. If you’d rather not include the container div just remove it from the html above and move the css I show here from #container to body.

#header — No css is needed for the header div. By default its width will be 100% of it’s container and by default it will position itself as far to the top and left as it can.

These defaults are exactly what we want so there’s no need to add more. A big part of understanding css layouts is realizing you often don’t need to do anything.

#content — The important css is the float: left. It isn’t needed to have the browser render the div where we want, however floating the content is necessary to have the sidebar div sit next to it.

The width is arbitrary. You can set it to be anything you want as long as the sum of the content and sidebar widths is less than or equal to the width of the container div.

#sidebar — Like the container, the sidebar is floated left, which is typically how I code this layout in practice. You could also float the sidebar to the right. Which you use is personal preference.

I’m unaware of any advantage or disadvantage to either approach. I usually float both to the left, though it’s simply because that’s how I first did it and now it’s become habit.

As with the content div the width here is arbitrary, except as noted above.

#footer — All we need to do with the footer is clear the two floated divs to ensure it sits below them. Since both content and sidebar were floated to the left we could have used clear: left instead of clear: both, but using clear: both is more flexible as we’ll see below.

Like the header the width of the footer will be 100% of the container which is what we want.

The rest of the css I’ve used in the demo is simply to make it more presentable.

Floated Elements

If you don’t have experience using floats you may be wondering why the above works. It’s a little much to explain in a few short sentences so I’ll direct you to a couple of others posts I’ve written in a moment.

The gist is that every element in an html document is defined by a rectangular box. There are two types of boxes, block and inline.

Divs are block level boxes, which are laid out vertically in the normal document flow. The box carves out a space forcing the next box to sit below it.

Floated elements are removed from the normal document flow and shifted as far left or right as possible. Other elements are allowed to flow around or next to them.

By floating both our content and sidebar divs above we break them out of the normal document flow and allow them to sit next to each other.

By clearing the footer div we get it to behave as though the the two floated divs are in the normal document flow and so the footer drops below them.

I realize that’s not much of an explanation. For a more in depth explanation of the css box model and floated elements you can read the 2 posts below.

• CSS Box Model: The Foundation For Improving Your CSS
• Understanding CSS Floats

Changing the Position of the Content and Sidebar

I mentioned above there were 2 ways to change this layout so the sidebar is on the left of the content instead of the right. Both are very simple to implement

The first is to change the order of the divs in the html. The sidebar being first will float to the left edge of the browser and the content will float as far to the left as it can go, which is against the right edge of the sidebar.

When I know in advance I want the sidebar to be on the left I generally place it first in the html.

The second way is even easier. Just float the content div to the right instead of to the left.

 #content {float: right}

This is why we cleared our footer on both sides instead of just the left.

The above css shows off the power and flexibility of css layouts. By changing a single word in a single css file we can move columns from one side of our layout to the other. We’ll see the full power of this with the code for a 3 column layout I’ll share next week.

It’s not something you’ll do often, but think about how much time and effort it would take to move columns around with a table-based layout.

Equal Height Columns

I should point out that this layout doesn’t automatically create columns of equal height. The demo makes it appear like it does, but that’s only because I set the height of the content and sidebar to be the same to make the presentation nicer visually.

The height of each of the 4 main divs will will expand and contract based on what’s inside and most of the time that means they won’t have the same height.

Creating equal height columns is a bit trickier, though possible, and there are several methods for making it happen. I’ll save those for another post.

Summary

I hope you can see how easy it is to set up a 2 column fixed width layout. There’s really very little html and css needed. An important part of css layouts is understanding you need less css than you think.

The key to this layout is floating the 2 divs we want to sit next to each other and then clearing the first div that comes after them, which in our case is the footer.

From here it’s all about filling up each of the 4 main divs with content, though that will be specific to your project.

One thing I would suggest is taking this code and play around with it. Reorder the divs, remove a float, change a float from left to right, and try clearing the footer to the left or right only and see what happens.

You have 4 blocks to play with and a few simple lines of html and css to move them around. The more you play, the better you’ll understand how and why this all works and the easier it will be for you to create more complex layouts like the 3 column layout I’ll offer next week.

Have fun.

Go to Source

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away
— Antoine de Saint-Exupery French writer (1900–1944)

Minimalism is a word I’m sure you’ve heard before. It often gets thrown around on design blogs though sometimes carelessly as though the term just means to put less on the page.

In fairness minimalism can be a hard concept to wrap your mind around and it probably means different things to different people.

I want to explain why I think all web designers would do best to master minimalist design before any other style.

What is Minimalism?

I suppose we should start by trying to define minimalism. Here are 2 definitions I found online.

• Movements in various forms of art and design, especially visual art and music, where the work is stripped down to its most fundamental features.
• Simplicity of style in artwork, design, interior design, or literature, achieved by using the fewest and barest essentials or elements to maximum effect

Minimalism has also been called ABC art, reductivism, and rejective art and its theories have been applied to lifestyle.

Minimalism aims for simplicity and objectivity. It wants to reduce works to the fundamental, the essential, the necessary, and to strip away the ornamental layers that might be placed on top.

Minimalist designs tend toward more whitespace, better typography, grid layouts, and less color.

Mies van der Rohe famously said “Less is more” to describe his aesthetic sense of having every element serve multiple purposes both visually and functionally.

Buckminster Fuller later reworked the phrase to “doing more with less” and Dieter Rams changed it to “Less but better.”

All three are saying the same thing. Minimalism is about designing smarter.

Why You Should Master Minimalism First

If minimalism is about designing smarter, doing more with less, and reducing design to the fundamentals, it relies on getting basic design principles right.

You’re working with less so you need to be able to use the tools you have better. You need a solid grasp of:

• Grids
• Typography
• Space
• Color
• Basic design elements

While simplicity is used to define minimalism, it’s anything but simple to create a good minimalist design. To master minimalist design means to master design. It’s harder to pull off because you can’t hide behind ornament and decoration.

All minimalist designs should not and do not look alike. Minimalism does not mean take everything away until only black text on a white background remains. It means communicating as much as possible with as few elements as possible.

It strikes me that instead of a design being minimalist or not minimalist, it’s more a case of to what degree does the design embrace minimalism. We can strive toward it, but even the most minimalist design could be reduced further.

None of this should be taken to mean that every design should end up being minimalist. Different design styles set different moods and invoke different emotions in your audience.

Once you’ve mastered the fundamentals you can add meaningful aesthetics on top. Ornamentation works when it has a solid foundation to sit on.

Stylistic details won’t save a design that fails to execute the fundamentals.

Summary

Minimalism is reducing your work to the essential and using less to do more. In order to do minimalism well you need a strong understanding of basic design principles. When you master minimalism you master design.

I’ll leave you with a few quotes to hopefully drive the point home.

Everything should be made as simple as possible, but not simpler.
— Albert Einstein

The secret of happiness, you see, is not found in seeking more, but in developing the capacity to enjoy less.
— Socrates

Omit needless words
— William Strunk Jr. The Elements of Style

Go to Source

Via Daring Fireball I was pointed to this post, which pulls a brief quote from the video below on storytelling by Ira Glass.

While Ira is mainly talking about stories, there’s some great advice for all creatives.

Many people who go into some form of creative work do so in part because they have good taste. You’re able to judge quality in the creative discipline(s) you choose to pursue.

Unfortunately early on there’s a gap between what you know to be good and what your skills allow you to create. When you look at your finished work you know it isn’t good. It tries to be good and has potential to be good, but it’s lacking something that truly makes it good.

What’s happening is your taste and ability to judge quality is ahead of your skills to create quality, which opens a gap leading to disappointment in your own work.

Most all creative people go through years of this gap where taste is more developed than skill. Unfortunately many quit before they reach the point where skills catch up to taste.

The best thing you can do to close the gap is a lot of work. Keep doing more projects. Create as much as you can to gain the experience you need. As you create more work you’ll inevitably close the gap. Your skill will catch up with your taste if you keep at it.

Using the Gap to Improve

The video resonates with me for a couple of reasons. First I know I’m still in the phase where I need to close the gap. It hasn’t been all that long that I’ve been designing websites. I’ve been developing them for awhile, but only designing sites for a few years.

I don’t think I’ve yet to create a design that had the something special I was looking for. I’ve gotten close a few times, but never quite there.

Second I think there’s more to the story. The gap is more than one between taste and skill. It exists between theory and practice.

Both theory and practice are important parts of learning. At any point in our careers we can open the gap by taking in more theory. We learn design principles. We study how to communicate visually to greater effect.

More practice then closes the gap again. Theory expands what you’re capable of achieving and practice actually achieves it.

Practice alone won’t take you past theory. No matter how much you practice you aren’t going to create a gap where skill outstrips knowledge.

To continue improving we need to consistently open and close the gap.

• Open gap — Initial development of taste and sense of quality
• Close gap — Practice until you can create quality that matches taste
• Open gap — Learn more theory
• Close gap — Apply theory you learned in practice
• Open gap — Learn more theory
• Close gap — Apply theory you learned in practice

and on and on.

Ideally you’ll always be both learning new theory and practicing the theory you’ve learned so the gaps you ultimately open and close don’t need to be very large. In fact you may never notice them once you’ve reached a certain point.

Opening the gap sets the new baseline you can reach. Closing the gap reaches the baseline.

I haven’t closed the initial gap where my design skills have caught up to the taste I’ve developed throughout life, though I think I’m getting close. I have closed that gap in other creative areas, but not yet where design is concerned.

I’ll continue to close and open the gap between theory and skills as a web designer and hope you will too.

Additional Resources

The video at the top of this post is actually part 3 of a 4 part series. All 4 videos are worth watching and each is under 10 minutes. Here are links to all 4 in case you’d like to watch.

• Ira Glass on Storytelling: Part 1
• Ira Glass on Storytelling: Part 2
• Ira Glass on Storytelling: Part 3 (the video above)
• Ira Glass on Storytelling: Part 4

Go to Source

• Mental model— how users think a system will work
• Conceptual model—how designers develop a system to work
• Interaction model—how people actually interact with a system

Mental Models

A mental model represents a persons thought process for how something works. It’s built through past experiences, incomplete facts, intuition, and the general understanding of how we think the world around us works.

We all use mental models to predict how systems work. They set a context that helps shape our behavior and actions with the system and they influence our visual perception by suggesting where we should look and what we pay attention to.

For example if you sit inside a car you have a mental model about how that car should work.

You expect to find an ignition, which you’ll likely turn on with a key. You expect a steering wheel that you’ll turn clockwise or counter-clockwise to turn the car right or left. You expect to find gas and brake pedals as well as many other things common to most cars.

Even though you’ve never been in that particular car it shouldn’t take you more than few seconds to figure out how to turn it on and drive it. You have a mental model for a car, which is easily transferred from one car to another.

Mental models are fluid. We create them quickly and modify them as new information comes in. We base them on

• Prior experiences
• Assumptions
• Observations

The first 2 allow us to form models quickly and the last allows us to modify them.

The main thing to understand is that we form mental models to help us make sense of world and interact with unfamiliar things. Our mental models influence our perceptions and our perceptions influence our mental models.

Conceptual Models

A conceptual model represents how something is designed to work. It’s the mental model of the designer put into action.

Consider again a car. There’s no reason we need to turn a key to start the ignition. A designer’s conceptual model of a car could suggest that a push button ignition and joystick controls are better ways to operate the car.

Push button and joystick break our mental model of a car. We do have mental models for what to do with buttons and joysticks in general and we can use them to figure out how to turn on and drive the cr.

Still it’s easy to see how some or even many would have trouble operating the push button and joystick car, because conceptual model and mental model disagree.

Every design decision creates either agreement or disagreement between mental model and conceptual model.

• Disagreement—leads to a system that’s harder to learn. It will typically create user frustration, more errors, and be less usable when first encoutnered.
• Agreement—leads to system that’s easier to learn. It will typically be highly usable and create less error and user frustration when first encountered. It will like be seen as more intuitive.

When mental and conceptual models agree little explanation is needed to use the system. When the models disagree an explanation is sometimes necessary.

Designing for Disagreement

While agreement makes a system easier to learn, it may not always be desired. Consider touch screen devices. When touch interfaces first appeared they broke the mental model for interacting with a computer.

Users typed using software instead of hardware. They swiped, tapped, and pinched without a mouse. While new and not part of anyone’s mental model at the time, all are still pretty easy to learn.

A good conceptual model allows people to predict the effects of an action. We expect to pull on a door handle. We assume things will move in the direction we swipe. A good conceptual model reveals itself through its interface.

2 principles we can use to help users predict how our designs work:

• Affordance—The physical characteristics of a design element suggest how to use it. A door handle suggests pulling. A door knob suggests turning. A button suggests pushing.
• Mapping—The relationship between design controls, their movements, and their effects on the element(s) they control. Moving a joystick to the left should result in something moving left.

We can also build in constraints to help prevent errors and generally build a forgiving design in order to encourage exploration.

Designing for Agreement

When developing a conceptual model we naturally consider our own mental model for how something should work, but as we’re designing for an audience we want to also consider the mental models they’ll likely bring to our design.

Usually we have different groups of people in our audience, each with different mental models. For example beginner, intermediate, and advanced users.

Someone very familiar with your subject or object is going to bring a very different mental model than a complete beginner. Mental models are also based on:

• goals
• motivation
• culture

We can use personas to see potential mental models for our audience and then design accordingly. We can also try usability testing and simple observation of people using our designs while we’re developing them.

Interaction Models

Interaction models are how people actually interact with a system. Communication between mental model and conceptual model occurs through the interface of the system.

Designers have complete and accurate conceptual models However designers have weak interaction models early on as we don’t know in advance how people expect our designs to function. We can use personas, etc. to predict mental models, but we won’t really know them.

Users start with an interaction model based on their mental model and then refine that model based on actual use. Through experience users can gain a complete and accurate interaction model.

A system’s interaction model could be completely different from either mental model or conceptual model, though in time users come to understand the interaction model through experience.

Optimal design occurs when we create an interface where interaction model and conceptual model meet. To do this we want to

• Use the system—To understand how a design works in practice we need to become a user of the design. However as designers we need to be aware that we aren’t typical users as we created the conceptual model. Using our own designs won’t always reveal problems in the interaction model.
• Observe others using the system—By watching others we again gain information about how our designs are used in practice. The advantage here is that we get to see how people unfamiliar with our conceptual model use our designs.

Designing with Conventions

Since an interaction model will begin as a user’s mental model, we can take advantage of standard mental models through design conventions.

Nothing says a link on a web page needs to be blue and underlined, but by making it blue and underlined we align conceptual, mental, and interaction models.

It’s a good idea to use conventions where possible because of this agreement between the 3 models.

However don’t force design into convention just to take advantage of the model. It’s better to have people learn to form a new mental model than require they use a mental model that doesn’t really fit the design.

Swiping pages on a touch device could have instead been a horizontal scroll bar that we tap, hold, and move, but aren’t you glad designers opted not to keep this model?

Contrast and Similarity

Consider the simple web page text link. The expectation (mental model) is clicking a link takes you to a new page. That’s at least the predominant model for a link.

The first time a link opened a new window or took you to a new place on the same page or triggered an ajax request it broke that predominant mental model.

Each of these different types of links is useful, but because they are different they should be designed differently to indicate in advance their different behavior.

Perhaps a different color for links that make ajax requests or an icon when a new window will open. The first time someone clicks those links they may still expect the default going to a new page, but by their second or third click they will have learned the different behavior.

The subtle change builds a new mental model and creates a new convention and trains our audience to use our design.

At the same time all these links share some characteristics. The standard link, new window link, and same page link all take you to a new location.

It makes sense therefore that each share some design characteristics. Maybe all 3 use a cool color and remain underlined.

Using contrast and similarity this way we can help people understand our conceptual models. Contrast with convention where there is disagreement in models and similarity with convention when there is agreement.

Summary

We all build mental models to help us predict how unfamiliar systems will work. We build them based on experience using similar systems, assumptions based on general knowledge, and observations of the new system.

Designers use their mental models to build things. Our mental model becomes the conceptual model of the thing we build.

When people use our designs they build an interaction model for how the design actually works. Over time they can develop an accurate and complete interaction model through experience with the system.

When conceptual model and mental model agree our designs are intuitive to use. When the models disagree the design needs to be learned.

We should do our best to understand the likely mental models our audience will bring to our designs. Where possible we should take advantage of conventional design patterns to indicate the model is correct. Where the model needs to be altered we should indicate that as well, by diverging from convention.

Go to Source

• Mental model— how users think a system will work
• Conceptual model—how designers develop a system to work
• Interaction model—how people actually interact with a system

Mental Models

A mental model represents a persons thought process for how something works. It’s built through past experiences, incomplete facts, intuition, and the general understanding of how we think the world around us works.

We all use mental models to predict how systems work. They set a context that helps shape our behavior and actions with the system and they influence our visual perception by suggesting where we should look and what we pay attention to.

For example if you sit inside a car you have a mental model about how that car should work.

You expect to find an ignition, which you’ll likely turn on with a key. You expect a steering wheel that you’ll turn clockwise or counter-clockwise to turn the car right or left. You expect to find gas and brake pedals as well as many other things common to most cars.

Even though you’ve never been in that particular car it shouldn’t take you more than few seconds to figure out how to turn it on and drive it. You have a mental model for a car, which is easily transferred from one car to another.

Mental models are fluid. We create them quickly and modify them as new information comes in. We base them on

• Prior experiences
• Assumptions
• Observations

The first 2 allow us to form models quickly and the last allows us to modify them.

The main thing to understand is that we form mental models to help us make sense of world and interact with unfamiliar things. Our mental models influence our perceptions and our perceptions influence our mental models.

Conceptual Models

A conceptual model represents how something is designed to work. It’s the mental model of the designer put into action.

Consider again a car. There’s no reason we need to turn a key to start the ignition. A designer’s conceptual model of a car could suggest that a push button ignition and joystick controls are better ways to operate the car.

Push button and joystick break our mental model of a car. We do have mental models for what to do with buttons and joysticks in general and we can use them to figure out how to turn on and drive the cr.

Still it’s easy to see how some or even many would have trouble operating the push button and joystick car, because conceptual model and mental model disagree.

Every design decision creates either agreement or disagreement between mental model and conceptual model.

• Disagreement—leads to a system that’s harder to learn. It will typically create user frustration, more errors, and be less usable when first encoutnered.
• Agreement—leads to system that’s easier to learn. It will typically be highly usable and create less error and user frustration when first encountered. It will like be seen as more intuitive.

When mental and conceptual models agree little explanation is needed to use the system. When the models disagree an explanation is sometimes necessary.

Designing for Disagreement

While agreement makes a system easier to learn, it may not always be desired. Consider touch screen devices. When touch interfaces first appeared they broke the mental model for interacting with a computer.

Users typed using software instead of hardware. They swiped, tapped, and pinched without a mouse. While new and not part of anyone’s mental model at the time, all are still pretty easy to learn.

A good conceptual model allows people to predict the effects of an action. We expect to pull on a door handle. We assume things will move in the direction we swipe. A good conceptual model reveals itself through its interface.

2 principles we can use to help users predict how our designs work:

• Affordance—The physical characteristics of a design element suggest how to use it. A door handle suggests pulling. A door knob suggests turning. A button suggests pushing.
• Mapping—The relationship between design controls, their movements, and their effects on the element(s) they control. Moving a joystick to the left should result in something moving left.

We can also build in constraints to help prevent errors and generally build a forgiving design in order to encourage exploration.

Designing for Agreement

When developing a conceptual model we naturally consider our own mental model for how something should work, but as we’re designing for an audience we want to also consider the mental models they’ll likely bring to our design.

Usually we have different groups of people in our audience, each with different mental models. For example beginner, intermediate, and advanced users.

Someone very familiar with your subject or object is going to bring a very different mental model than a complete beginner. Mental models are also based on:

• goals
• motivation
• culture

We can use personas to see potential mental models for our audience and then design accordingly. We can also try usability testing and simple observation of people using our designs while we’re developing them.

Interaction Models

Interaction models are how people actually interact with a system. Communication between mental model and conceptual model occurs through the interface of the system.

Designers have complete and accurate conceptual models However designers have weak interaction models early on as we don’t know in advance how people expect our designs to function. We can use personas, etc. to predict mental models, but we won’t really know them.

Users start with an interaction model based on their mental model and then refine that model based on actual use. Through experience users can gain a complete and accurate interaction model.

A system’s interaction model could be completely different from either mental model or conceptual model, though in time users come to understand the interaction model through experience.

Optimal design occurs when we create an interface where interaction model and conceptual model meet. To do this we want to

• Use the system—To understand how a design works in practice we need to become a user of the design. However as designers we need to be aware that we aren’t typical users as we created the conceptual model. Using our own designs won’t always reveal problems in the interaction model.
• Observe others using the system—By watching others we again gain information about how our designs are used in practice. The advantage here is that we get to see how people unfamiliar with our conceptual model use our designs.

Designing with Conventions

Since an interaction model will begin as a user’s mental model, we can take advantage of standard mental models through design conventions.

Nothing says a link on a web page needs to be blue and underlined, but by making it blue and underlined we align conceptual, mental, and interaction models.

It’s a good idea to use conventions where possible because of this agreement between the 3 models.

However don’t force design into convention just to take advantage of the model. It’s better to have people learn to form a new mental model than require they use a mental model that doesn’t really fit the design.

Swiping pages on a touch device could have instead been a horizontal scroll bar that we tap, hold, and move, but aren’t you glad designers opted not to keep this model?

Contrast and Similarity

Consider the simple web page text link. The expectation (mental model) is clicking a link takes you to a new page. That’s at least the predominant model for a link.

The first time a link opened a new window or took you to a new place on the same page or triggered an ajax request it broke that predominant mental model.

Each of these different types of links is useful, but because they are different they should be designed differently to indicate in advance their different behavior.

Perhaps a different color for links that make ajax requests or an icon when a new window will open. The first time someone clicks those links they may still expect the default going to a new page, but by their second or third click they will have learned the different behavior.

The subtle change builds a new mental model and creates a new convention and trains our audience to use our design.

At the same time all these links share some characteristics. The standard link, new window link, and same page link all take you to a new location.

It makes sense therefore that each share some design characteristics. Maybe all 3 use a cool color and remain underlined.

Using contrast and similarity this way we can help people understand our conceptual models. Contrast with convention where there is disagreement in models and similarity with convention when there is agreement.

Summary

We all build mental models to help us predict how unfamiliar systems will work. We build them based on experience using similar systems, assumptions based on general knowledge, and observations of the new system.

Designers use their mental models to build things. Our mental model becomes the conceptual model of the thing we build.

When people use our designs they build an interaction model for how the design actually works. Over time they can develop an accurate and complete interaction model through experience with the system.

When conceptual model and mental model agree our designs are intuitive to use. When the models disagree the design needs to be learned.

We should do our best to understand the likely mental models our audience will bring to our designs. Where possible we should take advantage of conventional design patterns to indicate the model is correct. Where the model needs to be altered we should indicate that as well, by diverging from convention.

Go to Source

Last week Amber Weinberg posted why freelancers don’t really need a business plan. It’s one of the rare posts where I agree and disagree with most everything in the post. The reason for my apparent confusion is the advice really depends on how you define a business plan.

What is a Business Plan?

Both of the statements below are from the same Wikipedia article on business plans.

Business plan—A formal statement of a set of business goals, the reasons why they are believed attainable, and the plan for reaching those goals.

Business plan—A decision-making tool. There is no fixed content for a business plan. Rather the content and format of the business plan is determined by the goals and audience.

The first is closer to what many people think of (and what Amber described) as a business plan. It’s a formal document that is written with a standard format. Here’s the format used in a sample plan at bplans.com for a service oriented business.

• Executive Summary (including Mission Statement)
• Company Summary
• Services
• Market Analysis Summary
• Strategy and Implementation Summary
• Management Summary
• Financial Plan
• Appendix

About the only time you would need one of these formal plans is if you’re seeking financing for your business and even then they may not be useful. (Note the headline in the image below)

Business Planning

The second definition above is more what I think of as a business plan. It’s a tool to give our business direction. It can take on any format you want. It’s business planning as opposed to a formal plan.

Mine helps me make decisions about my business and I consider it one of the most important documents I’ve created. It’s so important that I revisit and rework it every year.

While many freelancers start by declaring themselves freelancers and then looking for clients, I think the more successful freelancers take some time to plan how their business will function and grow.

Given that design is essentially formulating a plan, you can consider business planning as designing your business.

5 Questions You Should Answer When Starting Your Freelance Business

Regardless of whether you plan or not there are some questions you should answer when starting a freelance business. A few obvious ones are:

• What services will you offer
• How much will you charge for your services
• Where are you going to find clients
• How are you going to convince clients to hire you

You ask and answer these types of questions in advance to help you make decisions when they come up in practice.

Business planning for freelancers is an individual process. Only you can truly define all of the the questions and answers you need to ask, however I think there are few essential questions you need to think about and answer if you want to be successful.

Who is Your Market?

Your market isn’t everyone who needs a website. Thinking everyone is your market is a mistake many new freelancers, myself included, make.

The thought process is usually to cast the widest net possible as a wider net means more potential clients. You are never going to appeal to everyone and even if you could you wouldn’t have the time to serve them all.

Instead you want to more tightly define who your clients are. You can define your market based on demographics. You can define it based on location, type of industry, business size of the client, the platform you’ll develop on. etc.

The better you define a market, the better you can appeal to people in that market. Your market should be large enough to offer enough potential clients, but not so large as its definitions become too general.

How Can You Reach Your Market?

Once you’ve figured out who your market is you then need to figure out how to reach them. You have to let people know you exist before they can decide to hire you.

People in a market often spend their time doing similar things. They share needs and interests. They read the same magazines or join the same social communities. They probably search for similar things and visit similar websites.

To reach your market you need to be present in the same places they’re present. Join the same communities. Ask and answer questions. Get to know the people in your market.

One of the reasons I joined and now own a small business forum is because the people who typically frequent those forums are my market. In fact I built a client list by talking to people on a single forum. My client list has since expanded, but it all started with a handful of people on one forum.

What Differentiates You from Your Competition?

It’s unlikely you are the only business serving a market. You have competition for the same potential clients. Why you? Why should people in your market choose you over another freelancer?

Getting to know people will help as people generally prefer to hire people they know. Still you need to offer your market a compelling reason to choose you over everyone else who wants their business.

This can be a difficult question to answer, especially early on. I think the answer generally comes from one of three places

• You—What specific skills do you have both related to and outside your business. Whoever you are, you’re unique and have something to offer that your competition doesn’t.
• Your competition—If you spend some time studying your competition you can find things they aren’t doing or doing well. You can differentiate yourself by filling the gaps your competition isn’t serving.
• Your market—If you listen to your market you’ll hear them telling you what they want. They’ll tell you the problems they need solving. Be the person that solves those problems.

The main thing is to answer the question “why you?” If you don’t know, don’t expect that clients will either.

How WIll You Position Your business to Promote “Why You?”

Once you know how you’ll differentiate yourself from the competition you need to decide how you’ll get those differences across to your market. Will your advertising and general marketing convey why you’re the right choice?

What tangible benefits can you offer your market? Are you giving your market the features it wants? What compelling offer are you making to potential clients. What story are you going to tell?

This question is all about the specifics of how you’ll get across your differentiation and how you’ll be consistent in getting it across. This question is about building your brand and how you’ll turn it into the valuable asset it should be.

How WIll Your Business Generate Revenue?

The obvious answer is you’ll charge for services. By definition a freelancer sells services. However, there are a variety of ways you can generate revenue at the start or as you grow.

You can sell products you create like themes or plugins. You can advertise or sell affiliate products. You can create informational content with a price.

Even if you limit yourself to services, questions such as how much should you charge immediately require answers. A mistake I see many make is to try to charge less than the competition and use price as a differentiator.

Large businesses can do well competing on price. Freelancers will do better to differentiate on value. Price your services based on the value you offer to clients. I find this easiest to do when you’ve already asked and answered the 4 questions above.

Remember too that you’ll be paying for things like health insurance and a new computer when necessary. You have to account for all these costs when pricing your services.

How I Plan My Business

My business planning is about as informal as can be. I open a simple text file and I start typing.

Free writing, jotting down random thoughts, sketching something on paper, creating mind maps. All I’m trying to do is dump anything in my brain and record it somewhere.

I use the questions above as a guide, though I often meander my way to answers. I think about smaller details and larger concepts in no particular order.

Typically I’ll spend a few nights or a week thinking and writing all with the goal of answering the 5 questions above. I’ll flesh out notes, remove ideas that don’t fit, and generate new thoughts as the week progresses. After a few days I usually have the workings of a plan.

I tend not to revisit a plan after it’s written. The act of thinking and writing is enough for what I need the plan to do. Toward the end of each year I spend about a week going through the process again in order to plan how I want my business to grow in the coming year. Parts of my plan stay consistent from year to year and parts change.

For me the plan is all about getting me to think about the direction I want my business to go. It’s amazing how much more focused my business will be with even just a few hours of thinking about it over the course of a few days.

Summary

Is a business plan necessary for freelancers? It really depends on what you mean by a business plan.

Freelancers don’t need to create a formal plan. Those are created to convince banks to give you a loan. Freelancers will greatly benefit from planning their business, though.

It’s up to you the form your plan takes, but I think answering the 5 questions in this post is a good approach. You might even reduce all 5 questions to 2 general categories of thinking about your market and thinking about your brand.

Do you or did you plan a direction for your business? If so how often do you revisit your plan? Have you found business planning helpful or a waste of time?

Go to Source

The video is 5 minutes long and I think worth watching. It isn’t specifically about design as body language, though it’s still good. Heather even mentions the idea of designing with an inverted pyramid, something I talked about not too long ago.

What is Body Language?

Body language is a form of non-verbal communication. How we hold our posture or a facial expression we make, communicates a lot of information.

Many would suggest that the majority of communication between people meeting face-to-face is done non-verbally through body language. Aware of it or not we do react to body language even in robots.

This communication is usually sent and received subconsciously. Most people aren’t leaning one way or another or crossing and uncrossing their arms as a way to consciously communicate. In many ways body language is a window into what you’re thinking.

The non-verbal communication of body language sets the context for verbal communication. It builds the frame within which we interpret the verbal.

For example say an old friend you meet on the street says she’ll give you a call. If she gives you a hug while saying it, you probably believe she’ll call. If she says it as she’s quickly hurrying away, the likely interpretation is that you aren’t going to hear from her.

Body language isn’t always obvious to interpet.

• Crossing arms—Could be indicating a self defensive posture by putting up a barrier. It could also be a sign someone is cold.
• Maintaining eye contact—Could mean a person is attentive. It could also mean the person mistrusts you and is carefully watching

Body language supports the tone of what’s being said. This is especially true when conveying feeling and emotion.

We communicate better when all forms of communication support each other as opposed to working against each other. When speech and body language lack harmony we send mixed signals and confuse the message.

Much of non-verbal communication ultimately happens through a combination of signals. Those who understand body language can use it to their advantage including improving how much they sell.

Additional Resources

Below are a few articles I found while seaching. The first two offer some examples of body language gestures and the potential meanings of those gestures. The latter two are more in-depth articles on body language.

There’s plenty of information about body language to be found, though beware much of it will revolve around picking up members of the opposite sex.

• Examples Of Body Language
• Reading Body Language: Examples of Body Language
• How to Read Body Language Signs and Gestures
• How to Read Body Language

Kinesics

The study of body movements, gestures, and facial expressions as a means of communication is called kinesics. More generally it’s the interpretation of non-verbal behavior related to movement as it pertains to communication.

There are 5 different types of kinesics.

• Emblems—Non-verbal cues with a verbal counterpart. For example an ok sign or thumb’s up. Emblems serve as substitutes for words and phrases.
• Regulators—Non-verbal signs that regulate, modulate, and maintain the flow and pace of verbal communication. Nodding your head to indicate interest in a conversation for example.
• Illustrators—Accompany and reinforce what is being said as in pointing to an object you’re talking about.
• Affective display—Body and facial movements indicating emotion. Smiles and frowns for an easy example. A lack of affective display may be incorrectly interpreted as a lack of emotion.
• Adaptors —Typically movements at a low level of awareness made to release physical or emotional tension or perform specific task. An example might be leaning away from someone who’s just said something creepy or frightenting..

Because adaptors occur at such a low level of awareness some see them as key to understanding what someone is thinking.

However because they also occur to perform specific tasks or relieve physical tension they may not carry any more significant meaning than the other types of kinesics.

Design as Body Language

Now that we’ve briefly looked at body language let’s think about design and see how the metaphor fits.

Like body language design sets the context or frame for your content. Like body language communication through design often occurs subconsciously.

For example if your content is set on a grid it will communicate organization. Your audience will find it easier to read and find what they want and they’ll take those things away with them.

Nowhere though, do you need to explicitly say your content is easy to read and find. A visitor simply finds the design easy to use.

We can look at content as the verbal communication that happens and look at design as the non-verbal communication that happens.

Much the same way people don’t consciously notice body language we don’t always notice design. We’re probably more apt to notice either when unnatural or done poorly.

Both body language and visual design stand out more when they conflict with what’s being communicated verbally. When design displays unity with the verbal it communicates effectively by supporting and enhancing the verbal message.

When design lacks harmony it sends a mixed message, confusing the communication.

Kinesics and Design

Let’s revisit the 5 types of kinesics and see if we can connect them to design.

• Emblems—Icons are an obvious example. Using commonly understood conventions might also fit here.
• Regulators—Space, flow, alignment, proximity, and visual hierarchy all seem to fit here. Most design principles can likely be seen as regulators.
• Illustrators—The use of arrows, pointing cues, eye gaze in facial images are typically reinforcing non-verbal and verbal. Lines connecting different elements reinforce their connection.
• Affective display—Design style, textures, color are all ways we try to convey emotion through design. The use of anthropomorphic forms would be another. Any part of a design that sets a mood or frames the context of the content likely falls under affective display.
• Adaptors—Usability, accessibility, and affordance would likely fit as adaptors. So would the use of a grid to organize information. Anything that makes a design easier to use or interact with is a good candidate.

The above is just a quick interpretation on my part and shouldn’t be seen as set in stone. For example something like flow might be considered regulator, illustrator, or adaptor, depending on how it’s being used. If you have better examples please do share.

The main thing to take away is that it’s not too hard to see different aspects of design in similar ways as we see body language. The metaphor works and because it works so well a study of body language might benefit visual designers.