Article
Dreamweaver 8 Does Standards!
Validating your Document
How can you ensure that a document you've created in HTML or XHTML is valid, and conforms to the specification? Run it through the W3C Validator shown in Figure 1.3, "Using the W3C Validator."
To use the validator, you can enter the URL of the page you'd like validated (if it's live on the Web), or you can upload a file from your computer.
Figure 1.3. Using the W3C Validator.
Once you've told the W3C Validator where to find your (X)HTML, click the Check button. A page will display, announcing the joyful news that your page is valid, or providing a list of errors that you can work through before you re-check the page's validity. If you've been working in Dreamweaver to create an XHTML document, you should have very few errors to fix; however, later in this book, we'll look at some of the more common errors that can occur as we build Websites.
To help you ensure the validity of your pages during development, Dreamweaver provides a built-in validator. To run the validator, select File > Check Page > Validate Markup, or click the Validate Markup button. The validation results appear at the bottom of the window. As shown in Figure 1.4, "The validator in Dreamweaver," you can choose to validate the current document, the entire local site, or selected files within the site.
Figure 1.4. The validator in Dreamweaver.
Though this validator provides a useful check as you go along, I always check my documents at the W3C's online validator prior to their publication online. The Dreamweaver validator cannot validate any markup that's generated dynamically using a server-side language such as PHP or ASP. So, if you're generating pages—or parts of pages—in this way, you'll definitely need to use the online validator after uploading your pages.
Using Valid CSS
As we'll discover when we build our site, CSS replaces all of the deprecated presentational elements in HTML, as well as adding plenty of scope for interesting design ideas that aren't possible using HTML alone. CSS is also a Web standard, and the W3C has developed specifications against which we can validate our CSS code, just as we do for (X)HTML.
When it comes to CSS, you have three options for validation: point to a file on a live server (either a CSS file, or an HTML page with embedded CSS), upload a CSS file from your computer, or paste the CSS directly into a text area. As with the (X)HTML validator, the result will either be a congratulatory message, or a list of errors for you to fix before revalidating your style sheet. Dreamweaver does not offer a built-in CSS validator.
Validating for Accessibility
When designing a Website, designers and developers can become consumed by the way the pages display in a Web browser, or range of browsers; we can forget that, for many people, just getting the content is all that matters. Many Web users employ some kind of assistive technology—such as a screen reader, which reads the text of the page aloud—or have a disability that makes using the Web in the way that most of us do, with a graphical display in a Web browser, very difficult, if not impossible.
Through its Web Accessibility Initiative (WAI), the W3C offers recommendations that we can follow to ensure that our sites are accessible to these users; therefore, we should check that our sites comply with the WCAG 1.0 recommendations. As we'll see in Chapter 7, Accessibility and Chapter 8, Building the Site, validating the accessibility of Web documents is rather more tricky than checking your documents for valid (X)HTML and CSS. "Yes" and "no" answers are not always provided for the WCAG 1.0 recommendations' different checkpoints.
Dreamweaver contains an accessibility validator, which can be run from the Reports dialog (Site > Reports...), as shown in Figure 1.5, "Running an accessibility report from the Reports dialog.". Check the Accessibility checkbox and click Run.
Figure 1.5. Running an accessibility report from the Reports dialog.
The report that displays in the Results Panel will include notes such as, "Color is not essential," (which appears in Figure 1.6, "The UsableNet Accessibility Reference displaying in the Results tab of the Reference Panel."); this relates to a checkpoint that advises that the use of color in the document should not be essential to users' understanding of the page. You would fail this checkpoint if, for example, the only way you communicated the status of an article on your site was through color-coded icons. In this case, your pages wouldn't be accessible to users who could not differentiate between the colors. You would pass the checkpoint if you used both color-coding and a textual status note. Of course, there's no way for an automatic validator to know which approach you've taken, so you need to make your own, manual check and decide whether you pass or fail a checkpoint. And, to do so in an informed way, you need to have an understanding of what each point means.
That said, Dreamweaver can help: in the Reference tab of the Results Panel, you'll find the UsableNet Accessibility Reference depicted in Figure 1.6, "The UsableNet Accessibility Reference displaying in the Results tab of the Reference Panel.", which explains the checkpoints and provides methods by which you can check whether your site passes or fails each one. Right-click on any checkpoint and select More Info… to display an explanation of that checkpoint.
Figure 1.6. The UsableNet Accessibility Reference displaying in the Results tab of the Reference Panel.
There are also online accessibility validators, the most popular of which is WebXACT (previously known as Bobby), and Cynthia Says. These are accompanied by the same provisos as the Dreamweaver validator in that the results these systems provide require interpretation: they cannot give you a "yes" or "no" answer.
Applying a Semantic Document Structure
Implied in our adherence to Web and accessibility standards is the adoption of semantic document structure. A semantic document uses HTML tags for their meanings, not their appearance. For example, a semantic document would use the <h1>, <h2>, and similar tags to mark up a page's headings. If we didn't want to display the default appearance of these headings, we could easily change it using CSS. Similarly, the use of an unordered list (<ul>) tag to mark up a list of links would be preferable to separating those links with line breaks. If we want the list of links to appear without bullets, we can achieve the effect using CSS.
We will look at this issue in more depth in Chapter 3, XHTML and Semantics; however, here's a simple example. If I were to mark up a section of this chapter as an XHTML document, I might end up with something that looks like Figure 1.7, "Marking up the chapter as XHTML."
Figure 1.7. Marking up the chapter as XHTML.
The markup for the page could be something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<style type="text/css">
<!--
.heading {
font-size: 24px;
font-weight: bold;
}
-->
</style>
</head>
<body>
<p class="heading">Web Standards Defined</p>
<p>As we'll be concerned with Web standards throughout this book,
let's take a moment to clarify exactly what we're talking
about.</p>
<p>Web standards are specifications that direct the use of
development languages on the Web, and are set by the
<a href="http://www.w3.org/">World Wide Web Consortium (or
W3C)</a>. These specifications cover languages such as HTML,
XHTML, and CSS, along with a range of other languages, such as
MathML, a markup language designed to represent mathematical
equations, that you might come across if you have a specific
need. The W3C also publishes the Web Content Accessibility
Guidelines (WCAG)—recommendations that address the
accessibility of Web pages—via the Web Accessibility
Initiative (WAI).</p>
<p>You can read these specifications and recommendations at the
W3C site, though they're a little heavy going at times.</p>
<p>HTML 4.01: <a href="http://www.w3.org/TR/html4/">
http://www.w3.org/TR/html4/</a><br />
XHTML 1.0: <a href="http://www.w3.org/TR/xhtml1/">
http://www.w3.org/TR/xhtml1/</a><br />
CSS 1: <a href="http://www.w3.org/TR/CSS1">
http://www.w3.org/TR/CSS1</a><br />
CSS 2.1: <a href="http://www.w3.org/TR/CSS21/">
http://www.w3.org/TR/CSS21/</a><br />
WCAG 1.0: <a href="http://www.w3.org/TR/WAI-WEBCONTENT/">
http://www.w3.org/TR/WAI-WEBCONTENT/</a></p>
<p>In this book, we'll use the XHTML 1.0, CSS 1 and 2.1, and WCAG
1.0 specifications and recommendations, although you'll be glad
to know that we won't be doing too much reading of the actual
W3C documents themselves!</p>
</body>
</html>
As so many designers are now comfortable with the use of CSS for styling text, we often see text that's marked up as a paragraph (i.e. it appears between <p> and </p> tags), but is styled as a heading using CSS. To be semantically correct, I should have used a h1 element (as that denotes a heading), then used CSS to make it display as required.
Take a look at the list of URLs for the different W3C specifications: they've been split onto separate lines using the <br/> tag. The correct way to structure these links would have been as an unordered list. We could even indicate that this content constitutes a note using a <div> tag:
<div class="note">
<p>You can read these specifications and recommendations at the
W3C site, though they're a little heavy going at times.</p>
<ul>
<li>HTML 4.01 <a href="http://www.w3.org/TR/html4/">
http://www.w3.org/TR/html4/</a></li>
<li>XHTML 1.0 <a href="http://www.w3.org/TR/xhtml1/">
http://www.w3.org/TR/xhtml1/</a></li>
<li>CSS 1 <a href="http://www.w3.org/TR/CSS1">
http://www.w3.org/TR/CSS1</a></li>
<li>CSS 2.1 <a href="http://www.w3.org/TR/CSS21/">
http://www.w3.org/TR/CSS21/</a></li>
<li>WCAG 1.0 <a href="http://www.w3.org/TR/WAI-WEBCONTENT/">
http://www.w3.org/TR/WAI-WEBCONTENT/</a></li>
</ul>
</div>
A document can be perfectly valid against its specification while structured in a non-semantic manner. We need to use common sense and judgment to look at our documents and decide whether we're using the correct tags to mark up each element on the page.
Thanks to CSS, the look and feel of the document need not be compromised by our use of correct elements and adherence to semantic document structure. However, marking up documents correctly is extremely beneficial when we start to consider site visitors who don't use traditional Web browsers to read content. We'll discuss this issue more throughout this book.
Separating Presentation from Document Structure
Another issue that's implied by working to Web standards is that of separating presentation from content. The content comprises the semantic document that we discussed in the last section; the presentation is what makes it appear as it does on a computer, projector, or printed page.
If you're using a Transitional DOCTYPE, you can include in your document many tags and attributes that do not describe what the different elements in the document are, but instead, state how they should look. Presentational tags include <font> and <center>, and can be replaced using CSS. Other attributes are used for presentational elements such as borders: for example, <img border="0"/>.
Using such presentational elements can make it difficult to change the way elements look. Best practice Web development entails the separation of the structure of a document from its presentational aspects. This separation is achieved by the use of CSS, wherever possible, to dictate how the document should look. If you want to validate against a Strict DOCTYPE, for the most part you'll be required to apply this separation, as the tags and attributes that are absent from the Strict DOCTYPEs are largely presentational.
This separation of structure from presentation also underlies the recommendation that tables not be used for page layout purposes. The <table> tag was initially designed to describe tabular data, such as that found in a spreadsheet, not to force page elements into certain locations on the page. If your page uses a table to lay out page elements, you've mixed your structure and presentation—even though the page may well validate to a Strict DOCTYPE.
Summary
In this chapter, we've learned what Web standards are, and explored the core issues that we must consider if we want to develop Web pages to Web standards. We've also looked at some of the reasons why Web standards are helpful to those designing for the Web, and why investing time to understand this approach will pay off in future.
As is the case with all visual development environments, Dreamweaver has not achieved a reputation for creating clean markup. For many, however, developing in a visual environment is a better way to work than hand-coding HTML and CSS in a text editor. This book will discuss how you can use Dreamweaver to ensure that your work is standards compliant, and addresses all of the issues we mentioned in this chapter: valid markup and CSS, semantic document structure, the separation of structure from presentation, and meeting accessibility recommendations. Any tool—be it Notepad or Dreamweaver—is only as good as its operator, so let's move on and create a standards compliant Website using Dreamweaver 8.