1. Introduction
  2. History
  3. Web Standards
  4. Structure and presentation
  5. (X)HTML
  6. CSS
  7. Accessibility
  8. URLs
  9. References
  10. Glossary

1. Introduction

This document attempts to explain how and why using web standards will let you build websites in a way that saves time and money for developers and provides a better experience for visitors. Also discussed are other methods, guidelines and best practices that will help produce high-quality websites that are accessible and usable to as many people and browsing devices as possible.

2. History

When the Internet and the Web became mainstream in the second half of the nineties, web browser vendors had not yet implemented CSS (Cascading Style Sheets) well enough for web developers to be able to use it to control the presentation of an HTML document. The lack of implementation is partly understandable considering that the specification for CSS Level 1 was published in 1996 and the specification for CSS Level 2 in 1998.

The lack of CSS support in web browsers, combined with demands from graphic designers used to the level of control that is possible when working with printed material, led to the abuse of HTML in any way possible to control the visual presentation of a web page.

One example of this is the major “breakthrough” that was made when designers discovered that by using the attribute border="0" to hide the borders of an HTML table, an invisible grid that could be used to control layout was created. Another example is the use of transparent, and thus invisible, images called “spacer GIFs” to control spacing and margins.

Since HTML was never meant to be used to control the presentation of a document, hacks, invalid code, and vendor-specific elements and attributes were (and still are) used. Validation was something that very few knew about or used. Tag soup is a very descriptive name for this kind of HTML-like code.

As new versions of web browsers were released, CSS support was improved and extended, but not at the rate it should have been. However, despite browser vendors being slow to implement CSS properly, we have now reached a point where web browsers with good CSS support are being used by so many that there is no longer any reason not to use HTML the way it was meant to be: to describe the structure and content of a document, not its presentation. For that, we can now use CSS, which was designed specifically for that purpose.

3. Web standards

What are web standards?

Web standards are technologies, established by the W3C and other standards bodies, that are used to create and interpret web-based content. These technologies are designed to future-proof documents published on the Web and to make those documents accessible to as many people and devices as possible.

Structural languages

Presentation languages

Object Models

Scripting languages

This document focuses on HTML 4.01 Strict for structure, CSS Level 1 and Level 2 for presentation, and JavaScript for scripting (not that there are a lot of scripting examples).

When a document is said to adhere to web standards, it means that the document, besides using the above technologies:

Note that “works in any web browser” does not mean “looks the same in every web browser”. Making a document look identical across browsers and platforms is next to impossible. Not even using only images will make a website look exactly the same everywhere.

Documents that are published on the web will be accessed by a wide variety of browsing devices on several operating systems, with monitors of differing size and quality (or no monitor at all), by users who may have changed their browser’s default text size and other preferences.

Realising this and accepting that you simply cannot fully control the visual appearance of a website in your visitors’ browsers will make your life a lot less frustrating. Anyone who creates websites needs to understand that there are technical prerequisites to consider, the same way as those who publish on paper or make movies or television have other prerequisites to consider.

Do websites need to look exactly the same in every browser?

Why use web standards?

Some web developers and web designers have a resistance towards using web standards. Common arguments are It’s too difficult, It works anyway, and The tools I use create invalid code.

It’s easy to react emotionally and build up a resistance towards learning something new and abandoning techniques you know and feel comfortable with. However, if you look at the situation logically you will see that there are many benefits to learning and using web standards. Here are a few:

Using web standards saves time and money for website creators and in general provides a better experience to the website’s visitors.


Validation is the process of controlling that a document adheres to the rules of the programming language used in the document. You can compare it to checking a text you have written for spelling errors.

Quality assurance through validation is an important part of web development. Many errors that are hard to spot manually are discovered during validation. An error can be as trivial as a typo or as serious as an element or attribute being used in an invalid way. It can also have absolutely no effect on the way the document is rendered in a web browser or completely mess it up.

Unfortunately, many people don’t validate their documents. Some people may not know about validation, others forget to validate, and there are those who intentionally avoid validating. I think this situation can largely be blamed on web browser vendors. Most web browsers attempt to interpret invalid HTML as best they can and try to guess what the author’s intention is instead of displaying an error message. It is understandable that web browsers want to do that, but this error tolerance is undoubtedly one major reason for the sloppy markup that is very common today.

Why we won’t help you is Mark Pilgrim’s excellent explanation of the advantages of validation. The article also explains why it may be harder to get help from people on discussion forums and mailing lists if you haven’t validated your documents before asking for help.

Some HTML editors have built-in validation tools or will use the W3C’s validation services, available online. You can also use the W3C’s validation services manually:

Another excellent tool for checking the validity of the HTML you create is the HTML Validator extension for Firefox.

Understanding the error messages generated by the validators can be a little tricky. An error early on in a document may cause several additional errors. By fixing the first error and revalidating you will often greatly reduce the number of errors.

It is important to realise that validity alone does not mean that your document is accessible. Neither do a few validation errors necessarily make your document inaccessible or incompatible. That said, you should always aim for fully valid code and have a very good reason (such as improving accessibility for people with disabilities) for any errors you decide to leave in. If the tools (code editors, frameworks, WYSIWYG editors, content management systems) you use generate invalid markup, those tools are broken and need to be fixed.

Further reading

4. Structure and presentation

When discussing web standards, something that is mentioned a lot is the importance of separating structure from presentation. Understanding the difference between structure and presentation can be difficult at first, especially if you’re used to not thinking about the semantic structure of a document. However, it’s very important to understand this, since controlling the presentation of a document with CSS becomes much easier if structure and presentation are separated.

Structure consists of the mandatory parts of an HTML document plus the semantic and structured markup of its contents.

Presentation is the style you give the content. In most cases presentation is about the way a document looks, but it can also affect how a document sounds – not everybody uses a graphical web browser.

Separate structure from presentation as much as possible. Ideally you should end up with an HTML document which contains the structure and content, and a separate CSS file which contains everything that controls presentation.

Tables for layout

In order to separate structure from presentation you need to use CSS instead of tables to control the presentation of a document. When you’re used to using tables for layout, this can feel uncomfortable and strange, but it isn’t as difficult as it may seem at first. There’s plenty of help available on the Web, and the advantages are so many that it definitely is worth taking the time to learn the different way of thinking that is required.

Semantic HTML

Another important part of separating structure from presentation is using semantic markup to structure the document’s content. When an HTML element exists that has a structural meaning suitable for the part of the content that is being marked up, there is no reason to use anything else. In other words, do not use CSS to make an HTML element look like another HTML element, for instance by using a span element instead of an h1 element to mark up a heading.

By using semantic HTML, you will make the different parts of a document meaningful to any web browser, be it the very latest graphical web browsers on a modern PC, an old web browser that doesn’t handle CSS, a text-based browser in a Unix shell, or assistive technology used by people with disabilities.


To mark up headings, use h1 - h6 elements. h1 is the highest level and h6 the lowest.

<h1>Document heading</h1>
<h2>Sub heading</h2>


Use the p element to mark up paragraphs. Do not use br elements to create space between paragraphs. Margins between paragraphs are better handled by CSS.

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing
elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing
mollis neque. Aliquam in nulla.</p>


A list of things should be marked up as a list. There are three different kinds of lists in HTML: unordered lists, ordered lists, and definition lists.

Unordered lists, also known as bulleted lists, start with <ul> and end with </ul>. Each list item is contained in an li element.

Ordered lists start with <ol> and end with </ol>.

Definition lists are a little different. They are used to mark up a list of terms and descriptions. Definition lists start with <dl> and end with </dl>. The terms that are being described are contained in dt elements, and descriptions are contained in dd elements. Each group of terms and definitions can consist of one or more dt elements followed by one or more dd elements.

    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
    <li>Item 1</li>
    <li>Item 2</li>
    <li>Item 3</li>
  1. Item 1
  2. Item 2
  3. Item 3
    <dd>A collection of linked web pages that represent a company
    or an individual.</dd>
    <dt>web page</dt>
    <dd>The basic unit of information on the Web, containing text,
    graphics and other media.</dd>
A collection of linked web pages that represent a company or an individual.
web page
The basic unit of information on the Web, containing text, graphics and other media.

CSS makes it possible to use lists even when you don’t want their content to be presented as a traditional list. A navigation bar, which is a list of links, is a good example of this. The advantage of using a list for a menu is that the menu will make sense even in browsers that don’t support CSS.


The q element should be used for shorter, inline quotations. Web browsers are supposed to automatically render quotation marks before and after the content of the q element. Unfortunately, Internet Explorer doesn’t, and in some cases the q element can even cause accessibility problems. Because of this, some recommend that you avoid using q, and insert the quotation marks manually. Containing inline quotes in span-elements with a suitable class allows the use of CSS for styling quotes, but has no semantic value. Read Mark Pilgrim’s The Q tag for a detailed look at the problems with the q element.

For longer quotations that form one or more paragraphs, the blockquote element should be used. CSS can then be used to style the quotation. Note that text is not allowed directly inside a blockquote element – it must be contained in a block level element, usually a p element.

The cite attribute can be used with both q and blockquote elements to supply a URL for the source of the quotation. Note that if you use span elements instead of q elements for inline quotations, you cannot use the cite attribute.

<p>The W3C says that <q cite="
struct/text.html#h-9.2.1">The presentation of phrase elements
depends on the user agent.</q>.</p>

The W3C says that The presentation of phrase elements depends on the user agent..

<p>The W3C says that <span class="quote">“The presentation of
phrase elements depends on the user agent.”</span>.</p>

The W3C says that “The presentation of phrase elements depends on the user agent.”.

<blockquote cite="">
    <p>The following sections discuss issues surrounding
    the structuring of text. Elements that present text (alignment
    elements, font elements, style sheets, etc.) are discussed
    elsewhere in the specification. For information about characters,
    please consult the section on the document character set.</p>

The following sections discuss issues surrounding the structuring of text. Elements that present text (alignment elements, font elements, style sheets, etc.) are discussed elsewhere in the specification. For information about characters, please consult the section on the document character set.


The em element is used for emphasis and the strong element for strong emphasis. Most web browsers display emphasized text in italics, and strongly emphasized text in bold. However, this is not a requirement. Avoid using emphasis when all you really want is the visual effect of bold or italic text.

<p><em>Emphasized</em> text is normally displayed in italics,
while <strong>strongly emphasized</strong> text is usually
displayed in bold.</p>

Emphasized text is normally displayed in italics, while strongly emphasized text is usually displayed in bold.


HTML tables should not be used for layout. For marking up tabular data, however, tables are what should be used. To make data tables as accessible as possible it is important to know about and use the various components that can make up a table. A few examples are table headings (the th element), summaries (the summary attribute), and captions (the caption element).

<table class="example" summary="The Swedish population increased
by approximately 115 000 between 1999 and 2003.">
    <caption>Annual population increase in Sweden, 1999–2003</caption>
            <th scope="col">1999</th>
            <th scope="col">2000</th>
            <th scope="col">2001</th>
            <th scope="col">2002</th>
            <th scope="col">2003</th>
            <th scope="row">Population</th>
            <td>8 861 426</td>
            <td>8 882 792</td>
            <td>8 909 128</td>
            <td>8 940 788</td>
            <td>8 975 670</td>
            <th scope="row">Increase</th>
            <td>7 104</td>
            <td>21 366</td>
            <td>26 368</td>
            <td>31 884</td>
            <td>34 882</td>
Annual population increase in Sweden, 1999–2003
  1999 2000 2001 2002 2003
Population 8 861 426 8 882 792 8 909 128 8 940 788 8 975 670
Increase 7 104 21 366 26 368 31 884 34 882

For a more detailed description of tables and their use, see Bring on the tables, Tables in HTML documents and HTML Techniques for Web Content Accessibility Guidelines 1.0.

Further reading

5. (X)HTML

XHTML 1.0 is a reformulation of HTML 4 in XML 1.0 and was developed to replace HTML. However, there is nothing preventing you from using HTML 4.01 to build modern, standards compliant, and accessible websites. Whether you use HTML 4.01 or XHTML 1.0 doesn’t really matter all that much.

What is more important is to properly separate structure from presentation. Strict doctypes allow less presentational markup and enforce separation of structure from presentation, so I recommend using HTML 4.01 Strict or XHTML 1.0 Strict.

XHTML 1.1, which is the latest version of XHTML, is technically a bit more complicated to use, since the specification states that XHTML 1.1 documents should have the MIME type application/xhtml+xml, and should not be served as text/html. It isn’t strictly forbidden to use text/html, but it is not recommended.

XHTML 1.0 on the other hand, which should use application/xhtml+xml, may also use the MIME type text/html, if it is HTML compatible. The W3C Note XHTML Media Types contains an overview of MIME types that are recommended by the W3C.

Unfortunately some older web browsers, and Internet Explorer, do not recognize the MIME type application/xhtml+xml, and can end up displaying the source code or even refuse to display the document.

If you want to use application/xhtml+xml you should let the server check if the browser requesting a document can handle that MIME type, and in that case use it, and use text/html for other browsers.

This is called “content negotiation”. Instead of going into details about it here I refer you to the following writeups:

Note that when the MIME type is application/xhtml+xml, some browsers, for example Firefox, will not display documents that aren’t well-formed. This can be a good thing during development since it immediately makes you aware of some markup errors. However it may cause problems on a live site that gets updated by people who are not XHTML experts, unless you can ensure that all code stays well-formed. If you cannot guarantee well-formedness you should probably avoid content negotiation and use HTML 4.01 or “HTML compatible” XHTML 1.0 instead.

Differences between XHTML 1.0 Strict and HTML 4.01 Transitional

Here is a list of the things that are most important to consider when using XHTML 1.0 Strict instead of HTML 4.01 Transitional (or no-name, plain old invalid HTML):

Recommended rules for HTML 4.01

I recommend sticking to most of these rules even if you are writing HTML 4.01. Doing so makes the markup much easier to read and maintain, and has become a widely used convention. So when writing HTML 4.01:


The doctype, or DTD (Document Type Declaration), used to be more decorative than functional, but for quite a few years now the presence of a doctype has been able to greatly affect the rendering of a document in a web browser.

All HTML and XHTML documents must have a doctype declaration to be valid. The doctype states what version of HTML or XHMTL is being used in the document. The doctype is used by the W3C markup validator when checking your document and by web browsers to determine which rendering mode to use.

If a correct and full doctype is present in a document, most web browsers will switch to standards mode, which among other things means that they will follow the CSS specification closer. This will reduce the difference in rendering between browsers.

The following doctypes will will make the web browsers that have “doctype switching” use their standards mode:

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

For more detailed information about Doctypes, see my Opera Web Standards Curriculum article Choosing the right doctype for your HTML documents.

Character encoding

All XHTML documents should specify their character encoding. If you don’t, the browser will have to guess which character encoding to use. If it guesses wrong your visitors may have a hard time reading the text on your website.

The best way of specifying the character encoding is to configure the web server to send an HTTP content-type header with the character encoding. For detailed information on how to do this, check the documentation for the web server software you are using.

If you’re using Apache, you can specify the character encoding by adding one or more rules to your .htaccess file. For example, if all your files use utf-8, add this:

AddDefaultCharset utf-8

To specify a character encoding for files with a certain filename extension, use this:

AddCharset utf-8 .html

If your server lets you run PHP scripts, you can use the following to specify the character encoding:

    header("Content-Type: text/html; charset=utf-8");

To serve your pages as XHTML, change text/html to application/xhtml+xml. If you, for whatever reason, are unable to configure your web server to specify the character encoding you are using properly, use a meta element as the first child of the document’s head element. It’s a good idea to specify the character encoding this way even if your server is configured correctly.

For example, the following meta element tells the browser that a document uses the ISO-8859-1 character encoding:

<meta http-equiv="content-type" content="text/html;

Further reading

6. CSS

In the early days CSS was used mostly to specify font properties. CSS support in browsers has been mature enough for several years now that it can be used to control the entire layout of a document. However, to do this efficiently requires a somewhat different approach than when tables are used to control layout.

Structured, semantic XHTML is necessary for CSS to be able to control layout in an efficient way.

Browser support

As mentioned earlier, browser support for CSS has improved a lot in the last few years. Unfortunately all browser vendors haven’t been equally interested in implementing CSS fully and properly, so the level of support varies from browser to browser. On top of that there are software bugs that make browsers act in ways they shouldn’t be.

Currently (2008), the web browsers that have the best CSS support are:

Internet Explorer doesn’t yet (as of version 7.0) have the same level of CSS support, but it will let you do most of the basic stuff, though often in a buggy way.

Since currently a majority of people use Internet Explorer for Windows you will often have to let that browser be the lowest common denominator. That does not mean that you cannot or should not use the abilities of browsers with better CSS support to enhance the design for them. Doing so is fine as long as it does not make your site unusable to people using less capable browsers.

It’s important to stress that people using old (obsolete) browsers and browsers that by design do not support CSS must not be locked out. In the nineties, browser sniffing was a popular way of redirecting people using the “wrong” browser (normally anything but Internet Explorer for Windows) to a page that told them to upgrade their browser to gain access to the site.

These days you can handle unsupported browsers in a better way. One big advantage of using logical, semantic HTML is that it makes documents accessible and usable even without CSS. The presentation – the way the document looks – won’t be the same as in a supported browser, but the content will be there. In most cases, for most visitors to a site, the content is actually more important than the way it is presented. That’s why it is better to send an unstyled page to unsupported browsers than to lock them out of the site.

There are different ways of doing that. One of the most common ways is to use @import to link to the associated CSS file. Netscape 4 and older browsers don’t understand @import and will not import the CSS file.

There are plenty of ways to hide certain CSS rules from web browsers. The thing most methods (“CSS hacks”) for hiding CSS have in common is that they are based on bugs in the way browsers interpret CSS code. This means that there will always be a risk that a browser update fixes the bug that is used to hide CSS from it, but not the CSS problem that was the reason for hiding certain CSS from that browser. So the less you rely on CSS hacks, the better.

Obviously you can use server side technology to do a browser check and then send different CSS files (or none at all) to different browsers. If you do that you will have to make sure the detection script is kept current to avoid sending the wrong CSS file when a browser is updated or a completely new browser is released. You should also know that browser sniffing is fragile and error-prone since there is no guarantee that the browser is what it claims to be.

Different ways of applying CSS

There are several ways of applying CSS to elements in an HTML document.


There are several advantages to keeping all CSS rules in one ore more separate files. The HTML documents become smaller, CSS files are stored in the browser cache and will only need to be downloaded once, and you only need to edit a single file to change the presentation of an entire website. An external CSS file can look like this:

h1 {

Note: there should be no style element in an external CSS file.

You can link a CSS file to an HTML document by using a link element:

<link rel="stylesheet" type="text/css" href="styles.css">

or by using an @import rule in a style element:

<style type="text/css">
    @import 'styles.css';


By using the style attribute, you can apply CSS directly to an HTML element:

<h1 style="font-size:2em;">Heading</h1>

This should be avoided since it mixes structure and presentation.


Internal CSS is contained in a style element, which in turn belongs in the document’s head element:

<style type="text/css">
h1 {

This should also be avoided, since it is best to keep HTML and CSS in separate files.

CSS Syntax

A CSS rule consists of a selector and one or more declarations. The selector determines which HTML element or elements the rule affects. Each declaration consists of a property and a value. The declaration block is surrounded by { and }, and each declaration ends with a ; (semicolon).

A simple CSS rule looks like this:

p {

In this case, p is the selector, which means that the rule will affect all p elements in the document. The rule has two declarations which together will make the text in all p elements green and bold.

For a more detailed description of CSS rules, see for example CSS Beginner’s Guide, CSS from the Ground Up or a CSS book.

Superfluous elements and classes

When starting out with CSS, it’s common to make the mistake of using unnecessary HTML elements, superfluous classes, and extra div elements. This doesn’t necessarily mean that the code will be invalid, but it counteracts one of the reasons of separating structure from presentation; to get simpler, cleaner markup.

An example of using unnecessary HTML elements:


If you want to make the headline italic, use CSS to restyle the h3 element:

h3 {

Superfluous usage of classes can look like this:

<div id="nav">
    <ul class="navlist">
        <li class="navitem">
            <a class="navitemlink">Lorem ipsum dolor</a>

This will do fine:

<div id="nav">
            <a>Lorem ipsum dolor</a>

To control links in the div element with the id nav you can use descendant selectors in the CSS code. In this case it could look like this:

#nav a {
    /* rules */

In many cases CSS can be used to style logical HTML the way you want without having to add any extra markup. However, there are cases when adding some extra code is worth it.

CSS tips

Obviously, once you start using CSS seriously, you will eventually run into problems of some kind. Some problems may be caused by misunderstandings, others by unclear specifications or buggy browsers.

The CSS Crib Sheet is a collection of good advice, compiled by Dave Shea. Here are some of the most important tips plus a few more that aren’t in the CSS Crib Sheet.

CSS Layouts

There are many examples and step-by-step tutorials on how to use CSS for layout. A good advice is to start with a simple layout, learn how it works, and then move on to more advanced layouts.

Further reading

7. Accessibility

The way I see it, web accessibility is not only about supporting disabled visitors, though making the web more usable for people with disabilities is one of the most important reasons for making a website accessible. An accessible website works better for everybody, disabled or not, and can be accessed by more people with more kinds of web browsers and other browsing devices.

A common misconception is that by making a website accessible, it will look less attractive than, or different to, a website that is not accessible. That is not the case. Accessibility does not need to affect presentation at all.

Here’s an example of how accessibility can help everybody:

A website has a form which can be used to register for a seminar. In the form, you can choose to attend the seminar in one of three cities. Each city name is next to a radio button. If the creator of the form didn’t have accessibility in mind, anyone using a graphical browser has to place their cursor on the tiny radio button and click in order to choose a city. If the developer knows about accessibility and has marked up the labels next to each radio button with the label element, you will also be able to click on the city names to choose a location.

Which way would you say is simpler for anyone using the form?

There are many other considerations, but using semantic, well structured HTML will take you a long way towards an accessible website. To get a basic idea of how accessible a document is, try viewing it in a text-based browser like Lynx to see if the content still makes sense. Again, this is far from the only accessibility check you need to do, but it’s a good start.


Many web designers like using frames to divide the browser window into several independent parts, each consisting of a separate HTML document. This may be useful for something like an Intranet application. On a public website, however, there are many drawbacks to using frames:

Besides, you are making things harder on yourself. Frames make a website more technically complex and harder to maintain.


It’s pretty common for people to interpret “don’t use tables for layout” as “don’t use tables at all”. That is not how it should be interpreted. If what you’re marking up is tabular data, it belongs in a table, so a table is what you should use. However, it is important to know that when building data tables, there are many ways to make them more logical and accessible. I explain how to create accessible tables in Bring on the tables.


Forms are often unnecessarily difficult to use, partly because they are built in illogical ways, partly because the underlying HTML code isn’t using the elements that exist to make forms more accessible and easier to use. The elements label, fieldset and legend exist and are meant to be used. See my article Use the label element to make your HTML forms accessible for more information on the label element.

I advise against using tables to layout forms since forms are generally not tabular data. If you must use a table, make sure the form makes sense and is usable when the table containing the form is linearized.

JavaScript and cookies

Avoid depending on JavaScript. More people than you might think have JavaScript turned off in their browser, be it for security reasons or to avoid pop-up windows. They may also be using a browser which doesn’t support JavaScript. According to, 6% of web users have no JavaScript. reports 5%.

In many cases where JavaScript is being used it doesn’t actually benefit the visitor. Of course there are cases where JavaScript can be used to provide a better experience. One example is validating form input.

Note that this does not mean that you should avoid using JavaScript. It does mean that you should avoid making a website depend on JavaScript to work.

The same thing goes for cookies. Do not use cookies in a way that makes the web site stop working if the visitor doesn’t accept them.

Further reading

8. URLs

This section isn’t really about web standards or accessibility, but it’s here because the way a URL is constructed can have a great effect on how well a website is indexed by search engines, and how usable it is to its visitors.

Some search engine robots don’t follow links to URLs that end in a query string. This kind of URL is very common on websites that dynamically get their content from a database, and may look like this:

The easiest way to construct a URL that is better for both search engine robots and humans is to change it to look like it is pointing to a directory. The above example would then be changed to look like this:

The web server then interprets the new URL and internally converts it back to the original URL, complete with the query string. At the end of this section are some links to sites where more info on how to do this can be found.

It should be noted that in 2008, Google announced that they prefer URL:s with query strings to URL:s that have been rewritten this way. More details on that are available in the Google Webmaster Central Blog article Dynamic URLs vs. static URLs.

An even better, but somewhat more complicated, way of changing URLs is to completely rewrite the visible URLs to make them human readable:

The main advantages to using this kind of URL are that it becomes easier for humans to read the URL and you avoid revealing which server technology you’re using. Since the URLs don’t contain server specific file extensions, like .asp, .cf, .cgi or .jsp, this will also make it easier to change the technology used on the server, should that become necessary.

If you choose to use query strings in your URLs, it’s important to encode any ampersands, &, to their HTML entity, &amp;. If you don’t, web browsers will interpret the ampersand as the start of an HTML character entity or reference. If the text following immediately after the ampersand matches an HTML entity, the browser will convert the URL and probably break the query string. Validating your HTML will catch these errors since unencoded ampersands are illegal.

Another thing worth mentioning is that you should make sure your website works with or without www. Whether you use the www subdomain or not, it is a good idea to configure your web server to redirect any traffic to to or vice versa.

Further reading

9. References

A selection of recommended books, websites and mailing lists.



General web development



Web standards


10. Glossary

An accessible website is accessible and usable for everyone, regardless of any disabilities they might have and no matter what hardware and software they are using.
CSS (Cascading Style Sheets)
Rules that describe how an HTML document should be presented.
HTML (HyperText Markup Language)
Used to mark up the structure of a document.
The look (or sound) of a website.
The mandatory parts of a document plus the logical markup of the document’s content.
By marking up a document you give the document and its content structure and meaning. On the web, HTML and XHTML is used for markup.
Validation is the process of controlling that a document obeys the rules of the language used in the document. You can compare it to checking a text for spelling and grammatical errors.
W3C (World Wide Web Consortium)
An organization that develops specifications, guidelines, and tools for the Web.
Web standards
Web standards are technologies, established by the W3C and other standards bodies, that are used to create and interpret web-based content. These technologies are designed to future-proof documents published on the Web and to make those documents accessible to as many as possible.
XHTML (Extensible HyperText Markup Language)
HTML reformulated to follow the rules of XML.
XML (Extensible Markup Language)
A markup language that looks like HTML, but allows the author to describe data by defining suitable elements.

Comments, questions or suggestions? Please let me know.

© Copyright Roger Johansson