: HTML validation: is it worth it? What are the advantages and disadvantages (if any) of making sure that all pages validate compared to having non-valid HTML that however works on all major browsers?
What are the advantages and disadvantages (if any) of making sure that all pages validate compared to having non-valid HTML that however works on all major browsers?
Also, is having valid HTML after Javascript executes just as important?
More posts by @Sent6035632
15 Comments
Sorted by latest first Latest Oldest Best
Google and Bing do not, have not and will never use CSS or HTML validation as a ranking factor.
The majority of websites have dozens to hundreds of errors and you need not worry about them because all search engines care about is how the page renders. Just ensure your website renders correctly in all major browsers and Google's Fetch.
Even if your HTML works on all major browsers, it's still worth doing as it sometimes can cause problems with search engine crawlers like googlebot. For example see this:
www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx
A point nobody has yet mentioned is that invalid HTML can cause slower rendering times whilst the browser is trying to make sense of the non standard HTML when displaying.
Validation is useful because it can help you spot some hard-to-catch errors such as
<input name=foo value=<?php echo htmlspecialchars($_GET['foo']); ?> />
or unpredictable browser behavior (for example, putting block elements in an a can sometimes break in ugly ways in Firefox).
Validity helps you avoid incompatibilities and helps keep code maintainable. Browsers recover from markup errors, but sometimes in very unintuitive ways.
DTD-based (HTML4, XHTML1 @ W3C) — Might not be worth it. DTD is primitive and, e.g., cannot check validity of most attributes. You'll mostly get hard to understand errors about entities and nesting.
HTML5 validator — Yes. Definitely. HTML5 is more pragmatic and allows some harmless constructs that used to be errors. OTOH Henri's validator is much more thorough and better at discovering real problems.
Validity of JS-generated code might matter, as browsers operate on DOM, regardless how it was created. If you use document.write(), then you even have to take care to get syntax correct (it goes through same parser as page source).
One point no one's mentioned is future browser developments. Though all today's browsers handle invalid markup relatively well, that may not always be the case.
Browser makers in the future will be ensuring their browsers work to HTML/XHTML standards, so this is what web developers should be hitting as well. Just because a particular bit of invalid markup works now doesn't guarantee it will work in future browsers.
I think it's definitely worth doing, but you should never be a slave to validation -- it's a fool's game.
www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html
Validate your HTML. Know what it means to have valid HTML markup. Understand the tooling. More information is always better than less information. Why fly blind?
Nobody cares if your HTML is valid. Except you. If you want to. Don't think for a second that producing perfectly valid HTML is more important than running your website, delivering features that delight your users, or getting the job done.
Some HTML validation errors can cause non-obvious layout issues (e.g. wrongly nested/unclosed tags), JavaScript bugs (e.g. using an id more than once), and issues for some users (e.g. not including a meaningful or blank alt attribute on images).
If all our pages validate, that’s a nice automated check you can do to rule out sources of errors. If you leave some validation errors in because you know they’re not causing any harm, your check is no longer automated: you have to look at each error, and remember that it’s okay. Personally, I prefer it when computers reduce the amount of work I have to do rather than increase it.
The best approach is to learn which invalid HTML is bad, and which invalid HTML does not matter.
For example, forgetting to close a <div> tag is very bad, because your layout will almost certainly screw up in one or more browsers.
However, using <br> instead of <br /> in XHTML does not matter - all browsers will interpret both as a line break without problems. Using the target attribute on links is invalid, but the worst case scenario is that the browser doesn't open the link in a new window.
One reason to test your site for valid HTML is that it ensures that the search engine spiders will be able to fully index and determine the meaning of your pages. If they cannot do so due to malformed HTML (which the major browsers may work around for historical reasons) then you are potentially limiting your search engine rankings.
There has also been speculation that while the major search engines do a good job of dealing with malformed HTML, they may also assign page quality "points" for validity, further affecting your ability to rank as high as your content deserves.
When running the validator, you'll need to examine the errors it gives you on a case-by-case basis. Is validation important? To me, yes, it's very important. But is it a requirement? No.
Things like using the same ID multiple times (instead of a class), putting block-level elements inside inline-level elements (usually these elements don't fit this way semantically either), missing alt attributes on images (poor accessibility for the impaired), are all important. Things like unknown attributes on tags are NOT important. At all. Javascript frameworks like Dojo or that awful Meebo social-media bar use custom attributes as hooks, and the HTML spec states that these are allowed, and that any unknown attribute is to be ignored. The validator doesn't ignore them, though, it throws errors. These errors can be ignored.
When validating, do not just assume that if you have errors you're doing it wrong. Semantics are vastly more important, and it just so happens that valid HTML is more-often-than-not the natural result of having proper semantics.
there is no disadvantage of having valid html. there is a reason why there is a spec in the first place and why a lot of effort is being put into the spec to define how things should work.
basically, all you gain is to meet the specs. which in turn means, programs written to read html (browsers, bots) can not blame YOU for not meeting the specs if something goes wrong. and some of these programs give you extrapoints (higher ranking in search engines if the bot reports "meets the spec"). if you meet the specs you will be caught much less by surprise if some browsers do not render broken html the way you think it should.
so, to meet the specs and write valid html is good for you, no disadvantages at all.
I think it's worth it, as I've caught many markup and logic errors by seeking validation. It's one of those "necessary but not sufficient" things. Valid markup, like code that compiles (or checks out via JSlint) free of errors, warnings, and hints, is a good first step in getting it right.
I consider valid HTML a worthwhile goal, but do not see it as the be-all and end-all of building good websites.
The trick is, your markup may be perfectly valid, yet it may not be semantic - e.g. using tables for layout or navigation. There's a difference between valid code and semantic code.
On another note, if you use advertising or external scripts, they may insert their own markup which has a chance to really mess with your own.
Validation in of itself isn't so critical, since few browsers are 100% compliant and the spec isn't 100% clear on how to interpret the rules.
However being valid HTML puts you in a better position to adapt and improve your site. As the standards move, they will typically migrate forward and if you new site is valid, then updating to support the latest thing should be easier.
Bottom, being valid makes it easier to stay on top of the game and be as compatible as possible with the widest audience.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.