Jina has put together an excellent series of steps you can take to keep not just nice, but downright sexy.
Thursday, December 6th, 2007
Sunday, April 29th, 2007
Tom Watson's new site design changes stylesheets with the season. More of this kind of thing please, Web.
Tuesday, April 25th, 2006
CSS Naked Day was fun. It felt almost voyeuristic to peek under the CSS skirts of so many sites. It also made me realise that the browser default styles are what people are going to see if they decide to print out a page from many CSS-based sites.
I’ve had a rudimentary print stylesheet in place for Adactio for a while now, although I should probably revisit it and tweak it some time. But a lot of other sites that I’ve designed have been woefully lacking in print stylesheets.
Would it be possible to get a print stylesheet for the errata page that does a better job of preserving the table layout? As it is now, it’s sometimes hard to tell which page numbers match up to what errors. Just some borders on the table would help a lot.
That one made me slap my forehead. Of course! If ever there was a web page that was likely to be printed out, the errata for a printed book would be it.
As well as adding borders to the errata table, I set to work on creating a stylesheet for the whole site. It was fairly quickly and painless. I hid the navigation, let the content flow into one column, set the font sizes in points and used a minimum amount of colour.
I did much the same for Jessica’s site, WordRidden.
Principia Gastronomica was crying out for a print stylesheet. Half of the entries on that blog are recipes. Most people don’t have computer screens in their kitchens so it’s very likely that the recipes will be printed out.
A lot of the entries on Principia Gastronomica make heavy use of images. Everyone likes pictures of food, after all. I was faced with the question of whether or not to include these images in the printed versions.
In the end, I decided not to include the images. Firstly, it’s a real pain trying to ensure that the images don’t get split over two pages (
page-break-before would be a draconian and wasteful solution). Secondly, I bowed to Jessica’s wisdom and experience in this matter. She often prints out recipes from sites like Epicurious and, when she does, she wants just the facts. Also, these are pages that are likely to printed out in the home, probably on a basic inkjet printer, rather than in an office equipped with a nice laser printer.
If you’re implementing a print stylesheet for your site, I highly recommend reading Richard’s guide, The Elements of Typographic Style Applied to the Web. All the advice is good for screen styles, but is especially applicable to print.
These articles on A List Apart are also required reading:
- Improving Link Display for Print by Aaron Gustafson,
- CSS Design: Going to Print and
- ALA’s New Print Styles by Eric Meyer.
In an interview over on Vitamin, Eric makes the point that context is everything when deciding which stylesheets to serve up. Clearly, articles on a A List Apart are likely to printed out to be read, but the front page is more likely to be printed out to get a hard copy of the design.
Wednesday, April 5th, 2006
My site has no stylesheets (“how does it smell?”, etc.) but you probably won’t even notice because chances are your reading this in a feedreader.
In any case, it’s nice just to look at the flow of the document sans styles. Notice the “More information”
h2 tag that is normally hidden from view. With styles enabled, the visual layout makes this heading redundant but without styles, or for non-visual user-agents, it’s a useful marker.
Wednesday, January 11th, 2006
Aaron uses image replacement on an image to provide one image for screen and another print. Very clever.
Sunday, April 3rd, 2005
Simon has some good hands-on suggestions for mobile stylesheets.
Tuesday, September 23rd, 2003
Let me tell you why you’re here. You’re here because you know something. What you know you can’t explain but you feel it, that there’s something wrong with the web. You don’t know what it is but it’s there like a splinter in your mind driving you mad.
This is the web as it exists today…
Welcome To The Desert Of The Web
<table border=0 width=100% cellspacing=0 cellpadding=0>
<table width=100% border=0 cellspacing=0 cellpadding=0 vspace=0>
<td valign=bottom><font size=2><br></font>
<table cellpadding="5" cellspacing="0" border="0" width="203" >
<tr><td height="105" valign="top">
<table width=610 cellpadding=0 cellspacing=0 border=0><tr><td width=1><spacer type=block width=1 height=1></td><td width=608 bgcolor=666666 height=1><spacer type=block width=1 height=1></td><td width=1><spacer type=block width=1 height=1></td></tr><tr><td width=1 bgcolor=666666><spacer type=block width=1 height=1></td><td><table width=100% cellpadding=0 cellspacing=0 border=0 bgcolor=e6e6e6><tr><td>
<td width="179" bgcolor="#ffffff" align="left">
<tr><td><img src="http://pics.ebay.com/aw/pics/x.gif" height="0" width="0"></td></tr>
<td valign="bottom" align="left" width="179" height="21">
<table align="left" width="157" cellpadding="0" cellspacing="0" border="0" bgcolor="#ffcc00">
<td align="left" colspan="2"><img src="http://pics.ebay.com/aw/pics/x.gif" width="157" height="2"></td>
<td align="right" rowspan="3" colspan="2"><img src= "http://pics.ebay.com/aw/pics/22x21.gif"
width="22" height="21" border="0"></td>
I didn’t say it would be easy. I just said it would be the truth.
Why Use XHTML?
Web development is a war and we are soldiers, writing hacks and workarounds to make designs look right in buggy older browsers.
What if tomorrow the war could be over? What if we could build sites that won’t fall apart in future browser releases? Isn’t that worth fighting for? Isn’t that worth developing for?
XHTML encourages good practice. All your markup will be well-formed and all your tags will be closed. This makes page rendering easier for browsers and it makes bug-tracking easier for you.
Best of all, using XHTML means that you must keep your presentation separate from your content.
All you have to do is free your mind.
Why Use CSS?
Just imagine all the benefits that come with separating your presentation from your content.
Your pages will be smaller, much smaller. Without the bloat that comes with nested tables, spacer images and font tags, your mark-up will be leaner and meaner. That will appeal to search engines.
Life will be simpler for the people in charge of the design: the presentation of an entire site full of documents can be changed by altering just one file without ever touching the content.
Life will also be simpler for the people in charge of the content: your mark-up will be human readable allowing the content to be updated without changing the rules that govern the presentation.
With Cascading Style Sheets, your content will be accessible to all browsing devices, past and present. That means everything from Lynx to web-enabled mobile devices and fridges.
Remember, all I’m offering is the truth - nothing more.
Where To Begin?
Okay, I’ll try to stop with the Matrix-speak and get down to business.
Where should you start when you want to create a CSS based design?
"Content Is King". It’s a pithy old adage but it’s true.
Everything begins with the content. Everything else is layered on top.
Your finished page will have layers of presentation piled one on top of the other. But if you peel those layers away, what you are left with is the very heart of your page: the content.
Standards compliant browsers will see a beautiful many-layered page. Browsers with partial CSS support will see a partially layered page. Older browsers and search engine robots won’t see the layers of presentation but they will see the page.
The process of adding these layers is called progressive enhancement.
The result of allowing those layers to be stripped away without affecting your content is called graceful degradation.
The first and most important step on the road to CSS based design is having semantically correct mark-up.
That’s just a fancy term for describing your content correctly.
Semantically Correct Mark-up
Put headings and subheadings into
If a piece of text acts a label for an
<input> item in a
<form>, then describe it as such by using the
Wrap your paragraphs in
<p> tags. If you have a list of links, then put them in a list (
<ol>) and make each of them a list item,
You may have pre-conceived notions about how these will look.
The default presentation of tags is a result of browsers following basic rules.
What you must learn is that these rules are no different than the rules of a computer system. Some of them can be bent. Others can be broken.
You think that all
<li> list items appear vertically with a bullet point next to them? You think that’s air you’re breathing now?
Free. Your. Mind.
I’m sorry. That was the last Matrix reference: I promise.
Sometimes you’ll want to describe some content but there won’t be a suitable tag available. You can’t make up your own tags but you can reach for
<div> is a block level element. That means it’s self-contained and comes with a built-in line break.
<span> is an inline element. Inline elements don’t include a line break and must be contained within a block level element.
<span> are like blank slates just waiting for styles to be applied to them.
Don’t go overboard with
<span>. If there’s an existing tag that describes your piece of content correctly then use that tag.
Classes and IDs
If you want to apply a style to all instances of a certain tag, then you simply reference that tag in your stylesheet.
If, on the other hand, you want to apply a style selectively, then you’re going to need to add either a class or an ID to the tag.
Classes are reusable. A document can contain any number of tags that use the same class, e.g.:
An ID is unique. A document can only contain one instance of
Even though we can name our classes and IDs anything we wish, it’s still a good idea to try to use descriptive rather than visual terms. Describe a class as being "important" rather than "bigredbold".
If we combine the power of
<div>s and IDs, we can take the semantic description of our documents even further than the tags provided by XHTML allow.
Most web pages can be divided up into sections like "main navigation", "sub navigation", "main content" "related material", etc.
XHTML doesn’t give us the tags to describe these chunks of content. But if we take the blank slate block-level tag (
<div>) and give each section a unique identifier (ID), then we’ve taken semantic description to the next level.
If you mark up your pages with areas like
<div id="footer">, etc. then you have a way to reference those chunks of content. You will then be able to affect their visual appearance and even change how they are positioned.
If you’ve followed the advice I’ve given you so far then what you have now is a semantically correct document with no superfluous tags or attributes, broken down into helpful chunks.
Now we can begin to add the layers of presentation. We already have the core.
It’s possible to embed your styles within the very tags themselves e.g.:
<p style="text-align: right;">
But what’s the point of that? We want to separate presentation from content, not mix them up.
We can give a document its styling instructions from within the <head> tag by wrapping everything up in
This is slightly better than inline styles but it still means our content and our presentation are in the same place.
By keeping our styles in external documents we achieve a true separation of content and presentation. We can also change the presentation applied to a multitude of documents by altering just one external file.
The easiest way to reference an external stylesheet is by using the
<link> tag within the
<head> of your document, like this:
<link rel="stylesheet" type="text/css" media="screen" href="path/to/stylesheet.css" />
Notice that there is an attribute called "media" which we have set to "screen". This means that the styles in that stylesheet will only be applied to on-screen presentation. We could use a different stylesheet entirely for printing out our documents, referenced with the "media" attribute set to "print".
<link> tag is the most universally recognised way of referencing an external stylesheet. Even older browsers with just partial CSS support understand it.
Standards compliant browsers also understand the
@import method of referencing stylesheets. We can use this to our advantage. We can provide a basic stylesheet with the simplest of instructions referenced by
<link>. We can then add more complex instructions in stylesheets referenced by
@import like this:
<link> method, we can put our
@import command within the
<head> of our document (nested in
</style> tags). However, there’s a much cleverer way of referencing our more complex stylesheets.
We can put our
@import command within the basic stylesheet that we referenced using
<link>. That means our document only ever references one external stylesheet, a very basic one, but that stylesheet itself references more complex instructions.
Stylesheets within stylesheets. Basic styles for basic browsers. Complex styles for more complex browsers.
Once again, we’ve taken separation to another level. Now our stylesheets have been separated into basic styles and complex styles. We can go even further than this. To make life easier for us, we can have separate stylesheets for typography, positioning, etc., nested like russian dolls, one stylesheet referencing the next.
In our basic stylesheet, the one we reference with
<link>, we can put simple information like the basic colours and fonts we want to use.
We start by referencing the
<body> tag. Here’s how we specify the font-family we want to be used:
font-family: "Verdana", "Arial", "Helvetica", sans-serif;
Notice how we can specify different fonts in order of preferences. We want to use Verdana. Failing that, Arial. If Arial isn’t installed, then Helvetica will do. Finally, if none of those fonts are installed, then we say that any sans-serif font will do.
Now we can add some basic colour information. Whenever you specify the colour of something, it’s always a good idea to also specify the background colour.
We could use colour keywords like "white", "black", etc. but they’re fairly limited. We get a wider a range of values by using RGB values like #ffffff, #000000, etc.
Using web-safe RGB values also allows you to use a shorthand method of writing out the values. Instead of writing #6699cc, we can just write #69c.
Here’s how we’d add to our existing styles for the
<body> tag to specify black text on a white background:
font-family: "Verdana", "Arial", "Helvetica", sans-serif;
Now that we’ve set the typeface and colour for our document, let’s just take care of our links.
We can style our links to look however we want; bold, italic, underlined, whatever. We can also specify different styles for the various possible link states: link, visited, hover and active. These are called pseudo-classes.
That’s the right order to specify the pseudo-classes. Here’s a handy mnemonic for remembering the order: LoVe HAte.
Sizes and Units
Whenever we specify the size of something using CSS, we have a number of different options open to us.
When sizing text, for example, we can use percentage values, pixels, points or ems. We can say
font-size: 12pt or
font-size: 1.5em. The important thing is that we always specify units of some sort.
Layering The Presentation
Once we have our basic typography and colour laid down and referenced via
<link>, we can begin to add more complex styles referenced via
CSS allows us to add typographic flourishes that were previously impossible to achieve on the web. Print designers will tell you how important leading and kerning are when laying out text on a page. The CSS equivalent to leading is
line-height. For kerning we use
Another handy feature of CSS is the ability to add a background image to any element.
We can also control the amount and direction of tiling we want from the background image. This is done using
background-repeat. If we don’t want the background image to tile at all, we give this a value of
none. If we want it to tile vertically but not horizontally, we give
background-repeat a value of
We can also position the background image so it need not necessarily begin in the top left corner of its containing element (the default position for background images). To do this we use
background-position and we can specify either keywords, e.g.
right, etc. or we can use units like pixels or percentages. We can even mix units.
background-position: 90% 25px;
The Box Model
Every element has an invisible box around it. The content of every element is surrounded by
padding is contained by a
border is surrounded by a
We can manipulate the values of all three of these properties. For instance, we can change the width, style and colour of the
Or we can combine these all together with this shorthand notation:
border: 2px dotted #000;
margin we can specify the width for all four sides. Again, we are free to use any units we want and we can mix units.
If you are wondering whether to increase the
padding or the
margin of an element in order to add space around it, just remember that the
padding extends right up to the
border and will inherit values from the element itself such as
margin on the other hand, begins outside the border and doesn’t inherit values from inside the
Here’s one way to specify all four
margin values of an element:
Or we could use this shorthand notation, going clockwise from the top:
margin: 20px 10px 20px 10px;
In this case, because the top and bottom values are the same and the the left and right values are the same, we can use even more shorthand and just specify the vertical and horizontal values:
margin: 20px 10px;
If we wanted the same value on all four sides, all we’d have to declare is:
Many elements have inherent values for
margin: it’s what determines between the space between paragraphs or the distance between the edge of the screen and where the
<body> begins. We can still manipulate these values. So if you wanted no space between the edge of the screen and the beginning of the
<body>, simply declare:
You’ve probably noticed that I didn’t specify any units there. Didn’t I say that you should always specify units? Well, there’s one exception to that and that’s when the value you’re giving is zero. Zero pixels is the same as zero percent is the same as zero points.
Adding It All Up
One of the most obvious ways of manipulating an element’s appearance is to change its size. We do this by altering its
height. Once again, we are free to use any units we wish:
So what happens when we declare an element’s size but we also declare sizes for its
In theory, all of these values are added together to give the total width:
+ 10 (left
+ 10 (right
+ 10 (left
+ 10 (right
+ 10 (left
+ 10 (right
260 pixels total width
Unfortunately, the Windows version of Internet Explorer 5 (and, depending on your
doctype, IE6) gets it wrong.
Internet Explorer gives the overall total width at 220 pixels. The actual content of the element is reduced to 160 pixels because of the application of
border. Only the
margin values are correctly applied.
You’ll need to bear this discrepancy in mind when you’re putting together CSS designs but there are workarounds to get around this.
CSS allows us not only to change the appearance of page elements. With block-level elements we can also affect where they appear in the page. This is done using the
position declaration together with declarations like
Again, you can use any units you like, though pixels are probably your safest bet.
By default, all page elements have a
static which simply means that they appear where they would normally appear anyway, without any CSS trickery applied. When we want to manipulate the position of an element, such as a
<div>, then the two most important positioning options available to us are
position: relative, declarations like
left refer to the element’s normal (
static) position in the document:
This would put an element ten pixels below and to the right of where it would normally be.
position: absolute, declarations like
left refer to the containing element. In most cases, this would be the
This would put an element ten pixels below and to the right of the top left corner of the screen.
Once you declare that an element has a
position that is
absolute, that element is taken out of the flow of the document. Its default position is no longer where it would normally appear. Instead, its default position is the top left corner of its containing element (usually the
In other words, the order of absolutely positioned elements in the XHTML document no longer matters. Their positions now depend entirely on the CSS. Your document could have
<div id="content"> followed by
<div id="navigation"> but you could use CSS to place the navigation before the content.
Absolutely positioning elements is all well and good when you know the exact size of each element and the exact position where you want them to appear. It can’t help you if you want the position of one element to depend on the position of another.
You might want to declare, for instance, "whatever follows this element should appear to the right of it". Because absolutely positioned elements are taken out of the document flow, they have no context to relate to.
Luckily, we have the very powerful
float declaration which is all about context.
As we have seen, all block-level elements have an in-built line break. A series of block-level elements, such as
<div>s appear one underneath the other.
By applying a
float declaration of
right, we can determine what happens to the element that follows. Instead of appearing underneath its preceding element, it butts against it.
For the following examples, let’s assume that each box is a
<div> of fixed
float: left to box number one:
Box number two butts against the right of box number one.
Now let’s apply
float: left to boxes one and two:
Box number two butts against the right of box number one and box number three butts up to the right of box number two.
We are also provided with an antidote to
float. It’s called
clear. By applying a
clear declaration of
both, we can "break out" of any abutting caused by preceding elements.
clear: left to box number three:
Even though box number two has a
float: left declaration, box number three appears below it instead of butting against it. By declaring
clear: left on box number three, we can be sure that nothing will appear to the left of it.
Here’s a fairly complicated arrangement:
float: left on box number one so anything following it should butt against its right side. However, it’s followed by box number two which has
float: right declared so it appears off to the right hand side. Anything following box number two should butt against its left side. However, in this case the following element, box number three has a
clear: both declaration so it doesn’t appear to the left or right of anything.
Putting It All Together
Now you’ve seen just some of the things of which CSS is capable. There are many more stylesheet declarations that I haven’t covered but we’ve seen the most important cornerstones.
- Begin with correctly marked up XHTML documents.
- Add basic styles with a stylesheet referenced with the
@importto reference stylesheets with more complex declarations.
- Position page elements either absolutely or relatively.
If you build your websites this way, the rewards will be manifold:
- Faster loading times: stripping out
<table>tags can bring page sizes down enormously.
- Backwards compatibility: even the oldest web browser will be able to access your content.
- Better search engine rankings: Google loves semantically correct documents and hates tag soup. Clever Google.
- Ease of updates: you’ll be able to update your content without worry of changing your design and you’ll be able to change your design by just changing one or two files.