Learning how to use CSS for creating web sites is a pain in the ass. It’s not easy and it will hurt you. Over the last several years I’ve been asked by many web designers and developers about how to best get started with building web sites using CSS and standards. Usually, I’ll just send them 300 links and wish them a lot of luck. This overview is sort of my penance.
When it comes to understanding the world of standards based design, you have to think medieval. Creating a web site in CSS is like building a manor. You are a lord, setting aside land for specific purposes, hoping the user rotates their content appropriately. Most of you will build villages attracting only a few peasants to comment on various decrees, some of you will build castles and a very small number will build what I can only describe as cathedrals—structures that warrant pilgrimages from thousands across the globe.
There are few manuscripts to guide the way and the few monasteries dedicated to the craft are mostly filled with men. In addition to the kings, queens, wizards, dragons, knights, blacksmiths and apprentices, there is the code of conduct and the Crusades and the Inquisition and the trials and the tribulations and the terrible spiritual journey that everyone seems to think is a necessary rite of passage to leave behind the world of tables and spacer gifs. It’s a hard living because it’s not easy. It could be and should be easy, but there are too many exceptions and too many rules you have to know just to get started. Tables, I’m going to remind you, are easy. Slutty almost in their seductively slothy ways. It’s not too late to go back right now.
That said this overview will cover the current strategies used around the web to build the foundation of every CSS-based web site: layouts. Creating a layout in CSS is one of the hardest skills to master both conceptually and in practice because the vocabulary is large, somewhat new (even for experienced web designers) and often contradictory. Before we begin, please remember that these techniques are like footsteps in Heraclitis’s river, they are ever changing and should not be seen as doctrine but as guides. This overview will not hold your hand through every step of the process, but will help you find what I think are the paths to the appropriate sources.
They’re Just a Bunch of Boxes
There is a fierce and complicated history and dialectic to follow when it comes to the evolution of the XHTML and CSS architectures. The W3C has been there nearly every step of the way documenting and creating great tools to help everyone in the community keep track of the chaos and dialogue. Like any field or discipline that’s constantly evolving, I think starting your relationship with the authoritative source and moving outwards is the best approach to mastering it. If you’re serious about learning CSS, I highly recommend reading W3C’s technical specs and white papers.
In regards to creating layouts, I recommend paying particular attention to W3C’s ideas in Chapters 9 and 10 on the Visual Formatting Model. I’m not going to lie to you, it’s a dry read. But it’s also a good foundation / review for professionals and budding amateurs. This chapter describes how user agents (browsers) should process the document tree for visual media. There are two important ideas I took away the first time I read through the material:
1. In the visual formatting model, each element in the document tree generates zero or more boxes according to the box model. It’s crucial to understand that there are several ways to visualize the structures of an XHTML document. There’s the text itself, which is a linear sort of thing. Then there are the hierarchies contained in the document tree, which is extremely useful for programmers who need to traverse the information for scripting purposes. And for the designers, it’s just a bunch of boxes with borders, internal personal space (padding) and external personal space (margins). Creating a layout with CSS is simply a manipulation of the rules that govern the properties of these boxes and their personal spaces. This is what W3C says they are:
The layout of these boxes is governed by:
- box dimensions and type.
- positioning scheme (normal flow, float, and absolute).
- relationships between elements in the document tree.
- external information (e.g., viewport size, intrinsic dimensions of images, etc.).
To illustrate the point further, check out some of my favorite layout depositories:
2. A web page created with CSS is three dimensional. People often forget that there is a z-axis or depth to these pages. Thanks to the z-index property, boxes can be layered on top of one another to create complex visual effects. This idea might be confusing to some, but it makes sense when you think about how the best examples or illustrations of various concepts surrounding certain CSS techniques are best explained with 3 dimensional diagrams. Compare W3C’s diagram of the Box Model with Red Melon’s interactive flash demo of the box model. I believe this ability to layer elements is CSS’s greatest advantage over creating layouts with tables. Understanding the power and versatility of boxes that can be stacked and rearranged at whim was the knowledge that set me free from the old school way of doing things.
In the last few years there’s been a sort of visual renaissance in the CSS design community to break the notion that the web will only be constructed with boxes and squares upon squares. This defiance has lead to the rapid adoption of any visual trickery that can create additional depth and curves to a design: rounded boxes, angled/rotated banners, gradient backgrounds, drop shadows, etc. These visual tricks have all been put on the list of things to come with the CSS3 specs. It is this organic interaction between W3C and users /developers that I find most exciting about this community. Because our environment is always evolving, working with and pushing CSS layouts today helps make things much more exciting and easier to implement in the future.
Fixed vs. Fluid
One of the great debates you’ll find in the CSS design community is over whether fixed or fluid layout solutions best compensate for the differences between the 800x600 crowd of the corporate/typical user and the forward-thinking, obsessive-compulsive, ridiculous resolution users that tend to be the designers themselves. The problem, as I see it, is that the web is a dynamic medium that can be accessed in a variety of visual and operating formats. The basic fluid-pusher philosophy is that web designs should reflect their medium and be dynamic and adaptable. Unfortunately, for a field that is usually comprised of converted print and traditional graphic designers, this loss of control over the final presentation and dimensions proves difficult and sometimes even impossible.
To read more about the debate, check out the articles for and against both sides pointed out by Water vs. Stone - The reality of Fluid layouts.
The Other Options
The arguments for fixed and fluid layouts are primarily concerned with determining the ultimate width of a web site. This is because widths usually determined the number of useful columns that can be used to design a site, which is a major layout consideration among a lot of “traditional” graphic designers. Thanks, however, to a lot of experimentation by a lot of exciting people, the choices are no longer simply restrain your layout to some arbitrary 700 pixel limit or go 100% and risk poor text readability at larger resolutions.
Elastic Design - this concept proposes the use of ems instead of percentages to describe widths and typography. This would then tie a layout to the user’s preferred reading size. The logic being that a layout isn’t any good to someone who can’t see the content.
Elastic Layouts - show how minimum widths can be used to prevent a layout from collapsing. Even goes over a little known hack you can use to make it work for IE.
In the beginning, when everything was new and the potential of the web was high, people were pushing the boundaries, but were frustrated that some of their solutions or implementations were just not working. It turned out the problem, the very thing that makes designing for the web so difficult, was in the renderings by the “user agents” or browsers. And while it’s nice to know that some problems are just not your fault, rendering differences across browsers make the task of designing for the web counter-intuitive and extremely frustrating. If you’re serious about web design, keep tabs on the following two sites—they have distilled the art and accident of finding browser bugs to a science:
CSS Filters and Hacks
The obvious question you ask once you realize that you’ve run into one of these browser problems is what you can do about it. Well, one way to go about it is to not allow certain CSS rules to get through to certain problem browsers. These techniques are called filters and can be found here:
CSS Filters for Bypassing Specific Browsers
Or you can use a hack to trick the browser into doing what you want it to do … they’re easy to find and somewhat easy to use BUT I must warn you—they are ugly solutions, solutions that have no future. Two wrongs really don’t make a right in the long run and I want to recommend reading the following articles first to see what preventative strategies and alternatives are out there to avoid using these evils.
Articles on Hack Education and Hack Alternatives
Kevin’s Cliff Notes Version : Avoid them, Understand them if you have to use them, Comment your Hacks, Import your Hacks.
And then when you get desperate, you can always ask the robots to do it for you. Here are some web sites created in typical Web 2.0 fashion to do your bidding online. Not only are they great for the lazy, they’re good starting points for those who like to look and take apart without feeling guilty.