Working With Images in PHP - Part 1: Rotation
Topaz Simplify 3 Review
Happy Labor Day!
The Secret to Effective HTML Page Title Tags
The CS5 CSS Starter Page Series - Part 9: Quality AssuranceAs a web designer, your goal is to create a page that works well and looks good across a large variety of browsers and platforms. Validating your (X)HTML and CSS is a way to achieve this goal. If you've ever spent hours tearing your hair out trying to understand why your page was broken, only to finally have a colleague point out one tiny little typo in your markup that was the root cause, it's time you gave validation a try. I'll first explain why validation is important, then describe how to do it.
Note: In this article, when I use the term "(X)HTML," I am referring to both XHTML and HTML.
(X)HTML is a markup language, and CSS is a style sheet language. Just like spoken languages, they have set vocabularies and rules for using those vocabularies. Although browsers once focused on creating their own HTML elements, essentially creating their own "words," the languages of (X)HTML and CSS have since been standardized by the World Wide Web Consortium, or W3C. Browsers can still invent proprietary elements (or "words" that only they understand), but the last few years has brought a shift towards complying with web standards so that everyone can speak the same language.
Browsers understand the languages of (X)HTML and CSS (some better than others, admittedly), so that when you use a ul element, for example, it knows what to do. But browsers are not as smart as people are. If you and I speak the same language, and I make a grammatical mistake, you'll probably still be able to figure out what I'm trying to say. Browsers try to work around mistakes in language as well, but they just don't have the reasoning abilities that you and I do. If there is a mistake in your markup, the browser will try to figure out what you meant and display the page to the best of its ability. But often, what it thinks you are saying is not what you intended to say, and your page comes out looking awful.
Even if your page looks just fine in your browser, another person's browser may not be so forgiving or adept at managing your mistakes. Whether your page looks right to you is not a measure of whether it is actually written correctly, or whether it will continue to look right in future browsers or new user agents, such as PDAs, cell phones, and other new technologies.
Validation is a way to catch the pieces of our markup that don't obey the rules of (X)HTML or CSS. If our markup and styles are free of errors, they are more likely to display reliably in a wide variety of browsers, and are also more likely to be future-proof to new browsers that will come along later. As browsers become more focused on web standards and more strict in adhering to those web standards, valid code will become more and more important to ensure that our pages are working well and will continue to do so.
Even though validation is an important step for your web pages to go through, it is simply a tool to ensure that your pages will work well, not the end goal itself. Sometimes, you may validate your (X)HTML or CSS and discover one or two errors that you knew were going to come up but you cannot fix, or perhaps even choose not to fix.
A good example of this is when you use the display value of "inline-block" in a style sheet. This value was not part of the CSS 2.0 specification, and this is the default profile the W3C's CSS Validator checks against, since it is the latest complete specification. However, this value is part of the CSS 2.1 recommendation. If you use "inline-block," your style sheet will not validate at this time, but since you know this is only because of a value that has not been entered into the validator software, but is actually valid in the newer profile, you don't have to worry about it.
If you are aware of the cause of the errors, and you are confident they are not doing your page any harm, you can leave them in there without feeling guilty. You can always test to see if an error is causing any rendering problems by removing the portion of the document with the error in it and viewing your page again in a variety of user agents. If it looks the same as before, chances are your error is not a serious problem. Validation is a means, not an end.
It's also important to not let your valid page give you a false sense of security. Just because your page or style sheet is valid does not mean that it will work perfectly across all browsers. The validator does not know how different browsers will handle your markup; all it knows is what is correct according to the syntax. Every browser has bugs in the way it renders (X)HTML or CSS, so you'll always run into rendering problems in browsers whether or not your markup is valid. Validation just makes these rendering problems less common and easier to fix.
Also, just because your page or style sheet is valid does not mean that it will look or work just how you expected it to. A validator can only check if the content of your page complies with a limited set of rules — it can't tell if what you wrote in your (X)HTML actually makes any sense or follows current best practices. For instance, you may use a CSS selector like this to try to make the links in your sidebar black:
#sidebar p, a {
color: #000;
}
This is a perfectly valid selector, but you may be confused when you view your page and see that all the links across the page are black, not just the sidebar ones. This is because what you really meant to write, in order to target only the sidebar links, was this:
#sidebar p, #sidebar a {
color: #000;
}
However, the validator cannot read your mind — all it knows is that the first selector didn't break any rules, so it marks it as valid. It's kind of like making up a nonsense sentence, like "The green whale flew beside the shoe." This is technically a correct sentence — it has a subject, verb, and object, plus no punctuation or spelling errors. It just doesn't make any sense. You can do the same thing with your (X)HTML or CSS: use it in correct but goofy ways, which can lead to correct but goofy rendering.
All this being said, I want to reiterate how important it is to use validator software to help you find and correct mistakes in your documents. There are several online services who provide validation, but I will focus on the validators straight from the source, the W3C.
You validate your (X)HTML document by running it through software that checks what you've written in it against your page's document type definition, or DTD. The DTD is itself a document that specifies the syntax of (X)HTML: the allowable elements and their associated attributes within a document (the vocabulary), as well as what each element can contain and where each element and attribute can be used (the rules).
The W3C Markup Validator is a free online service. You simply enter the URL of your page, upload a file, or paste your markup into the text area provided. The validator uses your document's document type declaration (known as a doctype, and not the same as a document type definition!) to see which DTD to check your page against. If anything in your page doesn't match up with the DTD for your doctype, it tells you that your page is not valid, then lists the errors and warnings it found, with line numbers and a brief explanation of each.
If your page is dynamic, you want to validate the markup that is output by the server, not the code itself that is going to be producing the markup, so always use the URL method with dynamic pages, not the file upload or direct input methods.
You validate your style sheet by running it through a validator that checks what you've written in it against a profile. A profile is a CSS specification or something that is on its way to becoming one, such as a CSS recommendation. Just like a DTD, it contains the vocabulary and rules for the language of CSS.
The W3C CSS Validator is a free online service. As with the Markup Validator, you can validate a page by URL, file upload, or direct input. Since a style sheet does not specify which profile it is using (as an (X)HTML page does with its doctype), the validator assumes you are using the latest version of the CSS specification and uses that profile to check your style sheet against. If you want to validate your style sheet against a different profile, you can use one of the advanced interfaces of the CSS Validator, which allow you to select the profile to validate against. Once again, if some content of your document doesn't match the selected profile, it tells you that your style sheet is not valid and lists the errors and warnings.
The CSS Validator accepts more than just .css files, which is handy if your styles are embedded or inline, instead of linked or imported. Just put in the URL to your (X)HTML page (or CFM page, etc.), and the validator will find the styles in it and validate them. It can also find and review linked or imported style sheets this way, but it is recommended that you validate external style sheets directly, not by submitting their parent pages to the CSS Validator. This is because if the XHTML page has errors or warnings itself, trying to validate its external style sheet can result in the error "Please, validate your XML document first!". To avoid this, simply validate all external style sheets directly, rather than through the page they are linked or imported from.
Although the explanations for the errors have improved over time, it can still sometimes be difficult to understand what the validator is trying to tell you. The best advice I can give you here is to familiarize yourself with the W3C specifications. The more you get used to reading these, the more you will be able to interpret the validation errors that come up for your documents. Practice reading the W3C specs also gives you a firmer understanding of how (X)HTML and CSS work, making it less likely that you will make syntax mistakes in the future.
A handy way to validate your pages is to use the Web Developer Extension for Firefox and Mozilla by Chris Pederick. It adds a toolbar to your browser with buttons that submit the page you are currently on to the Markup or CSS Validators, as well as quick links to the W3C specs.
In the results of both the Markup and CSS Validators, you may receive errors or warnings, or perhaps a little of both. The difference between an error and a warning is that a warning is something that is valid according to the DTD or profile used, but is likely to cause problems in the browser. The most frequent one you will see on style sheets is that a background color has been set but the foreground color has not, or vice versa. This can be dangerous because if a user has his browser preferences or user style sheet set to show backgrounds in a certain color, and it just happens to be the same color as what you have set the text to, your text will now be unreadable to this person. This can be a serious accessibility problem when you are dealing with the body of the page, but with nested elements where background colors are transparent and allow the body background to show through, it not as dangerous to declare color without declaring background color.
It is up to you to review and understand the warnings, then decide whether it is important to fix them or not. If you do so, it will be less likely that your page will break for certain users or become unstable in future browser versions, but there are certainly times when it is safe to ignore the warnings. Testing your pages in the widest variety of user agents and platform setups will help you make this decision.
If you validate your page and find that it has dozens — or even hundreds — of errors, stay calm. Often times, a single error at the top of a document will spill down and cause errors throughout the rest of the document. For instance, if you forget to close a span element, you will not only get an error about this, but you will trigger several additional errors due to elements that are not allowed to be placed inside span elements. If you fix the first error by closing the span, the other errors will go away. Just take the errors one at a time, viewing and re-validating your page as you go to see how it is doing. It's probably easier to make your page valid than you think!
Keywords
XHTML, CSS, style sheets, validation, validating, validators, markup, World Wide Web Consortium, W3C, DTD, profile, specification, syntax, debugging, errors, warnings
