Though certainly not required, in keeping with my interest in embracing the full scope of blog standards and techniques I decided to get W3C (World Wide Web Consortium) certification for the validation of my site XHTML. I had done so earlier from my cascading style sheets (see earlier post) and had verified through the W3C validator that the WordPress site, itself written in WordPress, had valid XHTML. If any errors occurred on my own site, these indicators suggested that they were only introduced by me.
Why XHTML Validation?
The W3C validator checks for valid XHTML 1.1, which means the site identifies itself as "XHTML 1.1" and that W3C successfully performed a formal validation using an SGML or XML Parser (depending on the markup language used). Passing this test shows readers that you have taken the care to create an interoperable Web page, you may therefore display the W3C XHTML validation icon on any page that validates.
XHTML validation suggests that your site and its code meets current standards and will likely render and display properly in modern browsers. By giving attention to these factors early, effort in later post-cleanup are greatly reduced. (Though it is the case that dynamic sites that are template driven are easier to cleanup than static sites where mistakes are repeated on every HTML page.) I was also interested in the validation because of my assigned scope to get familiar with the entire blog and current environment.
What Initial Testing Showed
The first validation test on the AI3 entry page showed 284 errors. After checking further to remove duplicated errors resulting from the main display posting-and-comments loop, I found there to be about 142 errors in the main page template, which included the cascading includes of header, masthead, left- and right-hand panels, and main display area, which displays the results of the WordPress loop. Here is where I would first turn my attention, then followed by the loop errors.
In general, here are the types of repeated errors I had made:
- A lack of full close tags (__/) v. (/item) for elements such as link and image tags and line breaks
- Sloppy definitions of color and other parameter definitions that were not included in quotes (e.g., color="#820000" v. color=#820000). All of these were subsequently quoted; this is an important area to be attentive for future entires
- Place alt tags on all image references and elements
- Avoid the older italic (<i>) and bold (<b>) tags, using instead <em> (emphasis) and <strong>, respectively
- Replace the old style line break (<br>) with the new style closed break (<br />), and avoid breaks where open and close paragraphs can be used instead (<p> paragraph body </p>>)
- If using open and close paragraphs for spacing, make sure a space is included between the tags (<p> </p>)
- Take care when using <div> tags and make sure they are even and balanced with equal number of closes (</div>). This problem in particular caused display differences within MSIE and some temporary hacks that could later be removed when the div tags were balanced.
Efforts to Cleanup Errors
The efforts to identify and cleanup these errors took about six hours. After a short period spent understanding the cryptic messages from the W3C validator, the errors began to fit into patterns and corrections occurred more quickly. Also, here were some of the lessons learned:
- Except for very targeted and limited use of in-line styles, use external CSS where possible
- On the validator, set to verbose comments to get more errror descriptions
- Re-submit validations frequently as various parts of the code are cleaned up. This reinforces lessons learned and provides gratifying feedback
- Be careful about the use of in-line v. block elements, and make sure block elements embrace in-line ones. For example, bold is an in-line element. It should be used internal to a block element tag such as paragraph. The following is correct syntax: <p><strong>This is a bolded paragraph.</strong>,/p>. Reversing the order of <p> and <strong> is incorrect syntax
- IInspect the WordPress (or other blog software source) code for internally named classes and give them particular care in the CSS, adding if necessary and using where possible, and
- Avoid all use of the older <center> text body </center> style.
Resulting Testing and Validation of the Site
When the cleanup was completed, most pages within my site validated, especially the static ones and postings based on the WordPress loop. I had some particular problems with the PHP calls for the trackback mechanism when the reference was within link tags (<a href="item" /> <?php trackback stuff>Trackback<a />). By single quoting the reference, I was able to clear up this nasty error.
I have found a couple of places where my posts will not validate. These point to errors within the WordPress PHP code and when encountered I have chosen not to make the cleanup. This is based on my desire to not alter or hack basic WordPress code that might change in future versions and cause integration problems with my prior hacks.
Use of Valid XHTML Icon
Taking this effort and cleaning up the code enables you to display the valid XHTML 1.1 icon:
Author’s Note: I actually decided to commit to a blog on April 27, 2005, and began recording soon thereafter my steps in doing so. Because of work demands and other delays, the actual site was not released until July 18, 2005. To give my ‘Prepare to Blog …’ postings a more contemporaneous feel, I arbitrarily changed posting dates on this series one month forward, which means some aspects of the actual blog were better developed than some of these earlier posts indicate. However, the sequence and the content remain unchanged. A re-factored complete guide will be posted at the conclusion of the ‘Prepare to Blog …’ series, targeted for release about August 18, 2005. mkb
