Integrated Web Design: Seven Deadly Markup Sins
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Despite all the attention on Web standards in the past few years, there are ongoing problems with document conformance when it comes to HTML and XHTML.
I was recently involved as a judge at the HOW design contest, and have served as a judge for the Webby Awards—which recently announced their winners for 2004. Although both contests place emphasis on quality design and content, there's little attention paid to standards. I'm sure that readers can just picture me viewing source and validating sites because hey, that's what I do. Alas, the results were very distressing. Out of several hundred sites—many of them extremely prominent, well-known web sites—only a mere handful conformed to HTML or XHTML specifications.
What's encouraging about many of the sites is that some attempts by designers and developers to adhere to standards are obvious. What's discouraging about the sites are the kinds of errors showing up. Many of these errors are incredibly easy to repair! Of course, some sites are relying on problem Content Management Systems and others are being served markup via their ad server provider. In those cases, errors are introduced that are beyond the developer's immediate control.
No matter the cause, all developers would do well to take a look at the top seven mistakes I found within these sites. By looking at what we're doing wrong and how to do it right, we can quickly address poor markup practices and create more compliant documents.
1. Document Encoding Problems
Although document encoding does not influence a document's validity per se, it does influence the capability of that document to be validated and properly displayed. Unfortunately, it seems that many designers and developers are unaware of the need for encoding.
Document encoding describes the character set that is being used. Documents in English, for example, have long been identified with the character encoding iso-8859-1, which is the Latin character set. In recent years, we've been able to tap into UTF-8, a more universal character encoding standard.
In an ideal world, all encoding is done on the server. In this scenario, the server administrator sets the proper encoding via the HTTP headers. This can be done with any kind of web server—check with your systems administrator and find out whether encoding is set. If so, you're good to go and do not need to add any additional information about encoding.
However, if your server does not have encoding set, there are two alternative means of adding encoding information. You can add the encoding via a meta element, as follows:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
If you're using XHTML and want to include the XML declaration, you can include your encoding there, as well:
<?xml version="1.0" encoding="UTF-8" ?>
Of course, there are problems related to using this declaration (also referred to as the XML prolog). If IE 6.0 encounters it, it won't flip the DOCTYPE switch. (If you're not familiar with DOCTYPE switching, read on.) Other problems with the prolog include rendering issues on many older browsers that simply do not recognize the XML syntax or attempt to render the document as an XML tree rather than the document itself.
Another problem that's showing up a lot now that the W3C has upgraded its markup validator is document encoding mismatches. This problem comes from instances where the encoding is, as recommended, set on the server, but the document author includes a conflicting character set.
So, to effectively manage these problems, follow these steps:
Check with your system administrator and ascertain which encoding type is set for your server. If it's set properly, do not add a meta element within your documents. Be careful because many tools automatically add the encoding for you. In those cases, strip out the meta element to avoid conflict and unnecessary markup.
If document encoding isn't set on the server, you may have to resort to using the meta element solution. It's not ideal, but it will work and will allow you to validate your document without causing warnings to occur.
NOTE
For more information on this issue, please see the article, "WaSP Asks the W3C: Specifying Character Encoding."