

HTML Validation: Does It Matter? - twampss
http://www.codinghorror.com/blog/archives/001234.html

======
mdasen
I think the point of HTML validation is that there was a time when there were
many browsers that behaved incredibly differently with malformed HTML - the
days when everyone was creating their own rendering engine and all of them
were terrible; the days of HotJava and iCab. I'm assuming that the people back
then assumed that we'd get more, not fewer, rendering engines to deal with and
that if there were standard, valid ways of writing HTML, they could all
conform to the standard and life would be good.

Little did they know that Microsoft would come along and tear down that world.
Today, we've seen it bounce back a little, but really there are three
rendering engines - Trident, Gecko, and WebKit. And, compared to what we had
back in the Netscape days, they're all good engines. Sure, we might consider
Trident crap by comparison to Gecko and WebKit today, but it's clearly a cut
above what we were seeing in the Netscape days.

I think the reason that people today don't care about validation is that
perfectly valid code can render differently in the three different rendering
engines. If valid HTML doesn't give you the benefit of proper rendering, then
what value does it give you? If a rendering engine is "wrong" in how it
renders your page, you can bet that's your problem and not the rendering
engine's problem - at least it will be according to your visitors. And three
rendering engines aren't too hard to test - especially given the similarity in
a lot of the rendering between WebKit and Gecko.

As for XHTML and HTML, Apple's "Surfin' Safari" blog has a great post on it:
<http://webkit.org/blog/68/understanding-html-xml-and-xhtml/>. I guess XHTML
never really fulfilled its purpose as having machine readable data in HTML -
possibly eclipsed by things like RSS.

~~~
olavk
As others have pointed out, search engines also need to parse your pages to
extract text and links. You can't really test if Google parses malformed HTML
the way you think it ought, so I would say better safe (valid) than sorry.

------
anatoli
I wish people who know little about HTML, XHTML and CSS wouldn't write such
posts just for the hell of it. Jeff is a respected programmer, but front-end
developer he is not.

I'm not going to go into details of why he's wrong, because a) this has been
discussed to death by people who actually matter in this space, and b) there's
a ton of comments on his post explaining what's wrong with his view.

There are ways to argue that validation is unnecessary; however, they do not
include: 1) bringing up examples such as "target" attribute, and 2) saying
"who cares if it works anyway."

~~~
biohacker42
I don't know any programmers that respect Jeff, I can't imagine any who value
C would respect him as a programmer.

Jeff is a respected blogger.

~~~
req2
Jeff is a popular blogger.

------
tokenadult
Two consecutive comments to the submitted article:

"Google actually ranks it's indexed pages. The more valid the (X)HTML of your
pages, the higher it'll appear in a search."

"If you do write XHTML, you'd better get it right. I heard about CodeProject
practically dropping off the map because of an XHTML error that caused Google
to stop ranking them."

Is this indeed documented or well confirmed behavior of Google? That might be
a pretty important reason to validate.

~~~
anatoli
As the Google crawler is a just a basic HTML parser, it makes sense that
certain errors could cause major problems for a site — messed up nesting,
missing quotes, etc. Google likely has fairly sophisticated error recovery in
place, but I'm sure it doesn't cover everything. As such, it's always to one's
advantage to validate their site in order to minimize friction.

------
ejs
Building an entire site, then fighting with it to make it validate is
obviously going to be frustrating. Would you wire up a house, then whip out
your electric code book and go back to fix everything thats wrong? Just
because you don't agree with something, and it still works doesn't mean its a
good idea...

Anymore I actually like validating, I use it to check to make sure nothing is
blatantly wrong. There are a few rules that do not make much sense, but
overall I find it very helpful. But to make use of it this way don't go and
build the whole site, then try to fix all the problems and bad decisions made
earlier, use it through out the design process.

I know this blog post comes to this same conclusion by the end, but it just
feels so wimpy and pandering to everyone. Through the whole post it goes from
validation is pointless, painful, useful, helpful... do whatever you want.
Maybe the author should just take a stand and stop trying not to offend
anyone.

------
Hexstream
The interpretation of valid HTML is standardized. The interpretation of
invalid HTML is undefined. Make your choice.

Error handling is not defined in the standards so if you rely on it you're at
the mercy of every idiosyncratic error handling decision of every
idiosyncratic browser implementor.

------
carlosrr
HTML validation is of great value when debugging, even javascript. It can
discover things that are easy to miss like unclosed tags and repeated ids.

It is difficult to write a whole website, validate it and fix the errors and
at this point validating has little value. However by validating periodically
you are getting more out of the tools available. I don't force myself to write
100% strict HTML, but minimizing the validation errors means that I will have
less to read when it's time to.

------
jrockway
Validation probably doesn't matter to your users anymore. (If everyone wrote
valid markup back in the day, browsers would be faster, more secure, and more
stable. But that ship is sailed, so you're stuck with broken browsers for
backwards compatibility reasons.)

With that in mind, though, it's easy to write valid markup. All the rest of
the code in your app has to validate, why negelct the HTML? Making sure that
your markup is valid will save you time when you have to debug a weird
rendering issue (or JavaScript's view of the DOM).

Finally, if you even have the opportunity to pass invalid markup from your app
to the browser, you are probably doing something wrong. In my apps, I load the
web designer's templates (which may be invalid HTML) with libxml2 (it has an
HTML loader), process them programatically, and then serialize the DOM for the
browser. This way, the browser always gets something valid -- my program's
type system enforces this.

Valid HTML means you have one less thing to worry about.

------
jollymoon
Never can tell??

A couple of days ago I built a new webpage and as usual tried to validate my
HTML 4 strict and CSS 3 . The HTML4 validated just great with CSS2.1, but
threw a tantrum when I posted the CSS3 validation code and reran HTML4 Strict.

This is the offending line:

&profile=css3&usermedium=all&warning=1

which is OK on the CSS validation page, but will not pass inspection if ran
AFTER posting the WHOLE link to my web page. Everything is the same except for
that last line.

Run as CSS2.1 and all is well.

Run as CSS3 and the validator gives 6 errors on this part of the code alone.
It seems to hate the " & " and the " = " and even the " W " in warning?? !!

Would like to validate HTML 4.01 Strict with CSS3.

Any help??

------
sethg
It seems to me that validation would be especially helpful when you're
composing one Web page out of a bunch of smaller components; if, say, each
component is in its own <div> and your validator confirms that it's a proper
<div>, then you can have more assurance that your code will stitch them all
together into proper <html>. If one of the components is invalid, you run a
greater risk that when that component is included in a page with other stuff,
the interaction among all the pieces will create an ugly surprise.

------
ars
My rule is this: it must validate unless you have a good reason for it not to.

When I develop I use a firefox addon <http://users.skynet.be/mgueury/mozilla/>
that automatically tells me how many validation errors I have (it runs the
validation locally).

So as much as possible my code validates, but sometimes it doesn't - but each
time, there is a reason for it, and it's not just an accidental mistake.

------
jlujan
Ever try debugging javascript in a dynamic site with invalid HTML... enough
said. No, the user shouldn't care but so little of the code we write is
actually _for_ the user.

