Roger Johansson, 456 Berea Street
Warning! Old content ahead. The latest update was 2008-11-01.
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.
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.
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.
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?
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.
A complete course on Web Standards.
A W3C document on how to improve the code quality of your website.
Mission statement for The Web Standards Project.
The Web Standards Project’s a thorough explanation of web standards and why using them is a good thing.
A Netscape DevEdge article on how a company can make money by using web standards.
A Web Standards Project article aimed at stakeholders from the marketing, communication and IT departments.
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.
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.
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.
<ul>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ul>
<ol>
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
</ol>
<dl>
<dt>website</dt>
<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>
</dl>
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="http://www.w3.org/TR/REC-html40/ 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="http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html">
<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>
</blockquote>
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>
<thead>
<tr>
<td> </td>
<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>
</tr>
</thead>
<tbody>
<tr>
<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>
</tr>
<tr>
<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>
</tr>
</tbody>
</table>
| 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.
The slides used at a presentation that was held at Seybold 2003.
An excellent resource for learning the reasoning used to figure out how to mark up something in a semantic way.
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.
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):
Always use lower case, and quote all attributes: All element and attribute names must be in lower case. All attribute values must be quoted.
Incorrect: <A HREF="index.html" CLASS=internal>
Correct: <a href="index.html" class="internal">
Close all elements: In HTML, some elements don’t have to be closed. Such elements are automatically closed when the next element starts. XHTML does not allow that. All elements must be closed, even those that have no content, like img.
Incorrect: <li>Item 1Correct:
<li>Item 1</li>
Incorrect: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Correct: <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
Incorrect: <br>
Correct: <br />
Incorrect: <img src="image.jpg" alt="">
Correct: <img src="image.jpg" alt="" />
Attributes can not be minimized: In HTML, certain attributes can be minimized. XHTML does not allow this.
Incorrect: <input type="checkbox" id="checkbox1" name="checkbox1" checked>
Correct: <input type="checkbox" id="checkbox1" name="checkbox1" checked="checked" />
Don’t use deprecated elements: Some elements and attributes that are allowed in HTML 4.01 Transitional and XHTML 1.0 Transitional are deprecated in XHTML 1.0 Strict (and in HTML 4.01 Strict). A few examples are font, center, alink, align, width, height (for some elements), and background.
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:
img, link, and input)html, head, body, and tbody)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 HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
For more detailed information about Doctypes, see my Opera Web Standards Curriculum article Choosing the right doctype for your HTML documents.
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:
<?php
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; charset=ISO-8859-1">
The Web Standards Project asks the W3C if you should use HTML or XHTML, and why.
An A List Apart article on the transition from HTML to XHTML.
A good explanation of how to use XHTML and CSS.
The W3C explains the difference between XHTML 1.0 and HTML 4
The Web Standards Project asks the W3C which MIME type should be used for HTML and XHTML, and why.
A summary of which media types should be used for serving XHTML documents.
HTML Dog’s guide to the elements and attributes you should not use in XHTML.
A document on MIME types and how to do content negotiation with different server side scripting languages.
A W3C document on mime types and XHTML.
An A List Apart article on how to use doctype, and why.
A summary of how different doctype declarations affect browsers that have doctype switching.
The W3C’s official list of correct doctype declarations.
The Web Standards Project asks the W3C how authors should specify character encoding.
An article on different character encodings.
An explanation of how to use national and special characters in HTML documents.
A tutorial on how to choose and declare a character encoding.
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.
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.
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 {
font-size:2em;
}
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';
</style>
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 {
font-size:2em;
}
</style>
This should also be avoided, since it is best to keep HTML and CSS in separate files.
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 {
color:#0f0;
font-weight:bold;
}
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.
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:
<h3><em>Headline</em></h3>
If you want to make the headline italic, use CSS to restyle the h3 element:
h3 {
font-style:italic;
}
Superfluous usage of classes can look like this:
<div id="nav">
<ul class="navlist">
<li class="navitem">
<a class="navitemlink">Lorem ipsum dolor</a>
</li>
</ul>
</div>
This will do fine:
<div id="nav">
<ul>
<li>
<a>Lorem ipsum dolor</a>
</li>
</ul>
</div>
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.
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.
Validate first: When debugging, start by validating both HTML and CSS. Many problems can be caused by invalid code.
Test in the most advanced browser first, then make it work in the others: If you’re using an old browser with a bad and/or erroneous implementation of CSS while you’re testing, your CSS will be adapted to that browser’s implementation. When you test in a more advanced browser, chances are things will not look the way you intended. It’s better to first make it work in the most standards compliant browser, and then worry about less able browsers.
In other words, do not use Internet Explorer as a reference.
Understand the CSS box model: To get an element’s actual width or height, you add its padding
and its border to its width or height. In Internet Explorer 5.*/Win (and later versions of IE when they use quirks mode), padding and border are included in the supplied width or height.
Suppose you have the following CSS:
.box {
width:300px;
padding:20px;
border:10px solid;
}
The total width of the elements this rule is applied to is 360px.
10px + 20px + 300px + 20px + 10px = 360px
In Internet Explorer 5.*/Win, the total width is 300px, and the width of the content is 240px.
300px - 10px - 20px - 20px - 10px = 240px
To work around this problem, you can either use a CSS hack to feed different values to the browsers that get this right and those who get it wrong, or you can avoid specifying both width and padding or border for an element.
For more thorough explanations of the CSS box model, see Box model and Internet Explorer and the CSS box model.
Specify units for numerical, non-zero values: CSS requires that units are specified for properties like width, height, and font-size. An exception from this is when the value is 0 (zero). In that case, no unit is necessary, since zero is zero, no matter what the unit is.
Understand floats: The concept of floats can be hard to understand, but is very important since it is frequently used to in CSS based layouts. Some very good articles on floats are Containing Floats, Floatutorial, and Float Layouts.
“LoVe’s Hurts Fade Away”: Define pseudo classes for links in the order Link, Visited, Hover, Focus, Active. Eric Meyer explains why the order matters in Link Specificity, Ordering the Link States, and Who Ordered the Link States?.
“TRouBLed”: When using shorthand to specify an element’s margin, padding or border, do it clockwise from the top: Top, Right, Bottom, Left.
Name classes and IDs by their function, not by their presentation: If you call a class .smallblue, and later decide to make the text big and red, the class name will be confusing. It’s better to use names that describe function or structure, like .copyright or .important.
Case sensitivity: Values of the HTML attributes class and id are case sensitive when used with CSS (see CSS2 syntax and basic data types).
Element names are case sensitive when used with XHTML served as XML, but not when used with HTML or with XHTML served as text/html.
Check your IDs: Only one element in a document can have a certain value for the id attribute, while any number of elements can share the same class name.
Use only allowed characters for class and id: Class and id names can only consist of the characters [A-Za-z0-9], hyphen (-), and underscore (_), and they cannot start with a hyphen or a digit (see CSS2 syntax and basic data types).
Comment correctly: CSS comments start with /* and end with */:
/* This is a comment */
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.
Eric Meyer describes four ways of hiding CSS from certain browsers.
A large collection of techniques that can be used to hide CSS from browsers.
A document on different ways of enhancing the experience for people using a modern browser.
An explanation of, among other things, CSS import and media types.
With the help of his readers, Dave Shea has made a list of practical CSS tips.
John Gallant and Holly Bergevin explain how to write compact CSS.
A very good explanation of different CSS selectors and how they work.
An example of how to create a simple layout with a header, two columns, and a footer.
A collection of links to different CSS layouts.
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:
robots.txt to tell search engines not to index sub pages. On other sites, JavaScript is used to send anyone who arrives at the site from a search engine to the homepage. Both of these methods may work if your goal is to get fewer satisfied visitors.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.
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 TheCounter.com, 6% of web users have no JavaScript. W3Schools.com 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.
A WebAIM article on accessible forms.
An article that goes through the basics of building better, more accessible forms.
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:
http://example.com/products.asp?item=34627393474632&id=4344
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:
http://example.com/products/item/34627393474632/id/4344/
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:
http://example.com/products/flowers/tulips/
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, &. 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 http://example.com/ to http://www.example.com/ or vice versa.
An article that explains the problems with certain kinds of URLs, and how to make your URLs better.
An article on why ending URLs with “/” is good.
A collection of links to articles and tutorials on URLs.
A longer explanation of the problems with unencoded ampersands in query strings, and a test case.
A selection of recommended books, websites and mailing lists.
A project based book that explains how to use CSS.
The sequel to the first Eric Meyer on CSS.
A reference book that explains the CSS recommendations.
A thorough book on accessibility and how to build accessible websites.
The W3C’s official specification.
The W3C’s official specification.
A mailing list devoted to talking about practical uses and applications of CSS.
A website with a large collection of HTML and CSS tutorial, references, and articles.
A large amount of examples of how to use CSS to style the same HTML document in completely different ways.
Several very well-written articles on CSS.
Articles, demonstrations, browser bugs, and more.
A weekly online magazine with articles that explore the design, development, and meaning of web content, with a special focus on techniques and benefits of designing with web standards.
A mailing list for those involved in creating the web. Most things related to web design and web development is discussed on the list.
The W3C’s official specification.
A website with a large collection of HTML and CSS tutorial, references, and articles.
Joe Clark’s accessibility book in online format.
Mark Pilgrim’s book on accessibility.
The W3C’s official guidelines for accessible websites.
The W3C’s collection of information on tools to evaluate and improve the accessibility of websites.
“The Web Standards Project is a grassroots coalition fighting for standards that ensure simple, affordable access to web technologies for all.”
Dave Shea’s guide for anyone who wants to start using web standards.
The W3C’s official specification.
A website with a large collection of HTML and CSS tutorial, references, and articles.
Comments, questions or suggestions? Please let me know.
© Copyright Roger Johansson