In a previous post, I wrote about the value of using the HTML validation services available on the web. After I wrote that post, I thought I should run the validation on the blog site. Keep in mind that in my case, I have very little control over the HTML generated by the blogging software provided by my ISP. The software is WordPress which may or may not be customized beyond the default options by my ISP.

Overall, I have not noticed any errors rendering the blog site in a variety of browsers and a variety of operating systems. My initial impression is that the software appears well written and supported.

When I compose a post, I have the option of using either the rich text editor WordPress provides or write my own HTML. Currently, I use the editor provided. As such, I am completely at the mercy of the WordPress development staff.

Results of Validation

When I ran the validator against the blog site, 18 errors were identified — none of which appear to impact the functionality of the site. (FYI – the site is identified as XHTML 1.0 Transitional.)

1) (1 time) document type does not allow element “li” here; missing one of “ul”, “ol”, “menu”, “dir” start-tag.

This is from a system generated entry in the left hand menu.

2) (3 times) document type does not allow element “h1” here; missing one of “object”, “applet”, “map”, “iframe”, “button”, “ins”, “del” start-tag.

This is the title of a post

3) (14 times) document type does not allow element “p” here; missing one of “object”, “applet”, “map”, “iframe”, “button”, “ins”, “del” start-tag.
This is within the content of a post and is generated by the rich text editor.

Moral

While striving for cleanly validated HTML is a worthy goal and will help prevent issues it is not always achievable. Identify those errors and warnings which are important to you and investigate work arounds when you do not control the HTML.