Dreamweaver 8 Does Standards
If you’re reading this article, you probably already have an interest in the subject of “Web standards,” and are curious about the application of standards in a site that’s built with Dreamweaver.
Perhaps you already have an understanding of Web standards, but you’re not sure how to use Dreamweaver to create compliant code. Or perhaps you’re a Dreamweaver user who wants to comply with Web standards, use CSS more extensively, and produce more accessible documents. Either way, this article has the answers you need: it will show you how work to Web standards using Dreamweaver.
This article is actually excerpted from SitePoint’s new release, Build Your Own Standards Compliant Website Using Dreamweaver 8, by Rachel Andrew. This book shows you, step-by-step, how to develop a standards compliant Website using XHTML Strict markup and CSS. With this book, you can swiftly and successfully develop attractive, functional sites that conform to Section 508 legislation, and pass the WAI accessibility guidelines with a Triple A rating, using the extensive capabilities of Dreamweaver 8.
As we’ll discover in the course of this chapter, there are excellent commercial reasons why sites should be developed to meet Web standards. The decision to adopt Web standards shouldn’t be about jumping on a bandwagon, or keeping up with the latest Web development fashion. It’s about producing good quality work, and knowing that your development approach will benefit your clients or employers as well as site visitors.
Web Standards Defined
As we’ll be concerned with Web standards throughout this book, let’s take a moment to clarify exactly what we’re talking about.
Web standards are specifications that direct the use of development languages on the Web, and are set by the World Wide Web Consortium (or W3C). 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).
Note: Get the Spec, Direct!
You can read these specifications and recommendations at the W3C site, though they’re a little heavy going at times.
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!
Who Needs Web Standards?
You might have a vague notion that Web standards are a good thing, but many sites—including many big name sites—don’t comply with Web standards, and they certainly seem to manage perfectly well. So why should we make the effort to comply with Web standards? Are there any real benefits in doing so? Who needs Web standards, and who needs to take notice of the W3C specifications and recommendations?
Web Designers and Developers
At the top of the list of people who need to worry about Web standards are people like us: the designers and developers who put together Websites. Will the time we spend learning how to develop to Web standards pay off for us?
Cleaner Markup Makes Bug-fixing Quicker
If you validate your pages using W3C validators, at least you’ll know that invalid markup is not the cause of any page display errors you might be experiencing. Sometimes, the process of validating a page, and fixing the errors that are found, can clear up display issues caused by elements not being closed correctly, or misspelled tags.
Even if validating your document doesn’t fix the issue, at least you know that the problem exists within a valid document. Once you know that the problem isn’t an error, you can start looking at other issues, such as the differing implementations of CSS in various browsers.
Complying with Accessibility Requirements is Easier
If you create valid XHTML markup, and you ensure that your document is semantically correct, and you separate your document’s content from its presentation (all of which we’ll discuss in this chapter), you’ll already have made considerable progress on many of the accessibility checkpoints outlined in WCAG 1.0. It’s also important to recognize that accessibility isn’t designed just for those with disabilities. An accessible site is able to be read by many different devices, including search engine indexers and “limited-resource” devices, such as mobile phones and PDAs, which don’t have the processing power to cope with messy, nonstandard markup.
Forward Compatibility
If you consider how your newly developed page looks in only a few current browsers, how can you be sure that it will display well in the next new browser? New browsers may display your pages badly, leaving you scrambling to find and fix problems as complaints come in. If you rely on tags that are specific to certain browsers, or have been removed from the specification entirely, you leave yourself open to this problem.
Complying with Web standards won’t eradicate this problem completely; however, standards compliance makes the serious failure of your design less likely, as browser manufacturers now follow the standards, too. While they may occasionally misinterpret some part of the specification, they’re unlikely to stop supporting it altogether. If the worst does happen, and a new browser has a strange effect on your standards-based Website, fixing it is likely to be easier than fixing a non-compliant site. If you’re experiencing a problem, it will probably have affected other standards-complaint sites. The great minds of the Web community will be figuring out fixes and writing articles to explain their solutions. And, as we’ve already discussed, bug fixing in a compliant document is far easier than in a non-compliant document.
Easier Redesigns
Have you ever had to redesign a Website by ripping the text from it and starting from scratch? Have you ever seen markup that was so littered with font tags and tiny table cells that it was easier to just start over? I know I have, and it’s a slow process that can chew up a good deal of the time and money dedicated to a site redesign.
Separating the document’s content from its presentation won’t just give you a warm glow of standards compliance: it means that the next time someone has to redesign the site, they won’t need to copy all the text out of the Web documents. All of the site text will have been marked up using semantic (X)HTML, and all of the presentational information—the stuff the site owners want to change—will be stored in a CSS file that can be replaced easily.
Some clients won’t even wait for a redesign before they start asking you to make changes: they’ll wait until you’ve almost finished their mammoth site, then ask you to “just switch that column from the left to the right.” With a standards compliant site whose page layout is controlled by CSS, you can move page elements around easily, without needing to hack away at complex table structures on many pages. This makes changes to page layouts comparatively simple.
The separation of structure from presentation can also make it easier to provide added features, such as a high-contrast, low-graphics version of the site for visitors who prefer to use the site that way. Why create separate text-only versions of all your pages when you can simply swap out the style sheets?
Browser Manufacturers
The manufacturers of browsers that access the Websites we build do take notice of Web standards. In the past, browser manufacturers added their own, proprietary tags and attributes to the basic languages. But now, more than ever, they’re working to comply with the standards, and, certainly with the newest browsers, attempts are being made to display (X)HTML and CSS as described in the specifications.
Web browsers will, for the foreseeable future, attempt to render even the most poorly marked up, invalid code, because if they didn’t, hundreds of thousands of badly written sites would display as a complete mess—and the general public would most probably blame the browser, not the Web designer. However, other devices, which don’t have the rendering power of a desktop computer, rely far more heavily on the standards compliance of the markup they encounter.
Authoring Tool Manufacturers
Authoring tool manufacturers—such as Macromedia, which creates Dreamweaver—have to follow Web standards just as Web designers do, as, increasingly, their customers demand that these authoring environments output valid markup. Traditionally, visual development environments received bad press for creating messy, invalid markup; however, newer versions of the leading visual development environments have cited standards compliance and accessibility features as main selling points. The manufacturers are definitely listening—and responding—to the market’s demands.
Web Users
The users of the Websites we design also benefit from our adoption of Web standards, even if they don’t realize it! Perhaps they unwittingly use sites that specifically have been developed to display well in the most popular browser. If those users switch to a different browser, they might find that they no longer enjoy such a great online experience, as the proprietary markup used by those sites won’t work in the new browser. A standards compliant site has a far greater chance of working well across all browsers, both those that were in existence when you developed the site, and the new browsers that will launch later in the site’s lifetime.
In addition, a Website that’s developed in line with accessibility recommendations is likely to be accessible to users who might find browsing the Web a frustrating experience. The Web should offer opportunities for easier shopping, reading, and research to visually impaired or otherwise disabled users. It shouldn’t frustrate them with sites that use proprietary markup, or other techniques that effectively lock out of the site anyone who doesn’t use a “regular” browser in a “regular” way.
Using Web Standards
How do we ensure that we’re using these Web standards correctly? What does it take to comply with the standards?
First, we need to conform to the specification. This means that we should use only those elements and attributes that are included in the specification, avoiding the proprietary elements introduced by browser manufacturers, such as Internet Explorer’s <marquee> tag, and Netscape’s <blink> tag. We should also avoid using elements that appeared in earlier specifications (such as HTML 3.2) and have since been removed when we’re working on documents developed to a later specification.
Creating a Valid XHTML Document
We’ll use XHTML throughout this book, so we’ll be working to the W3C’s XHTML 1.0 Recommendation (in W3C parlance, a “recommendation” is a specification). XHTML is basically the latest version of HTML, and was designed to replace HTML as the markup language for Web pages. Though it’s a reformulation of HTML as XML, XHTML is almost identical to HTML, apart from a few small differences that we’ll discuss in Chapter 3, XHTML and Semantics.
You can create an XHTML document through Dreamweaver’s New Document dialog (File > New…). Make sure Basic page is selected in the Category list, then select HTML from the Basic page listing that appears, as shown in Figure 1.1, “Creating a new XHTML document in Dreamweaver.” You can then select one of the XHTML options from the Document Type (DTD) drop-down list.
Clicking Create will create the new document. Switch to Code View, by clicking the Code button at the top of the document window, to see exactly what’s included in a simple XHTML document. This is illustrated in Figure 1.2, “Displaying the new XHTML document in Code View.”
Figure 1.1. Creating a new XHTML document in Dreamweaver.
Figure 1.2. Displaying the new XHTML document in Code View.
The first line of the document will look something like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
This is called the document type declaration, or DOCTYPE. As you can easily infer from its name, the DOCTYPE declares what your document is—which (X)HTML specification you’re working to. In this example, we’re working to XHTML 1.0 Transitional, Dreamweaver 8’s default. The Transitional part tells us something else about the version of XHTML that we’re working with. XHTML 1.0 comes in three “flavors:” Strict, Transitional, and Frameset. Dreamweaver uses the Transitional DOCTYPE by default, and Frameset if you insert frames into the document.
XHTML Strict is, as you would expect, the strictest form of XHTML. An XHTML Strict DOCTYPE looks like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
If you’re using a Strict DOCTYPE, you can’t use any deprecated elements (tags) or attributes in the document; nor can you use frames. Deprecated elements are those that have been flagged for removal in future versions of XHTML. Many deprecated elements control the appearance of the page, performing the kinds of functions that can be handled by CSS. The main difference between Strict and Transitional DOCTYPEs is that, with the Strict DOCTYPE, you’re far more limited in terms of the presentational attributes and elements you can include in the document.
Note: Using the Strict DOCTYPE in Dreamweaver
Dreamweaver isn’t quite as careful as it could be about adhering to the standard. If you use the Strict DOCTYPE, take extra care to validate your documents and replace any invalid attributes. Typically, it will be quite easy to replace them with CSS.
The Frameset DOCTYPE supports the use of frames, and Dreamweaver will use it automatically if you include any frames in your document. The Frameset page will then reference at least two other HTML pages, which can use any DOCTYPE they like. The Frameset DOCTYPE looks like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
HTML 4.01 offers the same three DOCTYPE flavors—Transitional, Strict and Frameset—which work in exactly the same way as the above XHTML DOCTYPEs. If you used one of these, you would need to mark up your document in HTML, rather than XHTML. We’ll explore the differences between HTML and XHTML later in this book, as we start to create our Website.
Comments