Translations of this article are available.
This document explains how and why using web standards will let you build websites in a way that saves time and money for the developer and provides a better experience for the visitor. Also discussed are other methods, guidelines and best practices that will help produce high-quality websites that are accessible to as many 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 was published 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. An example is the major breakthrough that was made when designers discovered that by using the attribute border="0" to hide the borders of a table, an invisible grid that could be used to control layout was created. Another example is the use of transparent, and thus invisible, spacer GIFs to control layout.
Since HTML was never meant to be used to control the presentation of a document, hacks, invalid code, and vendor-specific elements (tags) and attributes were used. Validation was something that very few knew about or used. Tag soup is a very descriptive name for this kind of code.
As new versions of web browsers were released, CSS support was improved and extended, but not at the rate it should have been. Despite browser vendors being slow to implement CSS, we have now reached a point where web browsers with reasonable 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 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 as possible.
This document focuses on XHTML 1.0 Strict for structure, CSS Level 1 and Level 2 for presentation, and ECMAScript 262 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. Accepting this 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.
Certain 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. A few examples:
Web standards can save time and money for website creators, and provide a better experience to the website’s visitors. Besides, web standards is the future. If you’re not using web standards already, now is the time to start, or you will risk being left behind.
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.
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.
Validation is an important part of web development. Many errors that are hard to find 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.
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. 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. This behaviour has led to the sloppy markup that is very common today. The problem with that kind of markup is that it gives unpredictable results and relies on the error handling of web browsers.
There is no reason not to validate your HTML and CSS. On the contrary. There are only benefits.
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.
Several HTML editors, like for instance BBEdit and Homesite, have built-in validation tools. If your development tool doesn’t have built-in validation, you can use the W3C’s validation services, available online:
Understanding the error messages generated by the validators can be a little tricky. An error early 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 always a good idea to make sure your code is fully valid, but there are a few occasions when some validation errors are difficult to avoid. The most common example is embedding Flash, or other content that requires a plugin, in a document. Read more about the problems with Flash in Flash Satay: Embedding Flash While Supporting Standards, and Embedding flash without <embed>.
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 a document, plus the semantic and structured markup of a document’s 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 have an HTML document which contains the structure and content, and control the presentation of the document entirely with CSS.
Separation of structure from presentation is not very common on the Web today. On most websites the HTML code lacks both structure and semantics.
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.
The slides used at a presentation that was held at Seybold 2003.
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, or a text-based browser in a Unix shell.
To mark up headings, use <h1>, <h2>, <h3>, <h4>, <h5> or <h6> depending on the heading level. <h1> is the highest level.
<h1>Document heading</h1> <h2>Sub heading</h2>
Use the <p> element to mark up paragraphs. Do not use the <br /> element to create space between paragraphs. Margins between paragraphs are handled by CSS, and requires paragraphs to be marked up correctly.
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Ed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.</p>
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec risus. Sed rhoncus sodales metus. Donec adipiscing mollis neque. Aliquam in nulla.
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, and can be used to mark up a list of terms and descriptions. Definition lists start with <dl> and end with </dl>. Each term that is being described is contained in a <dt> element, and the description is contained in 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 the list’s 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 an element, usually a <p> element.
The cite attribute can be used with both <q> and <blockquote> to supply a URL for the source of the quotation. Note that if you use <span> instead of <q> 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.”
<em> is used for emphasis, and <strong> for strong emphasis. Most web browsers display emphasized text in italics, and strongly emphasized text in bold. However, this is not a requirement, so to be sure how emphasized text is displayed, it is best to use CSS to specify their presentation. Avoid using emphasis when all you really want is a visual effect.
<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 (<th>), summaries (the summary attribute), and captions (the <caption> element).
<table class="example" summary="This table shows the annual population
increase in Sweden during the years 1999 to 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.
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. Note that there is nothing preventing you from using HTML 4.01 to build modern, structured, and standards compliant websites.
However, to make the transition to clean, semantic markup, and be better prepared for a possible transition to XML and other future markup languages, you may want to consider using XHTML 1.0 Strict. The choice is yours.
What matters more than if you use HTML or XHTML is that you use a Strict doctype and properly separate structure from presentation. Strict doctypes do not allow presentational markup, and enforce separation of structure from presentation.
XHTML 1.0 Strict is what is used in the examples in this document.
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.
If you’re using PHP for server side scripting, the following content negotiation script can be used to serve documents with different MIME types for different browsers:
<?php
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\"?>\n");
}
else {
header("Content-Type: text/html; charset=iso-8859-1");
header("Vary: Accept");
}
?>
The script checks if the user agent sends an Accept HTTP header that contains the value “application/xhtml+xml”, or if the user agent is the W3C HTML Validator, which does not send a proper Accept HTTP header but still handles application/xhtml+xml. If either of those are true, the document is served as application/xhtml+xml. Those browsers are also sent an XML declaration. To other browsers, including all versions of Internet Explorer, the document is served as text/html. No XML declaration is added to the document, since that would put IE/Win into Quirks mode, which we don’t want.
After the Content-Type header, a Vary header is sent to tell intermediate caches, like proxy servers, that the content type of the document varies depending on the capabilities of the client which requests the document.
For a more advanced PHP content negotiation script, visit Serving up XHTML with the correct MIME type. That script takes the requesting user agent’s q-rating (how well it claims to handle a certain MIME type) into account, and converts XHTML to HTML 4 before sending the document as text/html to user agents that don’t handle application/xhtml+xml.
Here is a similar script for those who use ASP and VBScript:
<%
If InStr(Request.ServerVariables("HTTP_ACCEPT"), "application/xhtml+xml") > 0
Or InStr(Request.ServerVariables("HTTP_USER_AGENT"), "W3C_Validator") > 0 Then
Response.ContentType = "application/xhtml+xml"
Response.Write("<?xml version=""1.0"" encoding=""iso-8859-1""?>" & VBCrLf);
Else
Response.ContentType = "text/html"
End If
Response.Charset = "iso-8859-1"
%>
Note that when the MIME type is application/xhtml+xml, some browsers, for example Mozilla, will not display documents that contain errors. This can be a good thing during development, but 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 valid. If that is the case, you may want to consider using HTML 4.01 Strict 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.
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
A summary of the differences between XHTML 1.0 Strict and Transitional
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.
Currently, very few HTML documents have a correct and full doctype, or DTD (Document Type Declaration). It used to be more decorative than functional, but starting a few years ago, the presence of a doctype can 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, and is used by the validator when validating, and by web browsers to determine which rendering mode to use. If a correct and full doctype is present in a document, many web browsers will switch to standards mode, which means that they will follow the CSS specification closer. The document will also render quicker because the browser doesn’t have to interpret and try to compensate for invalid HTML. This will also reduce the difference in rendering between browsers.
The following doctype declares that the document is XHTML 1.0 Strict, and will make the web browsers that have so called “doctype switching” use their standards mode.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
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.
All XHTML documents should specify their character encoding.
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: application/xhtml+xml; charset=utf-8");
?>
To serve your pages as HTML, change application/xhtml+xml to text/html. 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 in the document’s <head> section. 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 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.
Having been used mostly to specify font properties, CSS can now 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 been improved a lot in the last few years. Unfortunately all browser vendors don’t seem to be interested in implementing open standards, 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 (2004), the web browsers that have the best CSS support are Mozilla (and other browsers based on Gecko: Firefox, Camino, Netscape 6+), Opera and Safari (and other browsers based on WebCore: OmniWeb 4.5 and later). Internet Explorer 6/Win doesn’t have the same level of CSS support, but it will let you do most basic stuff. Internet Explorer 5/Mac has very good support for CSS 1, but it doesn’t support a lot of CSS 2. IE 5.* for Windows supports quite a bit, but has some problems that you need to be aware of. Earlier versions of Internet Explorer have no support worth mentioning. The same goes for Netscape versions earlier than 6.
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 is not to say that you cannot or should not use the abilities of browsers with better CSS support to enhance the design for them.
Not all browsers currently in use have the level of CSS support required to render a website which makes full use of CSS for layout in a graphically attractive way. Luckily, on most websites, only a few percent of the visitors are using a browser too old to render a CSS-based layout properly.
It’s important to note that these people will not be locked out. In the nineties, browser check scripts were a popular way of redirecting anybody 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 XHTML 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 CSS from web browsers. The thing most methods for hiding CSS have in common is that they are based on bugs in the way browsers interpret CSS code. That means 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.
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.
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-weight:bold;
}
Note: there is 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 url("styles.css");
</style>
By using the attribute style, you can apply CSS directly to an HTML element:
<h1 style="font-weight:bold;">Rubrik</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-weight:bold;
}
</style>
This should also be avoided, since it is best to keep HTML and CSS in separate files.
An explanation of, among other things, CSS import and media types.
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 each declaration ends in ; (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 all text contained in a <p> element 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.
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.
When starting out with CSS, it’s common to make the mistake of using unnecessary XHTML 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 XHTML 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="main">
<div class="maincontent">
<p class="maincontenttext">
Lorem ipsum dolor
</p>
</div>
</div>
This will do fine:
<div id="main">
<div>
<p>
Lorem ipsum dolor
</p>
</div>
</div>
To control elements contained in div#main you can use contextual selectors in the CSS code. In this case it could look like this:
div#main p {
/* rules */
}
In most cases CSS can be used to style logical XHTML 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 on 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 adapt the code to less able browsers.
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, padding and border are included in the supplied width or height.
Suppose you have the following CSS:
div.box {
width:300px;
padding:20px;
border:10px solid;
}
The total width of this div 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 a thorough explanation of the CSS box model, see the document 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: The Theory.
“LoVe/HAte”: Define pseudo classes for links in the order Link, Visited, Hover, Active.
“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] and hyphen (-), 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.
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.
Accessibility is not only about supporting disabled visitors, even if that 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 is simpler for anyone using the form?
Using semantic, well structured XHTML will take you a long the 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. 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 the goal is to get fewer visitors.Besides, you are making things harder on yourself. Frames make a website more technically complex.
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.
Links to articles describing how to build accessible tables.
An article on how to use tables for tabular data.
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.
A common question is what to use to layout a form. Some say that a form can be considered tabular data, and should be marked up with a table, while others say that CSS should be used. Use either method, but if you use a table, make sure the form makes sense and is usable when the table containing the form is linearized.
A WebAIM article on accessible forms.
An article that goes through the basics of building better, more accessible forms.
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 8%.
In most 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.
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.
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 advantages of using this kind of URLs are that search engine robots will index the site better, 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, some web browsers will, as they should, see the ampersand as the start of an HTML entity, and if the text following immediately after the ampersand matches an HTML entity, the browser will convert the URL, and in most cases break the query string.
Another thing worth mentioning is that for most websites, using a www subdomain is unnecessary, and that http://example.com/ should be used instead of http://www.example.com/. More info on this can be found at no-www.org. Whether you use the www subdomain or not, it is a good idea to configure your web server to redirect any traffic to http://www.example.com/ and http://example.com/ to the same URI.
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.”
MACCAWS’ mission is to provide Web authors with the resources necessary to promote Web standards as a commercially desirable choice for clients. Two very worthwhile documents at MACCAWS are What Every Web Site Owner Should Know About Standards: A Web Standards Primer and The Way Forward with Web Standards.
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 2004–2008 Roger Johansson