validcode | SYS-CON ITALIA

validcode

Aug. 11, 2004 12:00 AM

In today's wild, wild Web, the catchphrases are usability, accessibility, standards-compliance, and valid code. Why is valid code so important? The sheer number of browsers out there that display the same code differently make it virtually impossible to have different versions of code for each browser. In this day and age, maintaining standardized and valid code is essential.

Dreamweaver MX 2004, being the top-of-the-heap software application it is, can help you code, but sometimes it gets a bit confused. Today, we are going to look at how to extend and use Dreamweaver MX 2004 to write standards-compliant, valid code.

Are you ready to get your valid code freak on? If so, keep reading!

Analyzing Your Workflow
The cool thing about Dreamweaver is that its users come from all walks of life, from beginners who've just installed the software, to hard-core code warriors who use its Server Behaviours to build complex applications or code their own applications from scratch.

Hand coders will love the Code View (View -> Code) because it facilitates typing code without having to use a third-party text editor. To the relief of many hand coders using WYSIWYG applications, Dreamweaver, unlike other applications, won't change your code at will.

Designers will love the Design View (View -> Design) because it allows them to see the end-result of the underlying code, and the Property Inspector (Window > Properties, Ctrl+F3) will allow them, to a degree, to tweak the code without having to remember HTML or crack open their trusty HTML books.

As I mentioned previously, Dreamweaver will sometimes get confused and insert invalid or deprecated code. Poor Dreamweaver. However, have no fear, we will make it all better in a second. Let's start by configuring Dreamweaver for accessibility.

Setting It All Up
Open Dreamweaver MX 2004 and click on Edit -> Preferences (Ctrl+U). Select the Accessibility option from the Category list (see image I) and check all four boxes, labeled Form Objects, Frames, Media, and Images.

What happens when you insert one of those items? A dialog box will pop up (see images II through V) and prompt you to add information, such as ALT tags and the like. These dialog boxes almost literally force you to enter the proper required attributes for the XHTML doctype. Just don't hit the "Cancel" button. Otherwise you will have to hand code the information, or delete the element and start over. Not fun and very time-consuming!

Now we will configure Dreamweaver to format your code properly. Select Code Format from the Category list (see Image VI) and, in the resulting pane, select <lowercase> from the Default Tag Case drop-down menu. Finally, select lowercase="value" from the Default Attribute Case drop-down menu. For centering, select the radio button next to the words "Use DIV tag".

We choose <lowercase> from the Default Tag Case drop-down menu because XHTML doesn't allow for uppercase tags. The same rule applies for the Default Attribute Case. For an example of what happens if you use uppercase tags and attributes with the XHTML doctype, create a page with uppercase tags and attributes and try to validate the page (validator.w3.org/). Validation errors galore!

Also, don't forget to check off the box named "Make Document XHTML Compliant." Because the acceptable format for documents on the Web uses the XHTML doctype, we will configure Dreamweaver to automatically use the XHTML doctype if we create a new file. Click on "New Document" in the Category list and, in the resulting pane, select UTF-8 from the Default Encoding drop-down menu.

Now, when you create a new page in Dreamweaver, you will see a few changes. The biggest of them is the new doctype.

Transitional: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

The other two doctypes available for use with XHTML 1.0 are:

Strict: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Frameset: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

If you would like to use XHTML Strict doctype as opposed to XHTML Transitional, simply add it to the Default.html file located in C:\Program Files\Macromedia\Dreamweaver MX 2004\Configuration\Templates, or Macintosh HD > Applications > Macromedia Dreamweaver MX 2004 > Configuration > Templates, if you are using a Macintosh Operating System. I will discuss how to do that later on in this article.

For more information about doctypes, read Holly Bergevin's excellent article "Rendering Mode and Doctype Switching" on CommunityMX at Click Here.

Finally, the last thing on our list is to configure the Code Validation capabilities of Dreamweaver. Click on "Validator" in the Category list, and check the box next to "XHTML 1.0 Transitional".

And Dreamweaver is configured! The fun stuff really starts now, because we will go more in-depth and do some hacking (the good kind!).

Doctypes and Charsets
Dreamweaver does a pretty good job of generating the code for an XHTML-compliant Web document:


<!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>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>Untitled Document</title>
</head>

<body>
</body>
</html>

However, there are still a few errors, and the namespace is incomplete. That's not a big deal; we will fix all that right now.

Locate the document called Default.html on your hard drive. If you are on the Windows operating system, this file is located in C:\Program Files\Macromedia\Dreamweaver MX 2004\Configuration\Templates. If you are using a Macintosh, you can find it in Macintosh HD > Applications > Macromedia Dreamweaver MX 2004 > Configuration > Templates. Danilo Celic has created an awesome extension that allows for the opening of default document types. Check out www.communitymx.com/content/article.cfm?cid=01E77 for more information.

Make a backup of this file (ALWAYS make backups if you are editing any of Dreamweaver's main configuration files), and call it something like Default (backup).html.

Open the Default.html file in a text editor, and enter in the following code:


<?xml version="1.0" encoding="UTF-8"?>
<!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"
xml:lang="en" lang="en">
<head>
<title>Untitled Document</title>
</head>

<body>

</body>
</html>

Note that in this example, the XML declaration is included. XHTML document authors are strongly encouraged to use XML declarations in all of their documents. However, an XML declaration like the one previously mentioned is not required in all XML documents. In fact, some browsers fail when confronted with an XML declaration.

The XML declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

Because we are declaring the document encoding type to be UTF-8, replace the code snippet with this one:


<!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" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>

<body>
</body>

</html>

While you are here, you can set up links to any style sheets, insert basic meta tags, or do any other general maintenance.

The reason we use UTF-8 as the encoding type is that UTF-8 is the normal character encoding for any HTML file that contains text in two or more non-Latin scripts, but it can be used for any document.

Save the Default.html file, and close it.

Closing the Tags
A few months ago, I had a conversation with an industry colleague at a local user group event. He was speaking about how to get the software to do the work for you, as opposed to having to do all the hard work yourself. The interesting thing was, I realized just how right he was. Think about it. Why do all the hard work yourself, when the software can do it for you?

XHTML requires you to close non-closing ("empty") elements, including input tags, image tags, horizontal rule tags, and break tags. (For more information, see XHTML Guidelines in the NYPL Online Style Guide at www.nypl.org/styleguide/xhtml/guidelines.html and W3C's HTML Compatibility Guidelines for XHTML 1.0, located at www.w3.org/TR/xhtml1/#guidelines.) Closing these pesky elements by hand can be one of the most time-consuming tasks in making the transition to XHTML.

Line Breaks
You can modify Dreamweaver to do the work for you. Let's start with the simple line break, an HTML element with which we are all familiar.

First, find the file called Linebreak.htm. The file is located in C:\Program Files\Macromedia\Dreamweaver MX 2004\Configuration\Objects\Characters, if you are using the Windows Operating System. If you are on the Macintosh Operating System, it is located in Macintosh HD > Applications > Macromedia Dreamweaver MX 2004 > Configuration.

Change line 18 of the Linebreak.htm to look like this:

return " ";

To test if your changes worked, create a new HTML document in Dreamweaver, and insert a line break. View the Code (View -> Code) to make sure it worked.

Images
We will also need to "close" the images. The process is similar to what you've just done with line breaks, but a bit more complicated.

Go to Configuration\Objects\Common and make a backup of the Image.js file. Open the file in a text editor (any one will suffice) and modify line 45 to look like this:

rtnStr= '<img src="' + newURL + '" />';

Again, test your work by opening a new HTML document and inserting an image file. I could go on and on about how to do this for every single non-closing element out there. However, in an effort to be brief (and to prevent you from falling asleep), repeat the above steps for HR.htm and any other non-closing elements in the following directories:

\Configuration\Objects\Forms: The files you want to edit are: button.htm (line 22), checkbox.htm (line 22), file field.htm (line 40), hidden field.htm (line 22), image field.js (line 16), radio.htm (line 22), text field.htm (line 22).
\Configuration\Objects\Head: The files you want to edit are: base.js (line 29), description.js (line 16), keywords.js (line 15), link.js (line 38), meta.js (line 29), refresh.js (line 22).

A Quick Word Of Advice
After you have completed all of the nonclosing elements, create a new document that uses all such elements and do a bit of QA testing. Run the pages through the HTML validator to ensure that the code is valid. After all your efforts, the last thing you want to do is create pages with invalid code.

The Bold and The Italic
You will notice that Dreamweaver still uses the and tags to bold or italicize text. Unfortunately, this is not conducive to semantically correct code. If you want to write true XHTML, you should be using the more meaningful and tags. We'll go ahead and change that right now.

Open menus.xml (located in Configuration\Menus) and change the code to look like this, on approximately line 1514:

TIP: Do not open this menus.xml in Dreamweaver. Open it using a text editor. Also, make sure you don't use a keyboard shortcut sequence that is currently in use. Cmd+Shift+h is a pretty safe bet.

And that's it! You're done. Now Dreamweaver is creating standards-compliant code.

You might be asking yourself why all of this work was worth the effort. There are many reasons.

Accessibility
Because Web standards incorporate and support accessibility compliance, a standards-compliant Web site is one step closer to accessibility compliance. By making your site accessible to the millions of people affected by disabilities, you can increase your customer base. In many jurisdictions, accessible sites are mandated by law.

An improved user experience also tops the list of reasons. Non-standard code can make it next to impossible for people using less common platforms, devices, or user agents to access your site's content. If your site is standards-compliant, then your site is available to all Web users, who are your potential customers.

Faster Page Loads and Lower Bandwidth Costs
Studies have shown that using modern, standards-based design can reduce the weight (also known as file size) of a site by 25% to 50%. Who can argue with that?

Device Independence
By employing the most recent standards for CSS, you can make it possible for your Web page content to be accessed by different browsers and devices - for example, the same Web site can be usable on both a cell phone and a fancy new computer.

There are many other reasons why you should use standards-compliant code; these are just a few of the more convincing arguments as to why you should adopt a standards-centric workflow.

Resources

What Every Web Site Owner Should Know About Standards: A Web Standards Primer: maccaws.org/kit/primer

The Way Forward with Web Standards: maccaws.org/kit/way-forward

The Web Standards Project: www.webstandards.org

The Web Standards Group: www.webstandardsgroup.org

Related Links

About Justin Kozuch
Justin Kozuch is a writer, web developer, and Team Macromedia member who takes pride in helping other Macromedia Dreamweaver users. His work is published weekly on CommunityMX.com, the home of the MX Community. He's also the Founder of Dreaming in TO (http://www.dreaminginto.com), a Macromedia Dreamweaver User Group located in Toronto, ON. A dynamic "junkie", Justin's passion lies in PHP/mySQL, organic design and breadcrumb navigation.