If you like this, you’ll love Quick Tips.

{Main Content}

Table of Contents

1.0 Introduction

1.1 Pronunciation

Web Design+, the bits they probably didn’t tell you in class:

Say what you see, Web Design+ really is pronounced just ‘Web Design Plus’. Now you can say it, maybe you can Digg it?

1.2 Abstract

What does it do? What is it all for?

Welcome to Web Design+. This is, in no particular order, an amalgamation of web-standards solutions for common web development issues and problems — a way to tackle development in the cleanest, most accessible and semantic way possible. By using Web Design+, the aim is to standardise practices throughout an organisation; from accessibility to hacks, Web Design+ covers the best ways to tackle a variety of dev problems.

The idea of Web Design+ is not to force techniques and methods onto developers, but to offer the best known ways of getting round problems, and generally better coding and developing standards in terms of accessibility, maintainability, usability and longevity.

Most of the tips here I have picked up along the way and have been of massive help to me — though I wish I had learn them all right away, which is why I’ve decided to collate them all for use by up-and-coming developers.

1.3 The Developer

Who had this much spare time?

Web Design+ was designed and developed by Harry Roberts, a 19 year old web developer from the UK. Harry works for Sense Internet, Yorkshire’s Best Web Design Company, as a front-end developer specialising in CSS, web standards, semantic xHTML, accessibility, usability and UX/UI. Check out my portfolio site, and follow me on Twitter.

Top ↑


2.1 Correct !DOCTYPE

Use xHTML 1.0, HTML 4.01 is too outdated:

The correct !DOCTYPE to use depends on the project. If you are starting a new project use the Strict !DOCTYPE, if you are appending or modifying an existing project use the Transitional !DOCTYPE. This boils down to the actual meaning of each word: transitional means making a transition — to be used when bridging between old and new code to minimise errors. Otherwise, it’s better practice to use the Strict !DOCTYPE to ensure better quality code.


For adding to and amending existing projects that potentially use old and/or deprecated markup:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


For new builds and isolated projects that will use clean markup:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

Top ↑

3.0 Markup

3.1 Structure and Semantics

The fundamental aspect of a maintainable project is well structured and semantic markup. Proper indentation, semantic ID and class names and valid markup all lead to better code.

3.1.1 Semantics

The main idea and purpose of semantics is to provide meaning through code:

<span class="alert">Warning!</span>

is much better than:

<span class="red">Warning!</span>

as the content of the span will always be a warning, but might not always be red. A general rule is to name classes and IDs after their purpose rather than appearance.

3.1.2 Structure

It is important to properly structure and indent markup, this means opening and closing tags in the correct order, e.g.:

<a href="#"><strong>Link Text</strong></a>

rather than:

<a href="#"><strong>Link Text</a></strong>

3.2 Validation

While validating you markup isn’t the be-all and end-all of creating maintainable, decent code, it’s certainly advisable. Valid code will eliminate the majority of broken layouts and visual discrepancies, making cross browser compatibility much simpler.

3.3 ID and Class Names

It is important to use semantic and relevant names for ID and class attributes, they should be as succinct as possible while being as long as is needed. As a general rule, only use a class if it is likely to appear more than once, and IDs for unique items such as container <div>s.

3.3.1 Generic Class Names

It’s always a good idea to define a series of generic class names in each new project that will be used frequently to achieve mundane tasks. Please read more in the CSS section.

Top ↑

4.0 CSS

4.1 CSS Resets

CSS Resets are the topic of much debate. Developers either love or hate them. They are used to create a level playing field across different browsers in one go. The most basic of which is:

This removes all paddings and margins from everything:


They help to minimise discrepancies in layout from browser to browser but at a cost — some of the most comprehensive resets inflate .css files, effecting bandwidth and load times.

Some of the better resets include:

4.2 Diagnostic CSS

Very useful:

Diagnostic CSS is incredibly useful during the build phase as it allows you to visually recognise errors in your markup as you build. Using advanced selectors such as a[title=""]{…} you can target markup based on it’s attributes. That example will locate and style any links with empty title attributes in your HTML.

4.3 Generic Classes

Extremely useful:

It is a good idea to have a preset list of generic classes in your stylesheets to carry out repetitive styling. Where possible however you should aim to use some more semantic naming techniques if they are available. Here are several examples:

.clear        { clear:both; }
.left         { float:left; }
.right        { float:right; }
img.left      { margin-right:1em; margin-bottom:1.8em; }
img.right     { margin-left:1em; margin-bottom:1.8em; }
.text-right   { text-align:right; }
.half         { width:45%; /* Not exactly half to account for paddings, margins etc. */ }

.hide{ /* Hide stuff without resorting to display:none; */


Various reactions to the suggested use of generic classnames have prompted me to add additional note; generic class names are by definition insemantic. However if the use of semantic naming techniques will bloat both markup and stylesheets with extraneous class/ID names it makes more sense to use reusable singularly-defined class names — this will save both time and effort. Furthermore, the chances are that if you need to apply a clear or a left float in one iteration of a build, it will most likely still need clearing etc in subsequent iterations.

Top ↑

Menus are not navigation!

Time and time again designers and developers wrongly categorise navigation and menus as being one and the same. Navigation is a means of navigating an entire site, whether that be through the main menu, sidebar links, breadcrumbs or content links. A menu however (which is often incorrectly referred to as the ‘navigation’ or simply ‘nav’) is the main body of links often located at the top of a document, and is usually consistent throughout the whole site.

An example of a menu

A menu — part of, but not exclusively, site navigation.

As such, a menu is part of the navigation, but is not navigation in itself. Another way to look at this is through the analogy: ‘All humans (menus) are animals (navigation), but not all animals (navigation) are humans (menus).’

Traversing the whole site from anywhere:

Navigation is the backbone of any website — all pages are connected (hence ‘web’) in some manner but it is the job of a web designer/developer to make these pages easy to access from any/all locations. Navigation encompasses everything from content links in body text, menus, breadcrumb trails and even URLs.

Navigating from a central point — a menu:

Now we have established the distinction between menus and navigation through etymology and semantics, let’s further dissect the word ‘menu’. Using the traditional form of menu — in a restaurant — we know that it is a list of items which can be selected at will. Transferring this to the web it’s only right to assume that a menu will be a list of links. This means that menus should be constructed using the <ul> element, and <li>s. Here is an example menu:

<ul id="menu">
	<li><a href="./" title="Home">Home</a></li>
	<li><a href="about/" title="About Me">About</a></li>
	<li><a href="work/" title="My Work">Work</a></li>
	<li><a href="contact/" title="Contact Me">Contact</a></li>
	<li><a href="services/" title="My Services">Services</a></li>

Like a menu, but slightly different:

Progress indicators — used to show a user’s location on a linear process — are very similar in structure to navigational menus, but should be built with <ol>s.

An example of a progress indicator

A progress indicator — a form of menu.

The same progress indicator without styling

The same progress indicator without styling.

The markup for a progress indicator is incredibly similar to a regular navigational menu, the only difference is the <ol> over the <ul>. This gives each step a number which is more semantically correct. It’s also a good idea to wrap the current step in a <strong> tag so that it is fairly evident which is the current step when styles are turned off.

<ol id="progress-bar">
    <li><a href="#" class="visited first">Step One &raquo; <span>Pick a User Name</span></a></li>
    <li><a href="#" class="current"><strong>Step Two &raquo; <span>Login</span></strong></a></li>
    <li><a href="#" class="unvisited">Step Three &raquo; <span>Edit Profile</span></a></li>
    <li><a href="#" class="visited last">Step Four &raquo; <span>Join In</span></a></li>

Top ↑

6.1 Best Practices

6.1.1 Phrases and naming

Never use phrases such as ‘Click Here’ for link text. This is because screen-reading software can isolate all the hyperlinks in a given page and lists them out of context for a user to make a decision on where they want to go without having to listen to the whole page (screen-readers can’t scan read pages). As such, ‘Click Here’ means very little to a user on it’s own — aim to use descriptive phrases as link text, e.g.:

<a href="login.php">Click here</a> to login.

can and should be written:

<a href="login.php">Login to your account</a>.

6.1.2 Outlining

Please don’t remove it:

Dotted outlines on hyperlinks

The dotted outline on clicked hyperlinks.

Many people complain about the existence of the dotted outline that appears in certain browsers when a link is clicked. While this can seem unsightly it is important to understand why it is there, and what it does.

The outline is especially useful to users who navigate using their keyboard as opposed to their mouse — a mouse user knows where they’re clicking because their pointer is over the link, a keyboard user doesn’t have this so the dotted outline serves as a pointer of sorts.

6.2 Attributes

Links come with several ‘obvious’ and widely used attributes such as href="" and title="". The former meaning ‘hypertext reference’ and the latter being a title used to describe the link’s function/behaviour.

6.2.1 The Title Attribute

The title attribute should always be used on links for screen-readers (reasons detailed above) as the title will offer a better idea of what the link will do when taken out of context. It also aids non-visually impaired users in that they can glean more information about a link without having to physically click it.

Titles should be as short as possible and as long as necessary, and should convey the behaviour and or location of the link.

6.2.2 The Target Attribute

Avoid using wherever possible:

This attribute defines where the destination document should be loaded. Options include target="_blank", target="_parent", target="_self", target="_top". You can also specify a valid URI, e.g.:

<a href="http://site.com/login.php" title="Login" target="http://site.com/">Login</a>

The target="…" attribute should however be avoided where possible. It was phased out of the Strict DOCTPYE as it enforces browser behaviour on the user. All users can specify whether they want a non-targeted link to open in a new tab/window (by Ctrl+clicking for example) or keep it in the same tab/window. On the flipside however, if a link has a target="_blank" attribute applied it will always only ever open in a new window, and cannot be told to open in the same view.

A common justification for using the target="…" attribute is that ‘I don’t want users to leave my website’ — if your site is worth visiting, the user will come back anyway, otherwise you have bigger problems to solve.

6.2.3 The Rel and Rev Attributes

Not mandatory, but can aid semantics:

The rel="…" attribute tells the browser the forward relationship between the current and destination documents.

The rel="…" attribute is not mandatory or essential but can be used to add semantic value to a link, e.g.:

<a rel="Next Entry" href="archives/?p=50">Next Entry</a>

The rev="…" attribute does exactly the opposite, e.g.:

<a rev="Previous Entry" href="archives/?p=49">Previous Entry</a>

6.3 Fragment Identifiers

Linking to sections/parts within a document:

It’s possible to use IDs and anchors to link to specific parts of a page (used extensively here), these are known as fragment identifiers. This is a valid means of navigation, especially in one page websites. However, if you use a JavaScript scroller to ‘slide’ between locations, make sure the script doesn’t knock the anchor ID from the end of the URI (e.g.: http://site.com/index.php#top). If it does remove the trailing ID, the back button will no longer skip back to the previous part of the page, instead jumping to the previous whole page. Also, it makes it more difficult for the user to link to specific page sections if the ID is omitted.

Top ↑

7.0 Images

7.1 Use of Images

Since the birth of the web, images have been a pivotal part of web design, however there are a lot of forgotten caveats surrounding their proper use.

7.1.2 Embedding in a Page

Through CSS or HTML?

If the image serves no informational/content purpose to the page it should be added using CSS as a background image. This includes the stereotypical image of a woman smiling with her Bluetooth headset on the white collar business website — if the page makes sense without the image, add it using CSS. If however it is a product page, where a product is described with an accompanying image, use the <img /> tag.

7.2 Attributes

7.2.1 The Alt Attribute

The <img /> tag comes with several specific attributes, the most important (and mandatory) of which being the alt="…" attribute. This provides textual information about the image itself for use when either images are disabled, or aren’t visible due to 404 errors etc. If the image is used as a space filler then the alt="…" attribute should be left empty, e.g.: <img src="placeholder.gif" alt="" />

It is also a good idea to give images font styles, such as italicised text, so that if/when images aren’t available the alt text appears styled differently to surrounding copy:


To see this method in action here, simply disable images.

7.2.2 The Longdesc Attribute

Another of the <img /> tag’s attributes is the longdesc="…" attribute. This is an extension to the alt="…" attribute in that it provides an in depth description at a different URI. This attribute is most commonly used on graphical data images such as maps, charts and graphs in order to give detailed information about the content.

The O’Reilly definition is that it specifies a URL of a document that contains a longer description of the element than what the alt or title attributes reveal. This is open to interpretation but it is safe to assume that for an array of images with longdesc attributes you can link to certain points in one external document, e.g.:

<img src="rainfall.jpg" alt="Graph of Average Rainfall" longdesc="graphs.php#rainfall" />
<img src="temp.jpg" alt="Graph of Average Temperature" longdesc="graphs.php#temperature" />

7.3 Image Replacement

There is an inherent need to replace raw text with images on the web; company names with logos, web-safe fonts with custom fonts. These can be for SEO and accessibility purposes among others.

7.3.1 Phark Method

Mediocre Method:

The Phark method of replacing text by removing it from view and replacing it with an image is probably the most widely used. However this method fails when images are disabled, as the text is hundreds of pixels off the screen and nothing else can be seen.

<h1><a href="./" title="Return Home">Home</a></h1>
#header h1{
	width:250px; /* Width of image in question */
	height:70px; /* Height of image in question */
	background:url(/web_design/images/logo.gif) top left no-repeat; /* Image */
#header h1 a{
	text-indent:-9999em; /* Move the text off-screen */
	display:block;  /* Required */
	width:250px; /* Width of image in question */
	height:70px; /* Height of image in question */

7.3.2 Gilder/Levin Method

Really great method…

By far the most robust and accessible method to date is the Gilder/Levin method (no URL available). This method maintains its integrity with all combinations of images on/off and CSS on/off.

This method works by laying an empty <span> over the top of the parent element with the required image applied as a background to that <span>:

<h1><a href="./" title="Return Home"><span></span>Home</a></h1>
#header h1 a{
	display:block; /* Required */
	width:250px; /* Width of image in question */
	height:70px; /* Height of image in question */
	position:relative; /* Required */
#header h1 a span{
	position:absolute; /* Required */
	width:100%; /* Stretch full width of parent */
	height:100%; /* Stretch full height of parent */
	background:url(/web_design/images/logo.gif) top left no-repeat; /* Image */
	cursor:pointer; /* Required for links to appear like links in IE */

…but has its drawbacks:

There is however a drawback to this method; the empty <span>. This is bearable though as the <span> will have no impact on the usability/accessibility on the page, and will only impact ever so slightly on semantics. Now users can always see an image or text regardless of whether they have CSS and/or images disabled.

Top ↑

8.0 Divs

8.1 (Over)Use of Divs

<div>s are the building blocks of CSS developed sites but should not be (yet are) heavily overused. A common overuse of the <div> tag is in wrapping elements such as menu <ul>s and <blockquote>s in order to manipulate and style the locations of these elements. What people forget is that many of these elements are themselves block level containers — the <ul> is a block level element that contains <li>s, and the <blockquote> contains text (often a <p>).

8.2 Float Clearing

8.2.1 The <br /> Method

Works, but less than ideal:

A common problem with floated <div>s within one wrapper <div> is that the parent container doesn’t ‘stretch’ around the floated children <div>s. One common way round this is to add a cleared element just before the closing </div> tag of the wrapper:

<div id="wrapper">
	<div id="content">
	<div id="sub-content">
	<br class="clear" />

The problem here is the superfluous and insemantic <br /> tag. There is however a much nicer way round this:

8.2.2 The Best Method

Perfect method, no extraneous markup:

<div id="wrapper">
	<div id="content">
	<div id="sub-content">

The trick here is the width and overflow declarations on the wrapper <div> — this solves the issue and the wrapper now stretches around both contained <div>s.

Top ↑

9.0 Forms

9.1 Form Elements

Accessibility and semantics in forms:

The <form> tag has several child elements, but only the most relevent in terms of accessibility and semantics are covered here.

9.1.1 The fieldset Element

The <fieldset> element is used to separate and group logical parts of a form. You can have more than one <fieldset> per form, and <fieldset>s within each other. Fieldsets improve semantics and accessibility by providing grouping to the form.

While not mandatory, the <fieldset> should always be used in forms, even if this means only using it once.

9.1.2 The legend Element

The <legend> element comes directly after the opening <fieldset> tag, and provides a description/title about that <fieldset>.

It is not always necessary to have the <legend> in view, so it can be hidden using CSS. The <legend> provides semantic meaning and as such plays an important part in markup — when CSS is disabled the <legend> should add meaning to the forms where styling once did. Issues when styling

There are several issues when styling the <legend> element, as all browsers seem to treat it slightly differently. A fairly stable way around this is to put the <legend> text inside a <span> and apply the styling to that, e.g.:

<legend><span>Contact Details</span></legend>

You should try and apply as much CSS as possible to the <legend>, and all the rest to the <span> as needed. Additional reading.

9.1.3 The label Element

The <label> element provides prompts and hints for specific form fields and inputs. They can be assigned to inputs in a number of ways but the best way is to explicitly declare it:

<label for="name">Name:</label>
<input type="text" id="name" name="name" />

Now when clicked, the <label> text will ‘jump’ the user to the name input.

9.2 Styling Forms

A lot easier than most people make out:

Forms are notoriously tricky to style, but with clean, semantic markup and some basic CSS, forms can be styled neatly and cross-browser.

The first thing to use when styling forms is the <p> tag. Wrap inputs and their respective <label>s in a paragraph to i) separate it from the rest of the element and ii) make the form look sensible without styles.

<form action="./">
			<label for="name">Name:</label>
			<input type="text" name="name" id="name" />
			<label for="email">Email Address:</label>
			<input type="text" name="email" id="email" />
			<label for="url">url:</label>
			<input type="text" name="url" id="url" />
			<label for="comment">Comment:</label>
			<textarea name="comment" id="comment" cols="50" rows="10"></textarea>
			<input id="submit" type="button" value="Submit" />
			<input id="reset" type="button" value="Reset" />

9.3 Usability in Forms

Open to discussion:

There are several ways of increasing usability within forms, one method — which is open to debate — is manipulating the cursor style for <label>s and buttons to display the pointer. Buttons and <label>s both provide actions on click — much in the same way as hyperlinks. In light of this it can be argued that, to enhance usability and indicate functionality, the following CSS can be applied to <label>s and buttons:

.button, label{ cursor:pointer; }

Note the need to add a class to buttons — input[type="submit"] isn’t widely enough supported yet.

Top ↑

10.0 Type

As a preface to this section, you may be interested in reading Information ArchitectsWeb Design is 95% Typography article.

10.1 Sizing Type on the Web

The mighty em:

Whenever styling text on the web, it is advisable to use ems — a relative measure defined as A unit of measurement used in typesetting, approximately the width of the letter “m”. Sizing in ems allows for better scaling of type in all browsers. However, being a relative measure, sizing can be pretty tricky. Most browsers’ default font size is 16px, making 1em = 16px, 2em = 32px and 1.5em = 24px. These numbers aren’t the easiest to deal with so use the following:

html{ font-size:16px; } /* Make sure the default is always 16px */
	font-size:62.5%; /* 16px * 62.5% = 10px : 1em now = 10px */
	font-size:1.2em; /* 12px */

The need for the declaration on the html is to ensure that no matter what, 1em will, at first, always equal 16px.

10.2 Font Size, Line Length and Leading

Never use Helvetica for body copy. Ever.

Helvetica for body copy

Issues with using Helvetica for body copy — it says ‘clicked’!

Font sizing on the web is extremely flexible, but anything smaller than 10px is generally too small to read comfortably. A great article by Wilson Miner outlines the justifications for larger body copy on the web.

Leading is pronounced ‘ledd-ing’ as back when type was set by hand, the lines were separated by strips of lead.

Line height is also fairly flexible, often decided by the designer. However as a general rule a line height of 150%/1.5em is advisable — this helps increase readability, particularly on longer lines of text.

Usability testing has shown that the optimal line length for the web to be 52–78 characters, or 2–3 alphabets. This isn’t a hard and fast rule, but is more a guideline to allow for increased readability.

10.2.1 Legibility vs. Readability

Legibility is the ease with which the font can be read out of context, considering just the typeface itself; readability is the ease of reading on the page, in context of the surroundings. From Wikipedia: Legibility is the quality of the typeface design and readability with the design of the printed page. Designers aim to achieve excellence in both.

10.3 Glyphs

Use proper glyphs, in their proper places and code them correctly:

There are a number of less well known glyphs on the web, which are often replaced with glyphs which are technically incorrect. The most common examples are:

  1. The use of &quot; (") instead of &ldquo; / &rdquo; (“ / ”). The former are in fact ‘prime marks’ — the latter are proper, matching quote marks.
    Prime marks are used to donate feet and inches or minutes and seconds, for example: 6'4" equates to six feet four inches (or six minutes and five seconds).
  2. The use of '' ('') instead of &lsquo; / &rsquo; (‘ / ’). As above.
  3. The use of ... (...) instead of &hellip; (…). An ellipsis is commonly mistaken for three full-stops, when in actual fact it is a whole character unto itself.
  4. The use of the hyphen (-) when a dash is needed. There are three types of dash: &mdash; / &ndash; / - ( —  / – / -). Read the correct uses of each.

Top ↑

11.0 Tips, Tricks & Hacks

11.1 Min-height Fast Hack

Courtesy of Dustin Diaz comes the Min-Height Fast Hack — a way of getting round IEs lack of support for the min-height declaration.

This takes advantage of IE also lacking support for the !important CSS:

selector {
  height:auto !important;

11.2 Float Clearing


As per §8.2, floats can be cleared by applying width and overflow to the container. This method applies to not only <div>s, but <ul>s, <span>s, and more.

11.3 Has Layout

One of the major causes of IE bugs is the IE only property ‘layout’. To combat this you can use any of the following CSS properties:

The most common way to give layout to an element is usually:

#element { height:1%; }


11.4 Conditional Classnames

A brief word on conditional classnames by Paul Hammond — a way round (multiple) IE specific stylesheets.

Top ↑

12.0 Miscellanies


Different comments for different purposes

If you are using comments to prevent data being displayed on screen, are commenting something out to avoid physically deleting it or are leaving notes for yourself/other developers who will be working on the project in the future, it is better practice to use server-side comments so as to prevent users seeing data in the source code (this is particularly true of comments to prevent markup display). PHPs commenting style is as follows:

// Single line commented out

# Single line commented out

Multiple lines
commented out

ASP.NETs comment format follows this pattern:

Multiple lines
commented out

Both of these will prevent anything between the comment tags being passed to the browser. These should be used where possible.

Regular HTML comments can however be used where data needs to be visible in the source code for users, but not in the page itself. Examples include disclaimers, copyright notices, and details about the developer(s):

<!-- © Company 2012 -->

<!-- Designed and developed by Harry Roberts - http://prdesign-studio.co.uk/ -->

Top ↑

Dev. Notes

A note on IE6

Web Design+ site is fully accessible in Internet Explorer 6, however some of the more specific aspects are not fully supported. For example IE6 has some pretty funky issues with lists and also does not (for some reason) support hair spaces (&#8202;) which are used around em dashes.

I have decided not to iron out all these minor bugs because of putting common sense before hard work: Web Design+’s demographic is web developers. Most — if not all — web developers use more standards compliant browsers than IE6, so the issues do not effect them.

That said, the issues are that slight that you can safely and comfortably look at Web Design+ in IE6, should you want to.

Top ↑


Web Design+ is © Copyright Harry Roberts 2012, however the content is copyright of its respective owner(s).

The ideas, tips and suggestions outlined in Web Design+ may not be the best and most up-to-date solutions available, and there may be alternatives. If you know of better solutions or disagree with something please do let me know. Web Design+ is intended for ‘starting out’ web developers who want to learn decent standards from the start. Web Design+ is constanly growing so if you disagree with anything or have anything to add/amend/update feel free to drop me a line.

The idea of Web Design+ is to redistribute and share the contents as widely as possible, but please exercise caution when reusing code and techniques found here. If you are unsure, please ask.

Top ↑