Welcome to another article on Building Better Web Pages. This article series comprehensively covers building an HTML document: easily learned, but rarely perfected.
Today’s article covers W3C Validation and Nested Tags. Some designers swear by the W3C standards like a bible, which they like to thump. The opposition likes to call them out and make a general mockery of things. Either way, HTML validation helps you uncover errors that may or not be affecting the rendering of your page, its search engine ranking, or both. This article deals not only with the topic of validation, but also the nesting of HTML tags within each other. We address both because they are often intertwined. Incorrectly nested tags are the cause of invalid code, and can also make it harder for a machine such as a search engine to crawl your site.
Solid Statement: Always validate your HTML over at the W3C. Don’t forget to use the option “Show Outline” to see how semantically sound your code is. This will quickly tell you about any nesting issues. To avoid those issues, never put inline tags inside of block level tags. the biggest offender is wrapping an <a> link around block elements like <p> and <div>.
Who Cares About Validation?
If you look for statistics, you see that over 99% of web pages have some invalid code in them. It is easy to understand, considering the complexity of most sites today. The vast majority of pages are created through a server side technology and/or a content management system. These pages are rendered bit by bit from many scripts, sometimes from different publishers. Add to that all the widgets available across the web and you are bound to have a handful of validation errors. Even the most vigilant of us can either rip out our hair or concede and deal with a few errors.
Invalid code is more of the de facto standard across the internet, but that does not mean its ok. Internet Explorer is also the de facto browser across the net, if that means anything to you. Those of us who want to get the most out of our sites will be the ones who code more responsibly and see better results. If you never check the validity of your code, you might end up with hundreds of errors. Compared to that, 5-10 errors don’t look so bad.
If its not enough to write proper markup for its own sake and you don’t believe that it will make a difference in SEO/traffic potential, then please do recognize you will be screwing over people who don’t access the internet like you do. Accessibility is immediately affected by invalid code. If I have a vision problem and I use a screen reader, your content will probably be broken to me.
Remember that, while you can easily read your web page with your own eyes, search engine bots and screen readers only look at code. It will behoove you to make sure that both are able to easily parse your content.
Common Validation Issues
One style of markup some people adopted long ago was writing tags in uppercase. Some people do this so that they could more easily discern their text content from the HTML code. Some people do it because they think it is supposed to be that way. In either case, valid XHTML 1.0 must have tag names in lowercase. Therefore, it is better habit to always use lowercase. HTML 4.01 allows for either upper or lowercase, along with other loose options. The XHTML doctypekeeps a shorter leash on sloppy code, so I use it instead of HTML. For instance, it forces all tags to be properly nested and closed.
While we are talking about doctype, it’s important to mention that missing Doctype declarations are one of the most common validation problems. This can most definitely cause immediate display issues with your site. That de facto browser we mentioned above (Internet Explorer) will automatically switch to a separate rendering mode when the doctypeis missing. Do make sure that you properly format your doctype. Design tools like Dreamweaver automatically place this for you. Make sure it’s the doctype you want. Below are the declarations for both XHTML and HTML in strict and transitional. Notice the case difference between XHTML and HTML.
Solid Tip: Valid doctype declarations are case-sensitive, must go on one line, must be on the first line.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> |
Unclosed tags are also prevalent in markup, even in tutorials. For some reason, some people like to leave the list elements unclosed.
<ul> <li>This is an unclosed list element <li>Maybe they are thinking 'bullet point' </ul> |
A final issue to look for is missing attributes. I find it is so easy to overlook accessibility issues that I must be overly strict about them. Forgetting to add the alt attribute on img tags always makes me slap myself. In my early days of validation, I would just end up putting alt=' '. Hey, I was young and had no idea the implications!
Common Nesting Issues
Improper nesting is a common validation error in markup. It is usually caused by a designer adding an anchor tag around a block element. If the term anchor is unfamiliar, it is referring to links. Designers often have elements in a div element that they wish to make a link. It could be a thumbnail image in a div that links to the larger image or a logo in the header that goes to the homepage. In either case, links are inline elements and are not made to surround block-level elements. It’s supposed to be the other way around.
Solid Tip: We can’t put links around divs! Actually, you can! Make that inline link a block-level link in your stylesheet using display:block. Now it will validate.
I have been spoiled by using Dreamweaver. So much so that I have not cared about overlapping tags for years. Dreamweaver and other developer environments always tell you when your tags overlap. I can’t say with any authority that this problem even exists anymore, but I will mention it here for posterity. This error is still possible when dealing with server-side pages like PHP or ASP. The developer environment may have trouble parsing through regular HTML and server-side code to catch tag overlaps. Since I like to have good habits, I always follow a strict code indent convention that helps me notice anomalies.
Finally, if you read my article on Separation of Presentation and Content, you know it’s a bad idea to have styles outside of a stylesheet. I grant diplomatic immunity to HTML email designers, though. Having the style tag itself in your document is also something I don’t approve of. It is valid HTML when nested in the head, but not the body. Occasionally, you can find this invalidly smuggled inside the body of the document.
Solid Reading
For building better web pages, any of the following books are a great! “Web Design For Dummies”
