Information Technology Reference
In-Depth Information
IV
If you use something other than the WordPress editor to create
your blog posts, you should validate all your posts against the
XHTML 1.0 standard. Like a debugger does for software pro-
grams coded in a particular language, a validator checks the doc-
ument type declaration (DOCTYPE) you make in your header and
flags places where your page doesn't meet the standard.
Even if you haven't posted to your WordPress blog yet—or even
created a web page—you can test your tool's default adherence
to the standard by creating a page with at least one h1 heading,
one h2 heading, a link, and some text. Run this page through a
validator and see what it finds. You can probably adjust your
tool's settings and defaults to fix the problems. If not, consider
getting another tool.
Validating your pages is easily done, and there are several ways
to do it. Go to the W3C Validator at http://validator.w3.org/ and
test your pages:
•
If you have posts already live, use the Validate by URI tab.
Copy the permalink of your latest post into the box.
•
If the post is saved to an HTML file, use the Validate by
Upload tab.
•
You can copy and paste all your text directly from your editor
into the edit box in the Validate by Direct Input tab. Be sure to
include all the header information, as the validator cannot
identify your document type if the declaration is not present.
tip
Many web authoring tools
include a built-in validator, or
can incorporate the free HTML
Tidy validator as a plug-in. Check
your tool's documentation to see
how to validate your XHTML
without leaving your application.
You can always use the W3C
Validator (or any other online
validator), shown in Figure 14.2
as a substitute or a supplement
to your built-in test.
note
The URI in this tab stands for
uniform resource identifier. This
is an XML designation for any
item in the DOM tree, including
the more familiar URL, or uniform
resource locator, links.
Click the More Options link to give yourself a bit more help in troubleshooting any problems the
validator finds. While you're still learning, we recommend checking the Show Source, Validate Error
Pages, and Verbose Output check boxes. This gives you the most information. The Show Outline
option displays your headings and tells you whether you are
using them properly. Check this if you use subheadings in your
blog posts. You could check the Clean up Markup with HTML
Tidy check box to use HTML Tidy to clean up your mistakes, but
the lessons to be taught by the validator just wouldn't be as last-
ing (see the Troubleshooting Note at the end of this section for
more about these lessons).
We ran one of the author's (McCallister's) posts through the W3C
Validator, and the results appear in Figure 14.2. Clearly, he needs
a more standards-compliant editor!
Many of the errors listed in the validation report shown here should have been easily identified and
fixed by the editor. About one quarter were “XML parsing errors,” including badly placed closing
tags. Some of these were introduced by an imported Text widget. About one tenth involved failing
to include closing tags for some paragraphs (a starting
<p>
, but no closing
</p>
).
note
Choosing “Group Error Messages
by Type” generates more errors
than the default setting, “List
Messages Sequentially,” but it
does help in identifying the
nature of a problem.
