Looking for the lessons? Get started!
Some of the fundamental principles behind the page layout.
The entire Web Design Principles section can be accessed through the menu below.
Unfortunately, not everyone's browser will support the spiffy JavaScript menu behind that innocent-looking button. If your browser won't display the menu, just click on the button and you'll be taken to a separate page with the entire menu displayed in clear, non-JavaScript HTML.
The experienced web designer, like the talented newspaper art director, accepts that many projects she works on will have headings and columns and footers. Her job is not to whine about emerging commonalities but to use them to create pages that are distinctive, natural, brand-appropriate, subtly memorable, and quietly but unmistakably engaging. If she achieves all that and sweats the details, her work will be beautiful. If not everyone appreciates this beauty — if not everyone understands web design — then let us not cry for web design, but for those who cannot see. — Jeffrey Zeldman
There are a blue million ways to lay out a Web site, from extremely simple to incredibly complex. If you search Google with the terms "CSS layout," you'll see what I mean. But before we go forward, let's take a look at what designers used to do in the wild, wooly, and semantically inaccurate days of yore.
Layout Fundamentals
As we noted in the Design of Web Design page, in a vast majority of Web sites, content is what drives a Web site and content must be served first and foremost. Cribbing from Craig Grannell's excellent primer on CSS and HTML, you should keep six fundamental principles in mind:
- Is the site easy to navigate?
- Is it easy for users to locate content on each page?
- It it easy for users to find what they need on the site?
- Are download times kept to a minimum? (Grannell is referring to, among other things, large graphic files, multiple JavaScript files, and anything that causes the site to be slow to load.)
- Is the site suitable and relevant for its target audience?
- Does the site use familiar conventions?
The last one is an interesting point. "Web conventions" are, basically, the way many sites have done things in the past, i.e. navigation links stretching horizontally near the top or vertically down the left side, links being either blue or purple, links being underlined, etc. Grannell warns designers not to mistake "conventions" for "inflexible rules". For example, about links, he writes:
As long as links are easy to differentiate from other text and styled consistently throughout the site, that's what matters.
Web designer and marketing guru Tim Priebe notes that site layouts should be driven by their content. He writes:
A good web site has several sections with plenty of information.
A better web site has just enough sections and pages without overwhelming the visitor with too much information.
Basic Structural Elements
At its most basic, an HTML page contains a few critical elements:
- DOCTYPE
- root element
- head
- meta data
- title
- body
Sounds complicated, doesn't it? It isn't as bad as it seems. Here's a fundamentally simple HTML template, based on one I use in everyday coding. The elements have been labeled (so if you use this for your own, don't include the orange labels!).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> DOCTYPE <html lang="en"> root element <head> head <meta http-equiv="Content-Type" content="text/html;charset=utf-8"> meta data <title></title> title </head> <body> body </body> </html>
More about the various elements:
Root elements enclose all other elements in an HTML page. They also set the language of the page ("en" for "English" in this case).
The head of the HTML page contains "header" information: the title of the page, the meta tags, stylesheet information, and JavaScript, among other goodies.
The title element is required as of HTML 4.01. It can only contain ASCII characters — letters, numbers, and basic punctuation. Special characters, or character entities, can be included as well. The title is what is displayed in the user's bookmarks or Favorites list, and is often (not always) displayed by search engines. They are also the first thing a screen reader announces, so they are a key element of accessibility.
Lastly, the body element contains the actual content of a site. Except for the title, everything you see on your browser display is contained within the body.
My friend and colleague Alex Dawson has written an excellent article, The Anatomy of a Website, detailing the structure of a basic Web site. He uses a clever metaphor — the structure of the human body — to give a complete and well-thought out examination of site structure. Definitely worth reading.
Choosing a Layout
Web designer Kayla Knight gives us some parameters to consider before selecting a particular layout. She writes:
When designing a website layout for a large audience, the designer must consider the following potential differences among visitors:
- Screen resolution,
- Browser choice,
- Whether or not the browser is maximized,
- Extra toolbars open in the browser (History, Bookmarks, etc.),
- Even the operating system and hardware.
Sounds simple enough, but if you're coding for a general audience, you won't get specific answers for any of those situations. Screen resolutions will vary widely, users will have every browser known to man, some will insist on browsing with a maximized window while others will work from a smaller display, some will lard their browser with many extra toolbars and widgets, and users will run Windows, Mac, Linux, BeOS, you name it, someone will have it. You have to try to code for all of them…within reason.
It's impossible to say which layout is "always" the correct one. Different needs will nudge the designer to different layouts.
If you want a video introduction to the subject, check out Chris Coyier's screencast about fixed, fluid, and elastic layouts.
Fixed-Width Layouts
To understand fixed-width layouts, you have to know that the layouts are written in pixel measurements:
More about units of measuring size.
You can also learn more about the optimum widths for different monitor sizes:
More about optimum widths for different monitor sizes.
Expert Web designer Mike Cherim explains what a fixed layout is:
A fixed width site is one where the main wrapper is set to a specific immovable width independent of the user agent's display resolution. A common and considerate fixed width is 760 pixels, a size that ensures users with 800×600 resolution monitors have close to full window viewing without annoying side-scrolling.
True enough, except that Cherim wrote that page in 2007, and many designers (not all!) have now abandoned the 760px width in favor of 960px, to accomodate users with 1024x760 monitor displays.
And remember, a fixed-width layout can contain percentage- or em-based elements. Knight writes:
The important thing is that the container (wrapper) element is set to not move. No matter what screen resolution the visitor has, he or she will see the same width as other visitors.
Web developer Michael Meadhra notes that many designers prefer a fixed-width layout:
Many Web builders prefer using fixed-width page layouts for page design because they produce precise and predictable results. This approach closely mimics print layout, which is a significant comfort factor for designers and visitors alike; it's also the best way to handle content that includes lots of large images and other elements that don't flow well in a liquid layout.
He also notes the "comfort factor" in translating rigid, table-based layouts into fixed-width CSS layouts:
The formatting attributes of tables and table cells lend themselves to fixed-width layouts by making it fairly easy to specify the sizes of those elements. But you can accomplish the same thing with divs by giving divs exact dimensions and using absolute and relative positioning to place those divs on the page.
The formatting attributes of tables and table cells lend themselves to fixed-width layouts by making it fairly easy to specify the sizes of those elements. But you can accomplish the same thing with divs by giving divs exact dimensions and using absolute and relative positioning to place those divs on the page.
On the other hand, my SitePoint colleague Ralph Mason notes:
Fixed-width, pixel-based layouts are predictable but not very adaptable to changing browser conditions.
So it's not only a matter of preference, it's a matter of function. Sometimes the fixed-width layout solves more problems than it creates; sometimes not.
Fixed layouts have their widths determined by the designer. Monitor displays with a viewport smaller than the width get a horizontal scrollbar, and a portion of the site is hidden until the user scrolls to the right. Monitor displays with a viewport larger than the width get the site displayed either in the center of the screen (good designer) or on the left (lazy designer), with the remainder of the viewport unoccupied by the site. Usually the user gets "strips" of white on the left and right of the site.
Advantages of a fixed layout:
- The main content area is strictly controlled without setting
min-widthandmax-widthvalues on thebodyof the pages, which aren't correctly supported by all browsers anyway. - Many designers find fixed-width layouts easier to style; some visual designs (i.e. header images that span the entire header area) can only be implemented in a fixed design.
- The main content area of a fixed-width design is usually a good width for readability.
- Since the widths are the same in every browser (aside from smaller phone-based browsers), adding images, forms, video, and other fixed-width content is fairly straightforward.
Disadvantages of a fixed layout:
- When users enlarge the text with their browser's text-resizing capability, the "optimum readability" idea can go out the window, since the ratio of line-width to text size does not increase along with the text. This doesn't happen unless the user makes the text very large.
- Users dislike horizontal scroll bars.
- Small fixed-width displays can look too narrow on large screen displays.
- The narrow width can, in some cases, limit the number of columns and the amount of content available to the display.
Meadhra provides some excellent demonstrations and examples of basic fixed-width layout code.
You also need to decide how you want your site to appear in larger monitors — left-aligned, meaning potentially lots of unused monitor space ("canvas") on the right side, or centered in the middle of the display. I much prefer centered sites myself. Since HTML will present the site aligned to the left by default, you have to take care of that little chore yourself. Here's one method, using CSS to modify the <body> and <wrapper> elements:
body {
text-align: center; /* for IE */
}
div#wrapper {
text-align: left; /* reset text alignment */
width: 960px; /* or a percentage, or whatever */
margin: 0 auto; /* for the other browsers */
}
The text-align: left makes sure that everything inside the wrapper isn't center-aligned.
Personally, I tend not to code with fixed-width layouts, but that's just me. Many designers with more chops than I swear by fixed layouts. (Um, Michael, this site uses a fixed-width layout. I know, I know.)
If you're interested in seeing some examples, CodeSucks.com provides a plethora of basic fixed-width layout templates that you can pore over at your leisure to see how they work. Web designer Alessandro Fulciniti also provides several dozen templates, many of which are fixed-width (or fixed-fluid hybrids).
Fluid Layouts
As above, to understand fluid layouts (also called liquid or liquid-width layouts), you have to know that the layouts are written in percentage measurements.
More about units of measuring size.
Cherim defines the fluid-width layout:
A fluid or liquid layout is created by not specifying a wrapper width at all or doing so using the percentage unit of measure. In other words, barring borders and padding screwing things up, a 100% width site will take up the entire viewport width without producing a horizontal scroll bar.
In other words, the fluid-width layout fills the entire screen, whether it be 300px wide or 3000px wide.
Mason writes:
Fluid (or liquid) layouts — even with a minimum and maximum width set — are harder to control, especially if the design requires features like a full-width header image.
Some designers like to create a "fixed/fluid" layout, for example a 3-column layout with fixed left and right sidebars and a fluid central content area.
Advantages of a fluid layout:
- It's not easy to do, but if done properly, a fluid layout can adapt to almost any viewport size, making the design very user-friendly.
- Fluid widths match the browser default layout, making it a "pure" layout. This does not necessarily translate into ease of use.
- Fluid layouts take advantage of a screen's entire viewport, making it easier to place important content "above the fold" (visible without scrolling).
Disadvantages of a fluid layout:
- As noted above, fluid layouts can be quite difficult to use. On large displays, lines of text can stretch on for what seems like miles, while on smaller displays, the layout can become quite congested. Sometimes the content blocks can overlap or "lay atop" one another. Often, whitespace is either underdone or overdone.
- Using the CSS
max-widthproperty doesn't always limit the width of the site, especially in — you guessed it — IE6. - It can be tough to design for larger images, videos, and other fixed-width content.
Designing with a fluid layout works best when the designs are simple and uncluttered with large numbers of images, videos, forms, and so forth. And using minimum/maximum widths is almost mandatory. My friend Paul O'Brien offers an excellent JavaScript-based method that works in IE6 and more modern browsers. Design Jedi Cameron Moll offers a similar technique.
Personally, I used to design with fluid, percentage-driven layouts, but I gave it up because of the caveats above.
One of my favorite layout designers, Matthew James Taylor, provides some tricked-out fluid layouts. Web designer Alessandro Fulciniti also provides several dozen templates, many of which are fluid-width (or fixed-fluid hybrids).
Design ninja Russ Weakley wrote a seminal 2003 article on designing liquid layouts.
Knight gives us a fascinating look at a new "adaptive" take on fluid layouts.
Elastic Layouts
As above, to understand elastic layouts, you have to know that the layouts are written in em measurements.
More about units of measuring size.
And I'll again let Cherim give a definition:
An elastic site's main wrapper and other elements are measured using ems as the unit of measure. Ems are relative proportionally to the text or font size. Thus, as the text size is increased, the sections measured in ems will increase in size as well.
Ems are used both with font sizes and layout dimensions.
Mason writes:
Em-based designs — especially when combined with some fluid elements — in a sense combine the both of best worlds…
Designers almost always set a "base size" for their fonts:
body {
font-size: 16px;
}
More about fonts and typography.
Once you've set this, you've told the browser that 16px=1em. Now you're cooking.
In Mason's example, he sets the wrapper (the ID that contains the entire site) thusly:
#wrapper {
width: 46em;
margin: 0 auto;
max-width: 94%;
}
Now the site is 46 ems in width (736px, for those with calculators), centered, and set at a max-width of 94%. Probably a bit narrow, so you can break out your own calculator, or abacus or notepaper or whatever, and figure out a width that suits you. Mason notes:
This setting will create a centered, fixed-width design, but with the difference that, if the user increases the text size, the wrapper will also grow proportionately. This is much nicer than having text reflowing with every resize.
Mason notes that while you can use a max-width of ems, because the designer has no idea how big or small his user's viewport is, the percentage dimension works with all displays.
I'll leave it to you to read Mason's entire article for much more about designing for smaller viewports (say, your friend's Blackberry), and even a way to make images — yes, images — elastic.
Many designers see elastic-width layouts as a "happy medium" between a rigid fixed layout and a potentially sprawling fluid layout. Others, like Cherim, don't see the point — why not pick one or the other?
Whether Cherim likes elastic layouts or not, he created an elastic CSS Zen Garden layout of which he is quite proud. Try resizing it and see what happens. Mason also has some interesting examples to go with his article.
Advantages of an elastic layout:
- A properly configured elastic layout resizes proportionally — thus, a user who resizes his browser gets the same site, just smaller or larger, with the layout, typography, etc. following along. (This is tough to do with images, but not impossible.) Ultimately, elastic layouts can be very stable.
Disadvantages of an elastic layout:
- Unless the designer limits the maximum and minimum widths, an elastic design can become a disaster, becoming incredibly large without ever stopping.
- Elastic layouts are, generally, the toughest designs to get right, and pose serious challenges to the designer.
- They often require supplementary stylesheets for IE6.
Designers should make sure that their elastic layouts function well on smaller displays. And it's almost always a good idea to limit the maximum and minimum width, in a way that works on all browsers. (See the section above on fluid layouts for information about incorporating max-min widths into your design.)
When given my druthers, I usually code with width-limited elastic layouts.
Designer Matthew James Taylor has given us a number of elastic layouts coded with both pixels (!) and ems. I've adapted several of Matthew's layouts for my own purposes.
Designer and code guru Patrick Griffiths gives a detailed examination of the pros and cons of elastic design, though he generally makes the case for elastic layouts.
Hybrid Layouts
"Hybrid" layouts combine fixed and fluid layout elements. Typically, such "fixed-fluid" designs have one or two fixed-width side columns and a liquid center, or main, column. This allows the sidebar(s) to always display at a particular size, while the central or main column resizes to fit the browser. As noted above, web designer Alessandro Fulciniti provides several dozen templates, many of which are fixed-fluid hybrids.
Mobile Layouts
As I learn more about creating layouts for mobile devices (handhelds, PDAs, iPhones, iPads, cell phones, and the like), I'll develop this section further. Right now, let me commend you to a three-part series of articles by Web design guru Cameron Moll, called Mobile Web Design. That's a very good start, along with an article, Responsive Web Design, that isn't directly about coding for mobile browsers, but covers useful techniques that we can use in our mobile layouts. (Warning: none of this is for the beginner.) Other resources include SitePoint author Brian Suda's Designing for the Mobile Web and Jeff Starr's The 5-Minute CSS Mobile Makeover.
Note: It would seem obvious that one of the first things you should do to make a mobile-friendly site would be to create a mobile stylesheet and use the HTML media="handheld" attribute for that stylesheet. Would that it were so easy. The "handheld" media type is not well recognized, and many browsers don't handle it properly.
Side note: Many site owners want their mobile site to have the ".mobi" top-level domain, such as www.example.mobi:
While these are certainly desirable, if you don't want to spend the money on a ".mobi" domain, you can achieve almost the same effect by using a far cheaper subdomain, say m.example.com. This has become a very common Web convention and is quite recognizable as a mobile site.
Absolute Positioning in Layouts
We talked more specifically about absolute and relative positioning (among other types of positioning) on this page; check it out if you need to refresh your memory:
Some designers tend to gravitate towards absolute positioning because of the apparent control they have over the page by positioning everything to the pixel. However, in some ways, absolute positioning defeats one of the fundamental rationales behind the Web page: the flexibility it gives the user in how to view it.
Your absolutely positioned layout might look perfect in the 1024x768 or 1280x1024 display size you use on your machine:
but if a user drastically resizes it, or opens it in an oddly sized display (say on a mobile phone or a notebook computer). chances are it will not display as you designed it. The absolute positioned elements will not nestle snugly alongside one another, but will battle for display space, and one or more of the elements will lose. So will the user.
Ian Lloyd writes:
If text sizes are increased in the browser, the document can reflow — that is, adjust the layout to suit the new text size — more freely if relative positioning is used. ... In practice, a well-seasoned web developer will use a mixture of absolute, relative, and floated positioning schemes.
Abandoning Table-Driven Layouts
When I began fiddling about with Web design in 1998 (strictly as a hobby — I've only begun to get serious about Web design since around 2008), every page layout that wasn't simply "stacked content" (a single full-page column with one element "stacked" one on top of the other like pancakes) was designed with tables.
Tables are wonderful things, for presenting tabular data. But early on in the game (pre-CSS), designers discovered that with a little ingenuity, they could use tables to lay out their pages.
It's only been since 2007 or thereabouts that something of a consensus has been reached: CSS-driven (tableless) layouts are best practices, and using tables to create page layouts is just flat wrong.
In 2005, when the debate between CSS and table-driven layouts was raging, Web designer Jon Henshaw explained:
Tables were never intended by the creators of HTML to control the visual style of a web page. They were only meant to display data with columns and rows. There wasn't a mechanism in place to address the needs of more advanced layouts, so some ingenious web designers discovered that they could use tables to implement robust layouts. Since that time, web designers have been regularly misusing the HTML language, mainly out of necessity.
In 2008, the tutorial site Learn Web Design Online wrote:
Now in 2008, the debate is more of historical interest, since it is clear that the web industry had gone in the direction of CSS-based tableless design. This is evidenced in the past years by many major websites doing an entire sitewide redesign to recode their table-based layouts to tableless layouts. If you pick up HTML/CSS books that are published in 2007 and 2008, you will find that it is CSS-based tableless design is what they will teach you.
The same site, in a page titled Benefits of using CSS based Tableless Layouts, gives a number of reasons why CSS-driven layouts are superior to obsolete table-based layouts. Three years before, Henshaw made many of the same observations; Web designer Cameron Olthius wrote on the same topic in 2006. To sum up their arguments, CSS-driven layouts are standards-driven; cleaner; far easier to maintain; more accessible to disabled users; easier for search engines to catalog; perform better; give a multitude of opportunities for creative expression; and are semantically more accurate.
On their side of the argument, advocates for table-driven layouts contend that tables are much more intuitive and easier to understand than CSS layouts; CSS layouts are subject to a number of "bugs" that tables don't fall prey to; and have some advantages, such as equal heights for columns, that CSS layouts do not have without "hacks" or workarounds.
Henshaw concluded in 2005:
The main argument for still using tables today stems from bad habits, and complacency. What is often said is that using tables is easier, and that browsers don't support it. It can certainly be easier in some cases, but browsers do support it. Internet Explorer can be frustrating to design for, because it doesn't adhere to web standards very well, but there are many fixes and workarounds that will enable CSS based layouts to render correctly. If there was ever a time to start designing tableless layouts, it's now.
Henshaw wrote his article months before Internet Explorer 7 came out. With all of that browser's flaws and quirks, it supports CSS-driven layouts much, much better than its persnickety predecessor, IE6.
More bluntly, Olthius wrote:
It's my belief that if you're a professional web designer (in other words, you exchange money for your services) then you should be building sites strictly with CSS.
In my view, Olthius is spot on. I can't imagine anyone, professional or amateur, who claims to adhere to anything approaching modern design practices advocating anything except tableless, CSS-driven layout design.
So why spend so much time and bandwidth on the subject? Because the subject is still being debated, and Web designers who ought to know better have stubbornly continued to advocate for table-driven Web design. You will run into knowledgeable people who strongly advocate tables for Web layouts. I appreciate their determination and their passion, but they are simply wrong. If you intend to design according to best practices, then you design using CSS to handle your layouts.
In the interest of completeness, I should mention an effort, led by some of the best minds at SitePoint and other design organizations, to use "CSS tables" to create layouts. SitePoint founder Kevin Yank wrote about this in 2008, and SitePoint published a controversial book, Everything You Know About CSS Is Wrong! co-authored by Yank and Web design guru Rachel Andrew, strongly advocating for the use of CSS tables for laying out pages. Unfortunately, since IE7 and earlier iterations of that browser do not support CSS tables whatsoever, it is impossible to use such techniques to design pages for anything approaching a general audience. IE6 has been around since 2001, and almost all designers must create their pages with that browser in mind. Who knows how long it will take for IE7 to run its course and disappear? Until then, learning how to code with CSS tables is little more than an academic exercise. (In light of the new layout techniques that will, we are told, be included in CSS3 when it is released and when browsers begin supporting it, we may never use CSS tables to create layouts.)
