How much time should I put into validating my HTML and CSS?

Question

I'm making some pages using HTML, CSS, JavaScript and PHP. How much time should I be putting into validating my pages using W3C's tools? It seems everything I do works but provides more errors according to the validations.

Am I wasting my time using them? If so any other suggestions to make sure I am making valid pages or if it works it's fine?

Answer 1

You should validate your code frequently during development. E.G after each part/chunk revalidate it, and fix errors immediately. that approach speeds up your learning curve, since you instantly learn from small mistakes and avoid a bunch of debugging afterwards, that will only confuse you even more.

A valid page guarantees you that you don't have to struggle with invalid code AND cross-browser issues at the same time ;)

use:

• Markup Validation Service for HTML
• CSS Validation Service for CSS
• JSlint for Javascript
• jQuery Lint for jQuery

Avoid writing new code until all other code is debugged and fixed

if you have a schedule with a lot of bugs remaining to be fixed, the schedule is unreliable. But if you've fixed all the known bugs, and all that's left is new code, then your schedule will be stunningly more accurate.(Joel test rule number 5)

Answer 2

Yes, you should definitely spend some time validating your HTML and CSS, especially if you're just starting learning HTML/CSS.

You can reduce the time you spent on validating by writing some simple scripts that automatically validates the HTML/CSS, so you get immediate feedback and can fix the problems easily rather than stacking them up for later.

Later on tough, when you're more familiar with what is and what is not valid HTML and CSS, you can practically write a lot without raising any errors (or just one or two minor ones). At this stage, you can be more relaxed and do not need to be that adverse about checking every time, since you know it will pass anyway.

A big no-no: do not stack the errors up, you'd be overwhelmed and would never write the valid code.

Answer 3

Do you necessarily need to get to zero errors at all times? No.

But you do need to understand the errors that come out of the validator, so you can decide if they're trivial or serious. In doing so you will learn more about authoring HTML and in general produce better code that works more compatibly across current and future browsers.

Ignoring an error about an unescaped & in a URL attribute value is all very well, until a parameter name following it happens to match a defined entity name in some browser now or in the future, and your app breaks. Keep the errors down to ones you recognise as harmless and you will have a more robust site.

For example let's have a look at this very page.

Line 626, Column 64: there is no attribute "TARGET"
…             get an <a href="http://openid.net/get/" target="_blank">OpenID</a>

That's a simple, common and harmless one. StackOverflow is using HTML 4 Strict, which controversially eliminates the target attribute. Technically SO should move to Transitional (where it's still allowed) or HTML5 (which brings it back). On the other hand, if everything else SO uses is Strict, we can just ignore this error as something we know we're doing wrong, without missing errors for any other non-Strict features we've used accidentally.

(Personally I'd prefer the option of getting rid of the attribute completely. I dislike links that open in a new window without me asking for it.)

Line 731, Column 72: end tag for "SCRIPT" omitted, but its declaration does not permit this

    document.write('<div class=\"hireme\" style=\"' + divstyle + '\"></div>');

This is another common error. In SGML-based HTML, a CDATA element like <script> or <style> ends on the first </ (ETAGO) sequence, not just if it's part of a </script> close-tag. So </div> trips the parser up and results in all the subsequent validation errors. This is common for validation errors: a basic parsing error can easily result in many errors that don't really make sense after the first one. So clean up your errors from the start of the list.

In reality browsers don't care about </ and only actually close the element on a full </script> close-tag, so unless you need to document.write('</script>') you're OK. However, it is still technically wrong, and it stops you validating the rest of the document, so the best thing to do is fix it: replace </ with <\/, which, in a JavaScript string literal, is the same thing.

(XHTML has different rules here. If you use an explicit <![CDATA[ section—which you will need to if you are using < or & characters—it doesn't matter about </.)

This particular error is in advertiser code (albeit the advertiser is careers.SO!). It's very common to get errors in advertiser code, and you may not even be allowed to fix it, sadly. In that case, validate before you add the broken third-party markup.