It's a matter of what you think your responsibility is to the wider developer community. If you're within some very small percentage instead of just a small percentage, things improve. As the old saw goes, it's never the same small percentage. Go from 99% to 99.9% and you reduce the possible set of global "quirks" by at least some factor, maybe not the full order of magnitude, but enough to make a difference in how difficult it is to create browser tech, and that's one more strength for the web to leverage for its growth.

Maybe you don't care personally. Certainly that's been the tone of this blog of late. But it's worth considering.

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. Also, I've heard Safari can refuse to render XHTML that's not according to Hoyle. Apparently spiders and browsers expect sloppy HTML, but if you say you're writing anal-retentive XHTML, they take you at your word.

> Go from 99% to 99.9% and you reduce the possible set of global "quirks" by at least some factor

Given everything I've learned to date about browser idiosyncracies, I find it very hard to believe that validating as HTML 4.01 strict will make any difference whatsoever.

For one thing, validating HTML says *nothing* about the CSS or JavaScript that drive most sites these days..

1. validating as xhtml 1.0 transitional is pretty easy nowadays, strict less so. However, try writing css that validates and works in internet explorer. If you can't write xhtml that validates, there's something wrong with your tools. But this isn't about bashing Microsoft again. Okay it is, they're an easy target.

2. Ever wonder why web browsers are so hard to build? Why they are chock full of security bugs? Ever considered writing your own web browser? I didn't think so. The reason so many xhtml parsers are fail fast is because we want to get away from this "liberal about inputs" world and return to a somewhat more sane "fail on bad inputs" world. Even writing a simple html parser for web scraping purposes can be such a waste of time because you *have* to assume the input will be invalid.

3. It's not terribly important for your site or your users to be good about (x)html validation but it is for the community at large. Which basically means everybody will start caring around about the same time pigs start flying.

I don't find writing proper (validating) XHTML strict any difficult, once you learn what is allowed or not. To me XHTML makes more sense than HTML 4, if we are going to write pseudo XML then why not write real XML ?

I'm not by any means a front end guru, but I would think that valid html would get much more important when it came to 508 compliance. Screen readers will get confused a lot more easily than browsers, and invalid html can't help the situation.

"Nobody cares if your HTML is valid"
As pointed out if indexing and your google ranking does not matter then take Jeff's advice of "it is up to you" otherwise validate your pages.

> The reason so many xhtml parsers are fail fast is because we want to get away from this "liberal about inputs" world and return to a somewhat more sane "fail on bad inputs" world.

The sooner we can smash pandora back in that darn box, the better off we all will be!

I dunno, there's a fine line between thought leadership and tilting at windmills. Validate if it's important to you. But realize that it's a small part of the overall equation.

> if we are going to write pseudo XML then why not write real XML ?

Indeed, why write a comment when you can write a novel? Why pilot a boat when you could captain a battleship?

No, really, why whould you expect target= to work in *strict* DTD? It's a frmes related attribute and as such is valid in frames DTD only.

And as to it being harmless... No, it isn't. It's a quite basic usability breaker. See, normal link (no target=) opens wherever I want. If I want it in the same window/tab it will open there. If I want it open in a new one -- it will open there, as instructed. But there's no fscking way to tell your browser to *not* open it in a new window/tab if you don't want it to.

@Vordreller and John: citation needed.

> Apparently spiders and browsers expect sloppy HTML, but if you say you're writing anal-retentive XHTML, they take you at your word.

Even if that's true, virtually nobody does that, anyway. Serving true XHTML is more than simply adding a doctype or a xmlns attribute, and if spiders relied on just that, easily more than half the websites which claim to use XHTML (via doctype) would be dropped from their index.

The opinions in this post are very similar to my feelings on using FxCop in .NET development. FxCop finds a few important defects very quickly for you *if* you've been fixing violations all along.

But, if you never fix the "Specify IFormatProvider" and "Specify CultureInfo" errors, you'll never find the "Exceptions should be public" errors that bite you in the future. I think electrical engineers refer to this as the signal-to-noise ratio.

I fully agree with this post: HTML validation, as it currently stands, is only useful for finding structural errors in your code, such as mismatched tags.

For one thing, lots of things that are illegal are, as you said, impossible or impractical with valid code. Javascript elements can only appear in certain places. Anchors can't have targets. There are other examples. In many cases the validator is essentially wrong, since no browser implements those rules. I believe HTML 5 is relaxing the rules a bit because of the way the browsers actually work.

Other things are just noise warnings for HTML: URLs are supposed to be SGML escaped (i.e. & -> &). This never matters in practice, so why do it?

I do agree that <td width="80"> is wrong, however, and so is <td style="width:80px">. The width should be declared in the CSS for the page. I wish HTML validators could highlight style= as an error, to make it easier for me to find hard-coded styles.

Basically what coven said: No target attribute is a feature. If I want your link to open in a new window (which is never) or tab (which is often), I will do it my goshdarn self, thank you very much.

Seems like new window links are really a behavior issue and don't necessarily need to be markup elements anyway---use Javascript for that.

The target attribute is so much a better way to open anything in a new window than doing it with JavaScript... At least the browser (Safari does it) can tell the user "this link will open a new tab/window". This is way more accessible and user respectful.

I hate it when I click on a link and it opens a new window (because my Safari is set to open target="_blank" in new tabs).
And, as a developer, I continue to use target="_blank" for external links.

I think target attribute is forbidden on strict html/xhtml because it breaks history, can do weird things if the user doesn't notice the new window, etc. But doing STRICT and doing the exact same thing with JS is just stupid (even MORE stupid if they say "we're xhtml strict valid").

My initial reaction to the removal of "target" was negative. I thought it was stupid. Then I thought some more and figured out the theory behind it. XHMTL is trying to do the MVC pattern with the markup being the model. Actions, like opening in a different browser are in the controller, which is browser and if you want to do custom browser behavior, you use JavaScript. So it make sense from the theory perspective. But my final conclusion rest in change and that people only like change that makes things better. This makes things harder and more bug prone, especially for non-developers. So I agree with you that XHTML strict is likely to be a developer only markup.

Just you wait to you see XFORMS, XHTML has nothing on them.

I would say validation should be important to developers. As HTML and CSS continues to evolve and become more advanced browsers will have no choice but to begin being more and more strict and when they do the broken HTML will be truly broken. One must also wonder what kind of impact these loose interpretations have on the performance of browsers since they have to spend a lot of time fixing stuff that should be done properly in the first place.

Rather than looking at the short term as everyone usually does, perhaps if everyone moved to valid HTML/XHTML we would have higher visual consistency in different browsers over time. It's a lot easier to code a display engine if everyone is following the same rules.

+1, for the removal of the "target" attribute.

Oh, how I hate those sites that thing they're so important that they can take over my browser experience.

XHTML has no advantage over HTML as of now, since IE doesn't support true xml. They won't in the future either.

http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

It's fairly easy to make a HTML-Transitional page fully validate though.

It's also worth noting that valid (X)HTML is MUCH easier for screen readers to parse. They aren't (always) as forgiving as your standard web browser.

Nor are the cut-down browsers in mobile devices, or in browsers that support older systems (ever try to surf using Lynx? THAT'S masochism)

Valid (X)HTML isn't just a nicety, it's the ramp outside the store, right next to the handicapped space. Just because YOU are sighted, not color blind, and can read 8-pt font comfortably doesn't mean everyone can.

It's also worth noting that if you use the web for a business and your website isn't accessible to screen readers, you may run afoul of some local laws.

It is very sad to read this post. I seriously doubt that the W3C standards were created just for the fun of it! I think the root of the problems lies in the forgiving nature of the EARLY browsers, newer browsers would then have to be forgiving as well, otherwise nobody would use them since they might not display your favorite site correctly (or at all).

BUT why not make things better? I'll wager that if browsers only displayed valid (X)HTML everyone would create valid (X)HTML. So I'm soooo glad XHTML Strict are really anal about validation!

If everyone then again had valid HTML, I'd bet a lot of things would be easier, e.g. parse XHTML via XML DOM...

Regarding JavaScript, if the JS engine only allowed "valid changes" to the DOM then there would be no problem.

Of course JS should be valid ecmascript (or whatever it's called this week) and the same really applies to CSS.

The attitude: "its hard to implement and it works anyway, then I can't really be bothered" (IMHO) effectively prevents unleashing the full power of HTML/the web.

Few points:

1) target="_blank" breaks (to some degree) the consistency of the web. If people want a new window, they can right-click->open in new window. If they want to replace your site with the new one, they'll just click. If they want it in a new tab, they'll middle-click. target="_blank" breaks all of that good standard Web stuff. Even if you insist on your nonstandard behaviour, chuck it where it belongs: not in the document structure (probably in the Javascript).

2) <td width="80">
<br/>
.. versus this way?
<td style="width:80px">
<br>
- both of these are wrong. 1st one has terrible hard-to-correct in-page styling (chuck it in a stylesheet!) and the 2nd is worse: in-page styling AND a malformed line break element (which even when written correctly is rarely/never necessary if you have decent mark-up. But it's legal, so fair enough).

3) Why build away from standards? XHTML Strict isn't *that* hard (apart from if you want to keep the web-distorting _blankness). Get it right now. Doing mark-up quickly while doing it well is only zero-sum if you aren't very good at it, in which case: pay someone to do it.

I generally like your posts but I am disappointed to see a prominent blog like yours advocating invalid markup and I feel sorry for those who follow your bad advice on this post.

Sloppy code, everyone is doing it and it works well enough so why bother to do it right, no one notices the code seems to be your message. Anyone who calls themselves a web developer ought to care enough to do it right or get out of the way and let someone who does care do it.

You are right to call out the popular sites that are not valid, they should be shamed into doing better, you are wrong to endorse bad practices just because there is so much successful crap out there.

Maybe its difficult to validate a site once you've waited until its all developed and in production, but with modern tools and awareness it is not difficult to build valid XHTML Transitional ASP.NET applications.

Joe Audette
Founder of mojoPortal an Open Source CMS that does produce valid Xhtml.

I have not looked at the sites listed, but do they say they apply to HTML 4.01 strict? Or have you validated with strict anyway? If you say your site is transitional or frameset it should be validated for that.

Maybe because I am a programmer I prefer strict. And I would probably use XHTML if the browsers really would support that. Firefox at least tell it likes XHTML. IE does only do */* as accepted data. I hate that. Now it was probably over a year since I last tried what browsers really accepted XHTML, so it probably lot better today. But with the world still being owned by IE6 I stick to HTML 4.01 strict.

I'm a bit disappointed that you don't get why target=_blank is bad. Here are some links:

http://www.useit.com/alertbox/990530.html
http://www.snyderconsulting.net/article_7tricks.htm#7

"a perfectly harmless attribute for links that you want to open in a different browser tab/window"

Therein be part of the problem - actions that *you* as developer want to happen to the user's machine, regardless of the user's wishes. For accessibility and usability reasons the user/user agent should remain in control of behaviour. Using JS is a better fit to separate behaviour from content but arguably this particular practice is undesirable anyway.

XHTML is just as easy to handcode as HTML once you are used to either one of them. Is this the same question as 'why does PHP need semi-colons at the end of each line when Python doesn't?', or 'why do I need a closing brace as well as an opening brace?' As noted though, sending XHTML is normally utterly pointless unless sent as application/xhtml+xml.

You're right that nobody cares if your code is valid except you, but it's akin to writing a statistical report where, because of rounding, the percentages don't add up to 100%. It doesn't really matter at the end of the day, but it's lazy and could confuse/give extra work to the reader (browser).

I agree with you completely. Validating your HTML is very useful since it exposes some obvious problems that could turn into real headaches. But, things like the target attribute are ridiculous. I actually ran into that recently.

So, I tossed the idea of completely validating my code right out the window. I used the validation check to see what needed to be fixed, but I did not fix it all. Fixing it all would lead to more problems. Instead, I just focused on what could actually cause complications down the line. All the rest, that have no effect on user experience, were left alone.

An example is when I set up a form with an empty action, and assign an event using MooTools. The event then directs an ajax submission when the user submits the form. But, when validating the HTML it comes up as an error that the form does not have an action assigned to it. Who cares? Nobody. It works.

Validating to 100% should only really matter if your site is running completely on HTML, with little to no JavaScript or other languages.

"You can feed web browsers almost any sort of HTML markup or JavaScript code and they'll gamely try to make sense of what you've provided, and render it the best they can."

Having seen web-developers near-enough tear their hair out over cross-browser rendering issues, one finds it difficult to conclude that the above statement is a positive one.

"In comparison, most programming languages are almost cruelly unforgiving."

This is a good thing, and this is the same standard that webpages should adhere to. If this were the case, it would be far easier to implement web browsers that could confidently apply standards-based layouts to pages, and would render cross-browser design issues a thing of the past. Web Developers that dig their heels in the ground and proclaim (about the lax attitude towards mark-up) "It has always been this way; why should we change?" are digging their own.

Coding Horror :D
59 Errors, 63 warning(s)

http://validator.w3.org/check?uri=http%3A%2F%2Fcodinghorror.com&charset=%28detect+automatically%29&doctype=Inline&group=0

Not just 508 but W3C accessibility guidelines, of which Priority 2 is the accepted (although not legal) minimum standard in the UK states that to achieve Priority 2 you must 'Create documents that validate to published formal grammars'.

I like having valid HTML, it helps when the browser rendering engines change so frequently, it's good to know you have a solid and correct foundation to buid from.
And as someone else said it helps with Search Engine Rankings, MSN even more so (although the site I'm basing that on we also did it to pass accessibility guidelines too) I was amazed!

The other thing is if you built a building and it didn't pass building regulations you'd get sued by the client...

Here's the reference for the story I mentioned about an XHTML error causing CodeProject to disappear.

How to Stop Google Indexing Your Site. A Bedtime Story.
By Chris Maunder

http://www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx

target is one of the most annoying things in web pages. I've adopted the habit of opening *all* links in a new tab (middle mouse button) in the background because this way, the experience is consistent.
This way, I know what will happen when I click that link (well except for the hiccup when Adobe Acrobat loads into memory).

If I were the worlds dictator I would force web browser developers to inform their users with a big red sign that the website, they're currently looking at, was not written carefully.

I agree with you - if you see no ACTUAL TANGIBLE benefits using true XHTML (i.e. application/xhtml+xml) then it makes no sense to use it. However, if you like to mash together SVG or MathML with your HTML there is some benefit (though IE doesn't support those technologies and you'll have to use server-side negotiation for fallback to text/html).

Also, I thought there was an official W3C validator for CSS?

"If you see this logo on a site, what does it mean to you?"

It means very little: "slightly less than half of pages using detectable validation icons actually passed validation." (http://dev.opera.com/articles/view/mama-markup-validation-report/ )

There's some relevant discussion of the reasoning behind HTML 5's conformance requirements at http://stackoverflow.com/questions/432933/will-html-5-validation-be-worth-the-candle/446732#446732

Actually, Pandora was never *in* the box. She was the one who opened it. Now, there may have been some who wanted to stuff her in the box afterward but that's another story...

I don't understand much about this stuff, but I think that validating against XHTML means that your website can be parsed by any XML parser, with that in mind there might be some browser and search engines optimizations when you validate as XHTML strict. But even if there are optimizations, that doesn't really matter, why would you want to make the job easier on google servers or in your user browser. People already got dual-cores and google has farms of them...

Not writing valid (x)HTML/CSS, etc. is just a sign of pure laziness.

If you're going to write code, whether it's markup, script or compiled, then you do it right, period. There is no excuse to write code that doesn't validate.

If you can't write markup that validates then you truly don't know or appreciate the markup you're writing.

In a previous blog post (http://www.codinghorror.com/blog/archives/000723.html), commenters discussed the fact that Google's main page has dozens of validation errors. It was mentioned that bandwidth is the issue; when you're trying to serve a very simple page to a significant percentage of the internet's users each day, whether you specify that your style is text/css explicitly or let the browser figure it out starts to matter. Most websites don't serve billions a day, but a lot aspire to do so; if it's good enough for Google, why not for the rest of us?

As far as browser compatibility is concerned, I think it's a pipe dream. The ecosystem of browsers that fail to correctly support standards is already too large; there's insufficient incentive to be standards-compliant when standards-compliant code isn't going to render correctly on a significant percentage of your user base. I much prefer the jQuery philosophy of treating browsers as separate environments and adding the layer of abstraction needed to deal with their individual quirks. It's an extensible model that can adapt to new members of the browser ecosystem, as opposed to wiring down some CSS according to the spec and then praying that all browser authors understood the spec as well as you did.

The web is a jungle. And it's nice to imagine that standards will bring some civilization to that jungle, but I think it's too optimistic to believe they will.

Next you'll be telling us IE6 is ok! :)

It's much more important to test your web site on all the platforms your visitors are likely to use.

Include all relevant web browsers, and maybe the most common screen reader (JAWS). If it works properly on all of those, you're golden.

Since adherence to HTML and XHTML strict rules does not guarantee platform compatibility, you should run these tests anyway. So why not cut out the middle man and just run the tests, and skip the strict? :)

Uh. I am a bit bored with these discussions, but let me say this: "client side" also has lots to learn. It takes some time and effort to find hows and whys.
The fact that browser handle HTML in forgiving manner does not mean that one shouldn't
spend time trying to learn markup.

Yes, that is true, HTML 4.01 strict DTD does noe define target attribute. Frameset DTD does (leaving alone the discussion, is it up to the author to decide how that link should open.)

Regarding width="80" vs. style="width:80"—these both should be absent from markup.
Style attribute is very nice to have in DOM, but it is ugly in markup, even if it is allowed.
And validation _is_ easy, regardless of the doctype. Producing meaningful markup is not so easy.

Does avoiding syntax errors in you C# code matter? Of course it does—your code won't run otherwise. Invaid XHTML proper (served with correct MIME type) will give you yellow screen of death. Invalid HTML most likely will be displayed, but that's a poor excuse.

Typically when I see that button, my first thought is "lets see how much of a lie this is." And about 70% of the time I'm right. :-)

You should at least open and close your html tags and nest them correctly, and have a doctype on your page. If your doctype says html or xhtml is not so important. That's the rules I must say are absolutely necessary. Otherwise I should say you are a careless, sloppy and motherfucking lazy ignorant jerk!
Why is programming code so important to have well-structured but not you're html? Why should not html abide the same strong rules as your server code does?

Jeff, believe in HTML!!!! And love your CSS!!! And don't use inline styles, put a class or a id on it instead.

From a purely practical standpoint, validation does not matter and will never matter. It's kind of like suggesting that we ditch SMTP and implement something totally new to cut down on spam. It's not going to happen.

Validation on the web will never be the norm. It's just too late. That battle was lost (due to natural selection) about 15 years ago.

I do my best to write valid XHTML or HTML Transitional code because It makes javascript and CSS debugging so much easier. I've solved dozens of cross-browser javascript and CSS issues simply by getting the HTML correct. Perhaps if you had valid HTML as a base, you wouldn't have so many complaints about javascript and CSS.

I always make an effort to validate for the reasons given above, when you make a mistake it's easier to find using the validator. w3c also offer a CSS validation tool which is useful for the same reasons. I also feel better about the code if I feel I have managed to code to some standard :)

Browser authors seem to be making moves to be compliant gradually too, IE 8 will be compliant apparently, which will be a massive shock to the system for developers used to messing about to get IE to behave (6 was/is dreadful, 7 not so bad).

With the exception of IE <= 6 I have found that compliant code seems to render more consistently across browsers than non compliant (unless efforts are made specifically to handle particular browsers in said non compliant code).

I've only been a professional web designer for one year and I'm shocked that anyone would find it difficult to comply with strict HTML/XHTML. There are exceptions but it seems to be mostly due to sheer laziness, and betrays a lack of understanding with regard to accessibility (and most often with it comes a failure to grasp separation of content, presentation and behaviour). Aside from that, personally I like to have the assurance that whatever else may be wrong, at least I know that my markup is well-formed.

Overall, I think that:
1. Knowing what "valid" HTML is, is something any web developer should learn, especially if he wants to write CSS and JavaScript
2. Trying to validate as HTML 4.01 Transitional is always a good balance
3. Don't even bother putting the W3C Logo on your page... nobody cares
4. Writing XHTML is nice when the browser is not the only target of your piece of markup

I agree completely with this article. Validating is only a small part of the equation.
The key here is: "Far more important is delivering features that delight your users, or getting the job done. "

Excellent reading!

It isn't hard to validate as xhtml strict if you set out with the intention that it will be valid and check it regularly as you build it.

Writing a site without using a validator (or having any knowledge of the rules) and then trying to make it validate is akin to writing a Java or C++ program in notepad and then compiling it for the first time once you've finished it.

I use the tidy/sgml plugin for Safari and Firefox that gives me a little tick in the corner of my page when my HTML is valid and a cross when it isn't. It was one of the first web development plugins I installed (before Firebug even existed) and is still the one I consider most indispensable.

It is true that making your site valid isn't prerequisite for it to work properly, and it doesn't directly impact the user experience. And sometimes it is neccesary to intentionally make your code invalid to improve the user experience (though target="_blank" was a bad example), but you severely weaken your argument when you admit that you didn't do it because it was too hard! I managed it with my own site - does that mean I'm smarter than you? I can assure you it's not because I enjoy pain, it's just that I didn't find it to be painful.

Deciding that it's okay for your site markup to be invalid is an advanced decision best made by developers who have experience of developing several valid sites and are therefore qualified to make that call. You've built one site that kinda-sorta-almost validates - that doesn't now suddenly make you an expert on the benefits and disadvantages of valid html.

As you correctly state, validating your site makes you a better (more informed) coder, and you know what? Making it 100% valid xhtml will make you an *even* better coder. As someone who clearly considers bettering your own expertise to be worthwhile, I would have thought that would be incentive enough.

To put it another way.
as a user, I couldn't care less if the html is validated or not, as long as the website is working and giving me value in return.

I'm guessing most of the commenters here are programmers, so I get why having your site validate sets your geek pleasure centers tingling, but let's get real here: For most people who author web content, validation is neither simple nor obvious. In fact, I'd argue the fault tolerance of HTML is precisely why the web took off the way it did: it made it easy to anyone to get in on the game. Now you can argue about whether that's actually a good thing, but (to unmangle Jeff's metaphor) the evils are out off the box and they're *not* going back in. XHTML is dead in the water. As TBL put it: "It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work." (http://dig.csail.mit.edu/breadcrumbs/node/166)

As usual most people here are missing the point of the post...

Browsers are already overly forgiving of everything that gets passed into them which is why half TheDailyWTF.com content is about web developers. Validation is a nice idea but unless browsers (all of them) actually rejected invalid content, what is the point?

The problem here is that browser won't reject content or else they lose users, and developers aren't going to validate so long as browsers continue to accept their crap.

Which all leads back to the original question _why_validate_?

Requiring the JavaScript garbage in HTML tags is absolutely stupid.

What if users of your site are running Firefox with the NoScript extension enabled? By default large portions of your markup won't work *at all* until they allow your domain. And you might not have done anything yet to earn their trust to enable JavaScript on your site.

This is a case where the presentation (HTML) conflicts with the code (JavaScript). I don't care if the client renders it or not.

The reasons I validate my website:?

If the validator spits out "This document was successfully checked as XHTML 1.0 Strict!", it just feels good!

It's the same as compiling on Visual Studio using Warning Level 4. Yes, the program will work even if there are tons of warnings, but you simply start to worry anyway (only if you're pessimistic... and usually that's a good thing if you're a developer)

But, you need to do it from the start and you need to check it often. After some point it's simply useless to fix all warnings. Just close your eyes and pray.

Putting the w3c xhtml banner on the page is useless though. Nobody of your visitors care, except you as a responsible developer should.

Exactly as Thomas said. If everyone is out doing their own thing with invalid markup, and it works, browsers will never standardize.

"Why pilot a boat when you could captain a battleship?"

I don't see how someone could disagree with captaining a battleship because that is awesome.

Yeah, just throw some garbage on the page and let browsers forgive you and parse the page anyway. Next year they decide to adhere a standard and won't parse your hacks anymore but why would you care about something you will have to do a year from now?..

XHTML validation from the group up is easy.
Additionally, I don't get why any programmer would prefer an inconsistent model (HTML) over a consistent model (XHTML).

I'll follow standards and validate my web as soon as the new standards are better than the old ones. Not for browsers, but for me. So far, it seems that each new standard is making things harder to do.

I understand the point about migrating existing html code to a standard compliant format, because that really is a waste of time if you follow the "if it ain't broke, don't fix it" mantra... but for new websites, if you design it from the beginning to be validated its not a problem, and it provides the (questionable) advantage of having your markup in a consistent format that complies with standards, allowing you to use many tools without worrying about specific issues.

There is also the (again questionable) advantage that when a tool fails it is actually the tool's fault for not complying with the standard correctly.

I can't say too much from experience though since I learned HTML from the W3C docs and have always written it to pass the XHTML 1.0 validation check and to be compliant with that standard...

What I don't quite get is why a new website would be designed with disregard to the standards... I don't see any advantage myself, just a few (small) disadvantages. I also really disagree with the idea that using XHTML complicates things... I have no idea where that idea comes from, its not like it adds any appreciable functionality absent in HTML 4.01 or vice-versa...

Incidentally the question about whether it matters if you use

<td width="80">
<br/>

versus

<td style="width:80px">
<br>

betrays a particularly poor understanding of mdern web development. You clearly intend it as rhetorical but the answer is actually "yes, it does matter", and here's why:

HTML is not a visual formatting language, it is a language for defining document structure. The inclusion of stylistic tags such as <font> and <b> and attributes such as width/color was a grievous mistake, which has now been rectified by deprecating those elements, and browsers only support them for backwards compatibility.

The correct way to define the appearance of your site is with css styles. Doing this separates presentation from content, and makes your content more re-usable. Of course to really take advantage of that you should move your styles out of the style attribute and into an external css file (which is why the style attribute is also deprecated as of xhtml 1.1).

While we're on the subject, your use of <td> and <br> tags as an example is also quite telling, as these are both quite controversial due to the tendency of bad web developers to abuse them. <br/> adds a line break, which is almost always a presentation rather than content-related decision. The only legitimate use of this that springs to mind is formatting an adress or a poem, where the line break actually has a semantic meaning, but it is more often used for all kinds of things that it shouldn't be, such as adding white space between lines of text or images. I certainly can't imagine why you'd ever want one inside a table cell.

And of course the humble table cell - an element whose intended purpose is to mark up tabulated data, but which for some strange reason is still regularly used for visual formatting by lazy developers who can't be bothered to figure out how to create columns, rows or grids using divs and css (despite the fact that it is actually much easier and more flexible than using a table).

It's hard to explain to software engineers why this stuff matters because they typically don't see html as a data structure. The best analogy I can find is that using a table to mark up a list or format a paragraph is like using a two dimensional array to store the characters in a string - it's the wrong tool for the job because it neither represents the structure of the data, nor offers the optimal method for retrieving and manipulating it.

Certainly the end user doesn't care which you use, but as a programmer it should matter to you that your code is well written, and given the inherently open source nature of the web it should matter even more since your bad code is there for all to see (and judge).

There is <a href="http://www.jslint.com/">JSLint</a> for validating JavaScript by the way :D

I use jslint to validate my JavaScript, and I highly recommend it. I also think html validation is important so that browsers know that they will not break your site when they release a new version.

Alexey,

Future browsers adhering to a standard is incredibly unlikely, and that is precisely why so few people see a need to validate their HTML.

Look again at the list of failing websites. They are in a category that makes up 94% of the content on the world wide web. What market forces will compel Microsoft to make their HTML valid? What about Sourceforge? Slashdot? CNN? The main page of Google?

Re-coding a page costs resources: money and time. If current browsers render the pages correctly, the incentive just isn't there (except to simplify debugging). If a future browser didn't render these pages correctly, then the people who find Microsoft, Slashdot, Sourceforge, or CNN useful in their daily lives wouldn't use that browser. So websites have no incentive to standardize, and browser authors have disincentive to reject non-standard HTML. For the scenario you described to play out, a browser would have to exist that was such a 'killer app' that people felt a need to invest time and effort in supporting that browser.

In fact, Jeff, that might be a fun topic to touch on at Coding Horror. Could there exist a "killer app" for browsers, a technology that couldn't be coded on the web, had to exist in the browser itself, and was so useful that the browser author could compel websites to be compatible with them?

Incidentally, Even if such a scenario occurred, it may not be enough to bring standardization. People would be coding to that browser's interpretation of HTML, not necessarily to the standard. Who's to say our magic 'killer app' implemented the spec correctly with no deviations?

Standards are there to aspire to, but for some reason send developers into frenzied defensive panic. Surely it is better to aspire to perfection, even if it isnt acheived. Sometimes, due to business requirements, it is plain impossible to accommiodate.

I work in QA, I am tired of dealing with shoddily coded web apps, when running pages through simple validators, and observing a few simple standards would avoid a lot of issues.

Well coded pages will pass Transitional, in general, which in my eyes is good enough. There is no standards police to make you adhere to standards, but at least using them as a guide would save us all from the proliferation of shoddy websites by amateur coders who think they know best (i.e. coders who dont want to do much work, to see an end result).

Not every client is a mainstream web browser, and that's when HTML validation does matter. All those non-browser apps will have to struggle to infer the intent of broken HTML to extract information.

"Re-coding a page costs resources: money and time. If current browsers render the pages correctly, the incentive just isn't there (except to simplify debugging)."

That's the problem. Manager's don't care about your markup or your code. Client's don't care either. Even technology, like browser, do not necessarily care.

But you, the guy maintaining the mess, you should care, for the same reasons you should refactor the codebase of a program.

+1 to no target and no javascript opening a new browser window.

I can't say it strongly enough. I *HATE* this.

The javascript is actually worse than the target. If you're used to command-clicking or control-clicking to get a new tab, the javascript says "screw you, I'm doing what I want and not what you want"

I *NEVER* want a new window, now that I have tabs.

Now someone going to come along and say, I should be using browser X instead, it does what I want.

They have no Idea what I want. I choose the browser I'm using for my own reasons. Web developers shouldn't be telling what browser I should use. *THAT* is why there are standards to validate against. If you're following the standards /any/ (compliant) browser should render the page correctly. If it doesn't it's a bug in the browser. If you're coding to a particular browser, you're intentionally putting bugs in your code.

Writing strict xhtml is not hard. You just need to learn about a dozen standard practices that are the most common mistakes. After that it usually takes a few minutes to fix the errors in validation that are more edge case.

If you learned web development the wrong way (like most of us, including me) then yes it's difficult to change, but it's not impossible and you should change for these reasons...

Cross browser compatibility. Generally speaking strict xhtml removes the need for 90% of the browser hacks people use and rely on these days. I write international sites that have to render in Opera, Safari, IE 6+ and FF 2+. My current project has one IE6 specific external style sheet with literally one CSS class override to fix a 1 pixel offset caused by a floating point error in dividing full width by 50%. It's a fully supported non-hack hack that I can live with.

Strict Code-Like Rendering you reference. You'll never reach the strict, code like interpretation of a programming language if you keep making developers support these cross browser incompatibilities because you refuse to see the benefit of strict xhtml code. As long as a majority of people keep writing poor html, browsers will still have to support it because otherwise the business community would scream murder when their sites don't render properly after a browser upgrade. Then we end up with transitional standards creating a third class of difficult-to-clean-up code.

I'm not sure why you don't think CSS isn't validated by the w3c (http://jigsaw.w3.org/css-validator/), or how you believe JavaScript isn't validated when it's parsed by the browser, but they are, and fortunately they're more consistent because I'd rather not mentally parse other peoples lazy preferences when reading their javascript code.

The only "downside" you mention is the lack of a _target attribute, which is not supported because there's a new CSS3 standard for that - it's a css attribute - "target-new: window" on anchor tags. But because the community dug themselves a hole, the adoption has been slow, and delayed. But on a more philisophical approach, unless you're doing a web application with a calendar or prompt popup, don't open a damn new window in ~my~ browser, if I want a new window, I'll hold my ctrl key when I click the link. If I want to leave your site to view another link, I will. And if you're developing a web application, then you're likely using javascript anyway so go ahead and use that to open the window and stop fussing. You're definitely over reacting to a very inisgnificant aspect of strict markup.

The bottom line is write strict code, it will make your life much easier once you learn it, and it will make everyone's life easier when we all do it. Hearing people shy away and fear strict xhtml is like the hearing vb6 developers shy away from .Net. Stop whining, and keep improving those skill sets so you don't end up like a dinosaur.

I view invalid markup a sort of technical debt that can build up and make things extremely hard later on down the road. It may be a good idea to only hit 90% valid on an initial release if it means you are first to market, but the longer you sit on these inaccuracies, the more risk you are taking for later.

Like any other technical debt, it pays to pay it down. When I have gone to 100% valid, it often fixed anomalies that were showing different depending on browser. Also, what is going to happen when people start using IE8 if you haven't paid down this debt?

Wow, Jeff, how DO you get through all these comments!? I'm not going to bother reading any of them, so maybe mine is redundant. Feel free to ignore.

I'm currently playing with my new Kindle and the source formats for creating my own eBooks. They are XML-based, a common thing in our world today, and the content is written in XHTML. I used to be all for the simple seat-of-your-pants HTML style of things until I began using Blogger (all tags must be closed) and also seeing how poorly it translates to lighter-weight, stricter renders like eBook Readers (this isn't to say a CSS/Script-heavy page doesn't fall apart as well). The advantage to me is how quickly write tools to process XHTML whereas HTML is another matter entirely.

While StackOverflow is something of a web application for developer collaboration, it's also a valuable repository of information. And as such, anything you can do to make it more accessible is worthwhile. All that said, I haven't had a problem reading questions even with NoScript enabled and my first blush searches on Google for technical issues are still always suffixed with "site:.stackoverflow.com".

HTML validation doesn't matter. See why using the Perfect Web Search Engine: http://dev.quickfire.org/perfect/

I am really split over this. I validate all my xHTML as strict xHTML. I just like the fact that it is neat and tidy xHTML, and should, render correctly everywhere. Now that last part isn't true because of various reasons, but validating can be useful for other things. Google ranks, finding bugs, etc.

My dad gave me advice too. He said: "If something's worth doing, it's worth doing right. Don't be lazy."

Just as an added reference...
http://stackoverflow.com/questions/7940/how-important-is-w3c-xhtml-css-validation-when-finalizing-work/7951#7951

Just turn on debugging in your browser and watch what happens...

>>So, immediately I began to wonder: Is anybody validating our JavaScript? What about our CSS?

http://jigsaw.w3.org/css-validator/validator?uri=asperous.us

Jeff wrote:
After jumping through the HTML validation hoops ourselves, here's my advice:
1. 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?

I know I am thinking abstractly (about the color of bikeshed so to speak) but wasn't your last post about how the key to getting things done was figuring out which pieces of information to ignore? I am not sure that it changes your main point but telling us that we should validate because more information is always better seems like a weak argument.

You should really educate yourself about the reasons behind these decisions. Asking "... who makes up these rules? And for what reason?" is pretty silly when you have a big fat W3C logo right above that sentence.

The core guiding principle is: separation of concerns. As a programmer, you should understand that principle.

HTML is supposed to encode CONTENT, information, data, whatever you want to call it.

CSS is supposed to encode PRESENTATION

JavaScript (ECMAScript) is supposed to encode BEHAVIOR, interaction

So, to address your examples:

- The target attribute encodes BEHAVIOR (what the browser should do). It should not be in the HTML "layer"

- Width of a table cell only matters in DISPLAY / PRESENTATION (and should be in your CSS stylesheet, not inline style attribute in HTML).

Jeff, great article, but I slightly disagree with you no a couple of points.

First off, there does exist a validator for CSS, and in conjunction with your flavor of HTML validation it really does check that what you're doing exists in the standard. This is especially important for CSS because there are so many proprietary extensions to CSS that are supported in certain (*cough*ie*cough*) browsers, and not supported or poorly supported in others.

What makes this much less useful is that the standard itself is not completely supported in all browsers, Javascript especially. But regarding just the markup, I've found that when I make an effort to produce strict standards compliant code, I end up with far fewer cross-browser compatibility issues.

No, standards validation won't solve all of your site problems. However, it does eliminate the chance for a great deal of them, and better yet can help to point out problems that *aren't your fault*, like issues with a certain browser rendering a CSS attribute for example.

Finally, I disagree on one of your points. My hand-crafted forums system at a couple of my sites validates to the XHTML 4.01 Strict standard just fine, and it has lots of user generated content and a similar parsing system to stackoverflow. Yes, it was partial hell to get it to work that way, but it can certainly be done. I don't think it makes sense to discourage users. After all, if you really feel strongly about treating HTML as code (as mentioned in a previous blog post) don't you think the HTML should follow the same syntax verification as the rest of the code in a site?

so the summary really should be : "standards compliant html/xhtml is hard - lets go shopping!"

@Mark T. Tomczak

Looks iike you don't know much about future web browsers, acid3 test and work done on HTML5.
You ask "What market forces will compel Microsoft to make their HTML valid?" How about this: http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.msn.com%2F ?

"Re-coding a page costs resources: money and time. "—sure it does. That's why it is better to build it right way from the start—and that also minimizes the number of issues you have to deal across different browsers. Proper code most of the time works fine across firefox, opera and safari, some tweaks might be needed for less capable (you know the name).

And the incentive is there—it is to be professional.

At least Stackoverflow.com now renders correctly in Opera (the only compliant browser) thank you!

@Rick Dailey: Your comment makes too much sense - Jeff doesn't care because being reasonable and non-combative doesn't attract the quantity of traffic that Jeff has become accustomed to. Passionate opinions, even if uneducated, misguided or just plain wrong, polarize people and get them riled up. That's good for business.

In actuality, I guess the best result from posts like these is the resulting conversation, and that is what blogs should do - start or participate in a conversation with the readers. I just don't know that this particular "conversation" is useful...

@Rimantas

Thank you for the input, but could you expand on it a bit? I don't quite follow how the fact that www.msn.com validates is a "market force." Are you implying that Microsoft now has a policy to crank out standards-compliant code? That's good for them (and should simplify the lives of some browser developers), but it shifts one company's website out of the 94% bracket and into the 6% bracket; it's hardly a compelling reason for the other 94% to follow suit, not when they're still learning how to do HTML from the "For Dummies" series instead of the w3c standard.

You also mention a critical sticking point with standards adoption: as long as the browser that ships by default on most people's personal computers requires "some tweaks," writing proper code is neither necessary nor sufficient to make my website show up correctly on most people's personal computers. I'm back to per-browser testing, which I would be doing anyway; writing the code to be standards-compliant and THEN still needing to do per-browser testing adds one more thing to my list of things-to-do, a thing that gives questionable gain.

More predictable behavior in dynamic pages is a significant gain. Making my page standards-compliant is definitely going into my debugging toolbox for pages with dynamic content. I'm not convinced it matters as much for pages without dynamic content.

But you should care. Because if you're anyone who writes anything that needs to scrape HTML (screen readers for the visually impaired immediately comes to mind), then having a strict definition of HTML and conforming to it makes it a hell a lot easier to work with.

Compare that with the total mess of "malformed" HTML now. A lot of sites are simply unworkable with screen readers.

Hmm...

-- 8< --
Errors found while checking this document as HTML 4.01 Transitional!Result: 66 Errors, 87 warning(s)

[...]
Line 12, Column 126: document type does not allow element "LINK" here.
&#8230;rastination and the Bikeshed Effect" />

... One common cause for this error is the use of XHTML syntax in HTML documents.
-- 8< --

Jeff, if you don't want to do XHTML, then why you're even trying it?

Validation is definitely the way forward.

Validated HTML (plus validated CSS) doesn't guarantee that your page will render properly in all browsers. That much is obvious.

But conversely, you can't really complain about that pesky inconsistent renderings if you are feeding the browser invalid markup and just leaving it to guess what you actually meant (GIGO).

“Look again at the list of failing websites. They are in a category that makes up 94% of the content on the world wide web. What market forces will compel Microsoft to make their HTML valid? What about Sourceforge? Slashdot? CNN? The main page of Google?”

I’m no expert, but this seems like a rather complacent argument for not writing valid code. In order for a browser to render the 94% correctly it only needs to have workarounds for the mistakes in those websites. And how much effort would it take for these big sites to correct their pages? I suspect it wouldn’t be too difficult as they are mostly generated code. So if say in a years time most of the sites had improved to the point where a mostly conforming browser rendered them fine, do you think manufacturers will put a lot of effort in maintaining all there workarounds to support the percentage of the remaining 6% of the WWW with invalid code.

In any event, if it is as easy to write valid as invalid code, why take the risk?

I'm sad to see nor many people bringing up accessibility as a good reason to try to keep 'close' to validation.

validating isn't really needed, it's meaningful markup and a good separation of content and presentation that helps from my understanding.

A little note about accessibility, a salesman who works for our company has a total color blindness, thus if our software were to rely solely on color to help run the UI, he would automatically have a handicap with using his computer. While total color blindness is rare, should we account for it at all?

The same statement can be changed, if we're still supporting IE6, even though it's getting a lot more rare, should we account for it at all?

Screen readers arn't common either, should we account for them? Does valid xhtml really help them parse the data on screen? Do screen readers ignore 'style', 'id' and 'name' attributes?

http://www.freedomscientific.com/jaws-hq.asp - something tells me, by looking at their markup, that JAWs might actually work just fine with the majority of sites and not be partial to xhtml, unless of course they don't follow their own guidelines.

Tricky situation, it isn't about validation, validation doesn't matter so much as accessibility in my eyes, but everyone should do user testing, right?

You brought up CSS validation... are you aware of the W3C's CSS validator?

http://jigsaw.w3.org/css-validator/

Also -- in terms of JavaScript -- what about JSLint?

http://www.jslint.com/

Jeff, if I were a woman, I would have your babies.

I'm using HTML 4 with plenty of errors. I have always felt this way about using validating & when my coworkers treat it as the be-all end-all, it really is taking away from what we're trying to do...hopefully having people visit & use our website.

Your word is gospel to me (most of the time at least).

> Does it really matter if we render stuff this way..

> <td width="80">
> <br/>
> .. versus this way?

> <td style="width:80px">
> <br>
> I mean, who makes up these rules? And for what reason?

Actually, the width attribute in tables has been deprecated, and has been for years. The correct way to do this is to use CSS -- either embedded into the HTML or (preferably) as a separate page. Sooner or later, that width attribute will disappear.

Originally, HTML was a means to helping you understand the context of the document. If you were indexing the document, <h1> through <h6> tags could mark subject headings while <ul> and <li> would mark out lists, etc.

The problem started with Netscape's <center> tag. Center doesn't tell you anything about the context of the page. It's a formatting direction. Originally, formatting was really left up to the browser, but now Netscape was taking that right away from the user.

Soon, formatting tags proliferated, and we started getting the "This page is best scene with..." lines all over the place.

HTML 4.0 was a move away from formatting codes embedded in HTML, and allowing HTML once again to render context and not formatting. The result is that the webpage is free of formatting and contains more content. Content in HTML can be arranged, so that main content is on the top of the HTML file even if it isn't actually displayed there.

XHTML is merely the next step. Browsers render a page at a time, and aren't the real target of XHTML. Browsers will always render sloppily coded pages and always be rather forgiving. Instead XHTML is aimed at the massive indexers that someone might use to figure out what information is actually on their page.

While a browser doesn't have to figure out what is on the page it is rendering, the indexer does, so any coding error in the XHTML might make the page impossible to index. Google's indexer does its best to figure out the content of a page, but it does its job so much better when XHTML is used, and styling is saved in a style sheet.

I've seen this myself with my own pages. Fixing XHTML glitches didn't necessarily earned me a higher page rank, but it did help put my pages into the correct search results.

I've read through most, if not all, the comments and I don't think anyone has commented on the business side of this argument.

Say you have a moderately sized site and you need to allot labor hours to this project. Let's say you get a very good scripter/coder/hacker to review the entire's site code in 20 hours at a rate of $100/hour (some make more, some make less). Is it worth $2,000 to the business owner to have a validation review completed? What about the opportunity costs associated to using the manpower? Now, let's combine this with Jeff's recent technical debt article and even with overall lower costs, is it worth it now? The answer is probably still no.

The discussion is not as clear cut as "of course you should write valid markup" when you have to justify the costs of doing so especially if you're dealing with an already existing non-validating codebase.

I try to make my html valid because i think its fun!

Harvey Dent sums it up quite nicely: "You thought we could be decent men, in an indecent time! You were wrong."

There is a good reason for producing validated HTML:

If something does not display the way it should, and your HTML and CSS (there also is a CSS validator on W3C.org BTW!), then you can go to the browser vendor and say "You suck! My page is totally valid, your browser screws it up... please go and fix it!"

However if they test your page and it has hundreds of validation errors, they will not care for your bug report. They will say "First go and fix your page, maybe it WILL display correctly once you did that and *THEN* we can talk about our browser".

Using valid markup makes sure your bug reports are taken seriously and they make sure browser bugs are found and fixed and this is something everyone profits of, as the more correct browsers work, the more webmasters can rely on correct working browsers, the less special browser hacks they must use, the better their page will render on any browser the user wants to use - the better the web experience for everyone.

I agree with Eddie on the FxCop analogy. That "lint checker" allows you to customize the rules for your business or particular application, persist those changes in a project, and even suppress particular violations (with text justifications) in a persistent manner. This keeps the noise down if done regularly.

Similar agrument goes for correct spelling. Who cares if you get it "right" according to some arbitrary authority's judgement, as long as people understand you?

That's a crappy argument, if a tempting one.

Engligh spelling is meaningful. Aside from being wary of dislexic traps such as "anti" and "ante", words have roots in multiple languages and in order to spell words correctly, especially unfamiliar ones, you need to understand what the components of language MEAN.

"It doesn't matter how I spell/punctuate/validate as long as people/browsers understand me?" Ah, but do you really understand YOURSELF?

Where the hell is Catto when you need him? I scrolled through the whole darn thread, not a single "Hey Now Jeff" anywhere.

Writing valid xhtml strict IS NOT HARD WHEN YOU KNOW THE RULES. If you happen to know the rules, you should do it. If you don't know the rules, do whatever you want. Amazingly, the rules are quite easy to learn: write your markup in xhtml, validate it, and fix problems.

Let's say the site you are building hinges on faulty (x)html. There is no guarantee that markup written against the spec will act as expected in every browser, present and future. Work with the spec, and you know exactly what will happen. It's that simple.

Granted, you probably won't run into many cases where this will affect you, but if you do it could drive you insane. And it is quite dumb that target is invalid.

I love it when people proudly attach those valid html logos to their sites. About 80% of the time I click them, the validator produces a bunch of errors. I guess they were valid before a bunch of changes though :p

I love the argument about Screen Readers - "Write better html code to let Screen Readers programmers write crappy Screen Readers". html is standart for all browsers, why write Screen Readers that does not know html?

I know its cool to write good html, i even write html with right formatting, but it just for fun. I remember that at collage i was tought to write xml pages than transform them with xslt. why nobody is doing this? its more fun.

I love debates like this, its almost like tables vs css pseudo-tables. everybody would like to push as many standards as possible. its ok if they make sense, but with html validation nobody cares. if you are bored go for it.

I'm surprised no one has mentioned the one self-interested reason to write valid markup. Maybe I'm behind the times here (not much of a jQuery coder), but don't browsers go into "quirks mode" if your markup doesn't match your DTD?

Granted, whatever the opposite of "quirks mode" is, it's not W3C-clean perfection. Most (all?) browsers still break the spec even when they say they're in standards mode. But in my experience getting the browser out of quirks mode can really help with some of those CSS layout problems that can get you banging your head against the screen.

@ehhh: "I love debates like this, its almost like tables vs css pseudo-tables"

Have you ever tried to make a "minor" change to someone else's table-driven layout?

This reminds me of the the broken window syndrome.

I suspect that such a neglect doesn't resonate very well with programmers for obvious reasons, while it might be different for others, who doesn't understand the importance of protocol standards - or standards in general, because it doesn't affect them in the same way. If it looks the same as before, why bother fixing it, right? We know better; we should know better.

http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy

http://en.wikipedia.org/wiki/Fixing_Broken_Windows

I absolutely can't stand target=_blank so I have a hacked up version of the "blank must die" greasemonkey script that gets rid of them.

target=_blank is right up there with changing visited links to be the same color as unvisited links. It's like these self styled "web designers" trying to make browsing as difficult as possible.

Firefox DOES support custom DOCTYPEs. It's just that it only supports them in XML or XHTML (and not just XHTML served at text/html).

Thats right Jeff. Nobody should bother writing markup that can be read by screen readers and braille screens. It's just too difficult to do and time consuming and won't make a difference. All those disabled people don't use the internet anyway. Especially not programming websites. And nobody uses reduced functionality browsers on their mobile devices. And nobody cares about their google ranking. And nobody needs a standard way of parsing web pages. Most people will see the web sort of the way it was intended anyway. We shouldn't have to cater to a minority who are different from us. It's too much hard work to do things the right way. Fuck everyone else, I'm OK. Standards are for other people to adhere to.

XHTML validation is all the more difficult that the W3C validators are broken: they don't understand perfectly valid custom namespaces.

I have to admit that I read almost every Coding horror post, I listen to each podcast of the Stackoverflow podcast and yet I almost always disagree with you. (Weird, sorry) .. This time, however...

I COULD NOT AGREE MORE!

Thanks a lot Jeff! Excellent post. I'm glad someone said it ;-)

As a web user, it doesn't matter to me if it doesn't validate. I wouldn't know unless I go through the trouble of passing it through a validator. Why would I spend time doing this.
What matters is the site should be functional and easy to use. like stackoverflow. I don't care if SO has 200 errors.

However it probably matters to people with non GUI browsers...

Jeff, what has always intrigued me is that programmers are able to create valid RSS and ATOM feeds for their websites, but come up with every reason under the sun why they can't create valid XHTML for their websites.

XHTML is just XML with a couple extra rules about what elements can go inside what other elements and what attributes are allowed - as you've noted above. No biggie. Coding Horror's RSS Feed validates. StackOverflow's RSS feed validates. CNN's feed, etc. etc. etc. What's the problem? My thoughts:

http://iamacamera.org/default.aspx?section=develop&id=73

Brilliant!

Your problem is that... you're doing it wrong.

First - target="..." is BAD! If I want it in a new window, I'll do it myself. Don't try to force anything on me, thankyouverymuch.

Second - You're writing a html page. Why don't you write it correctly from the start?
Comparing to programming - do you write the whole program and then add patches until it kind-of works, multiple bugs cancel each other out and memory leaks aren't critical? Or do you write small parts and test them so that the whole program is correct?
You don't have to cleanup the mess if you don't make it in the first place.

Jeff, since you are the self-proclaimed ShamWow (attributed) guy of Coding Correctness, it must sting to see "FAIL" next to that validator report.

Now you have to re-python the whole thing or the Scrummy world will implode.

I may not be the most precocious web developer out there, but I really found the process of converting my own CMS (if you can call it that) to output strict XHTML & valid CSS2 pretty satisfying. The real pain in the neck for me is filtering the output of the RSS feeds aggregated on my site so that they, too, are XHTML-strict.

Making your site XHTML-strict is good for you. Think of it like... flossing.

It is not too much to ask that all browser render valid html the same way: according to spec.
But it is too much to ask that all browsers make the same guess how you want your invalid html to be interpreted.

Only when we write valid html can we expect html to be cross-browser compatible.

I am amazed that those who are so opposed to the target attribute have not found the simple solution:

Keep the tag in the spec, but let the user agent ignore it if that is what the user wants.

That way, people could live in the dark ages if they want, but those of us who understand tabs and windows can benefit from a web author's suggestion that those features would be useful when following a particular link.

The problem with the standards is that they keep changing.

So any attempt to standardize right now may be wasted effort when whatever is done is then undone.

I understand that is the idea of versioning, but to spend 2000 manhours standardizing your HTML only to find out it's no longer the "latest-and-greatest" when that was your selling point for the project might cause you to lose your job.

Not a wise risk to take.

Of course, for those of you who work for a company where you can waste 2000 hours for no reason, have fun!

I would add that following standards on new content is a good idea. But for refactoring old: You have to consider the cost/benefit ratio and make an informed decision.

That goes for all of these QA points. Seriously. The solution is not "ALWAYS refactor" nor is it "NEVER refactor." (replace "refactor" with "standardize" for this specific blog post) The solution is to do so when the benefit outweighs the cost, abstain when the benefit is less than the cost, or when analyzing the cost is more expensive than the benefit.

@Practicality - the latest and greatest standards are ten years old, plenty of time to learn them properly so that one does not need to spend 2000 hours making something valid.
Making code validate is VERY easy. The important thing is to remember, that valid tag soup is still a tag soup.

"if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window."

I think that's true in general, but <a href="http://validator.w3.org/check?uri=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFixing_Broken_Windows&charset=%28detect+automatically%29&doctype=Inline&group=0">Wikipedia validates</a>, and it's <em>all</em> user generated content. (Not necessarily a counter point, but it's interesting.)

I've been working on a specialized <a href="http://simple.wikipedia.org/wiki/Main_Page">simple wikipedia</a> editor; and Wikipedia's use of XHTML over HTML makes it more straightforward to pull information, like edit-tokens, out of their webpages. So I think XHTML has it's advantages for letting people build things that interface with your webpage in ways you wouldn't expect.

"if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window."

I think that's true in general, but Wikipedia validates ( http://validator.w3.org/check?uri=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FFixing_Broken_Windows&charset=%28detect+automatically%29&doctype=Inline&group=0 ), and it's *all* user generated content. (Not necessarily a counter point, but it's interesting.)

I've been working on a specialized editor for http://simple.wikipedia.org/ ; and Wikipedia's use of XHTML over HTML makes it more straightforward to pull information, like edit-tokens, out of their webpages. So I think XHTML has it's advantages for letting people build things that interface with your webpage in ways you wouldn't expect.

Brilliant! ( posting THIS article immediately after "BikeShedding" :)

"BUT why not make things better? I'll wager that if browsers only displayed valid (X)HTML everyone would create valid (X)HTML. So I'm soooo glad XHTML Strict are really anal about validation!"

This is technically accurate, in that obviously, "everyone" would only consist of those people who could still write web-pages. So it'd be a smaller "everyone" by a factor of hundreds of thousands.
However, it misses the point that the web would be limited to providing for the kind of people who obsess over XHTML. The "true power of the web" would still be slowly rendering Captain Janeway pr0n, and arguing over whether "bang" is a silly word to use for the "!" character.

"target, a perfectly harmless attribute for links that you want to open in a different browser tab/window"

Ahem. As the user, I am the one should dictate where the links open. If I want it to open in a new window, then it shall. You need to ditch the target attribute. Now.

If you want Strict - then stick with strict, and don't use a target attribute on your link.

If you want target, use the Frameset DTD. HTML 4 has 3 fully legitimate DTDs you can pick-and-choose from, and just like your favourite fundie, whatever you pick-and-choose is the right one.

Why did you pick Strict for Stackoverflow anyway?

-------
* The HTML 4.01 Strict DTD includes all elements and attributes that have not been deprecated or do not appear in frameset documents. For documents that use this DTD, use this document type declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

* The HTML 4.01 Transitional DTD includes everything in the strict DTD plus deprecated elements and attributes (most of which concern visual presentation). For documents that use this DTD, use this document type declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

* The HTML 4.01 Frameset DTD includes everything in the transitional DTD plus frames as well. For documents that use this DTD, use this document type declaration:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">
-------

You should always leave 1 mistake in your HTML to retain your humility.

I have to say that HTML validation (especially using the 4.01 Transitional) is not difficult to attain. Pages that don't validate are either due to a misunderstanding of the basics of HTML, either to pure laziness.

Let's take for example out beloved codinghorror.com:

6x "document type does not allow element "LINK" here" : That comes from a misunderstanding of the way HTML works. Tags such as link and a handful others (br, area, link, img, param, hr, input, col, base, meta) don't need to be closed. Actually it is wrong to explicitly close them because they are implicitly closed, closing them manually would be like closing them twice.

12x+ "end tag for element "INPUT" which is not open": Same error as above: misunderstanding of the basics of HTML

1x: "end tag for element "TD" which is not open": Laziness... There is no table anywhere close to that TD...

and 30 more warnings about not encoding & to &amp; in urls as it should be. : Misunderstanding of HTML basics. & is not a regular character in HTML, it is used to reference entities that are declared in the DTDs that apply to the current document in the form &entityName; The HTML 4.01 Transitional declares a crapload of entities. Entities are NOT limited to the ones declared in the HTML 4.01 DTD as you could supposedly attach more DTDs to your document.

Hence using '&' verbatim in your HTML is similar to using an unescaped " in your C#/Java/whatever source code, you should escape it with &amp; .

Seriously, how can we even expect browsers to be somewhat standard compliant if we keep feeding them that kind of crap.

Oh boy Jeff... Please don't spread this kind of amateur misinformation.

"That's right, target, a perfectly harmless attribute for links that you want to open in a different browser tab/window, is somehow verboten in HTML 4.01 strict"

_target is a usability issue. Nothing annoys me more than clicking a link and having it open in a new window without my approval. All links should open in the active window unless one explicitly says otherwise (eg. by middle clicking). The workarounds are kludges because you shouldn't use them! What's the point of technically conforming to the spec if you are only going to insert the same violations through a backdoor such as Javascript so they aren't detected by the validator! Pointless. Might as well not validate in the first place, if you don't believe in the W3C's take on these matters.

"Does it really matter if we render stuff this way... ...versus this way?"

Jeff, the two examples you gave are both bad. We're talking separation of concerns here. The second one with the style attribute properties should have been pulled out to a CSS document. How can you not know this, given that you've already made the somewhat flawed analogy between html and css as the model-view-controller architecture? Presentation data goes in a stylesheet, while the information goes in the HTML document.

Got halfway through the page when I gave up on reading all of the comments, but (for the first time ever) I feel compelled to say I also think you forgot something very important in your article:

Yes, it's true that most browsers render almost any website - whether they're good or badly coded - but not all browser render bad code in the same way. How can you make a cross-browser website that way?

I personally spent many, many hours on trying to get websites to look the same on any (major) browser. When you (and browsers) don't commit to a standard (be it HTML or XHTML of any version), how can one then create a website that anyone can see in the same way - namely, like you wanted them (your visitors) to see it?

> So, immediately I began to wonder: Is anybody validating
> our JavaScript? What about our CSS?

Well, the JS interpreter "validates" JS. There's also JSLint (http://jslint.com/) which performs a stricter form of validation.

Regarding CSS, the W3C have a validator http://jigsaw.w3.org/css-validator/

Personally, I believe it is worth the effort to write HTML which validates as being at least XHTML transitional. This guarantees that the code is valid XML, which means I can use it with XQuery, XPath, XSLT, etc.

Although I frequently attack standardistas who fixate on minutiae of HTML and CSS, while effectively ignoring software engineering, scalability, design, usability, business workflows, marketing, expedience, and all the other factors that weigh in on real websites, this post is just plain irresponsible.

Web standards exist to reign in the MADNESS that us long-time web people lived through 10 years ago. The amount of lost productivity could only be measured in the billions. Thankfully, due to the standards movement, it's now possible to write flip articles like this. But be careful not throw the baby out with the bath water. Standards are what bring us to a world of less browser testing, greater accessibility, and ultimately greater productivity. A general vote against validation is a vote for increasing the number of development headaches we'll face in the years to come.

Looks like I got to the party late. OH well, here goes anyway...

To all you people, maybe even the author, saying, Who Cares?, remember to bring this attitude up when interviewing. I damn sure wouldn't want you working for my company. You are all the type that wrote those crappy, spaghetti-code VB apps aren't you?

Back in the day, visual tools could have helped Mom and Pop write valid HTML. Today? I know of no one, outside of web developers, who writes HTML any more. They use blogs, Facebook, etc.

Shitty markup is dead and lazy morons that still produce it should be fired and sent back to the McJobs they are qualified for.

Wow, a lot of soap boxes out there...

In the theoretical world, yes, there are standards. However, in the practical world, if the standards are not enforced then there are no standards. I find I'm more productive if I live in the practical world and not the theoretical world - and no, I'm not lazy, just efficient.

Jeff, keep up the good work.

Know the rules, then break them if you have a good reason to. It's as simple as that.

Validation is pretty much at the very, very, very, bottom of priorities in any site I make. And even if by some miracle I ever actually got to this proverbial bottom, I wouldn't do it just because I think it's such a waste of time.

I agree with this post on the level that it is a pain to validate and the rules seem arbitrary, but I don't agree that it doesn't matter. For persons with Low vision/blindness who use text only browsers or screen readers, it is very important to have valid markup.

I look at valid XHTML the same way I look at XML. Well formed, valid markup is only a problem if you don't think about it until the end. Start from the beginning with valid markup as the goal, and you're fine.

>Validation is pretty much at the very, very, very, bottom of priorities in any site I make. And even if by some miracle I ever actually got to this proverbial bottom, I wouldn't do it just because I think it's such a waste of time.

Boy, I imagine the quality of the code that you write is just superlative. Do you just vomit it out, and so long as it (sometimes) runs to the intended effect, ay okay?

Making correct rendered output is no different than ensuring your solution doesn't compile with thousands of warnings because of ignorant or sloppy coding practice. In the end you end up with something that is tremendously more maintainable.

Making valid HTML *from the outset* is trivial, and it's only when hacks do their worst and someone else inherits it that it becomes much more of a toss-up if it's worthwhile going back and fixing up their monstrosity.

And while Jeff mentioned the limited benefits of making StackOverflow validate, the reality is that the errors in it weren't minor little errors, they were *egregious* errors. Getting to a clean state offers them the ability to go forward and immediately catch and eliminate those errors quickly and easily, instead of being Yet Another Hack pontificating about how much of a waste of time it is.

Does it matter? To end users, probably not (unless they're blind or aren't using the majority browser, but who cares about those people anyways right?), however it absolutely speaks volumes about the care and concern put into the product by the developers.

> the reality is that the errors in it weren't minor little errors, they were *egregious* errors

I don't think egregious is the right word for..

<br> versus <br/>
<input> versus <input/>
<img> versus <img/>

etc, etc, ad nauseam. The validation was marginally useful, because we did have a few extra close tags hanging around in a few pages and it helped us find those. But as I said in the post, for us it was largely a six hour exercise in to-may-to versus to-mah-to.

Overall I liked @filini's list, posted earlier on in the thread:

--
1. Knowing what "valid" HTML is, is something any web developer should learn, especially if he wants to write CSS and JavaScript
2. Trying to validate as HTML 4.01 Transitional is always a good balance
3. Don't even bother putting the W3C Logo on your page... nobody cares
4. Writing XHTML is nice when the browser is not the only target of your piece of markup
--

When it comes to #4, I'd argue you really want an *API*, not a brain damaged "wow, we can scrape your site as XML!" mentality.

While I'm building the templates for a site I'm working on, I'm regularly passing them through a html validator and the css through a validator also. Part of the reason, I admit, is to learn where I'm being clumbsy - especially with the css. Doubling up on work, overwriting previous rules etc etc.

I know it means absolutely nothing to the end users if I have completely valid html and css. But if I can get it right now, why wouldn't I for a couple of extra minutes work?

Saying that, I probably wouldn't go back and validate a site already complete and in production. Too much work for little benefit.

Personally, I can't wait for HTML 5 to be widely supported -- it actually supports semantic elements that are useful for document markup. XHTML -- trying to squeeze document markup into a data container model -- was a mistake from day one. I understand the sentiment behind it, that being that forcing well-formedness (which XML demands) would clean up the worst of the mess. But XML is the wrong model for document markup. For instance, there is no particular reason why a browser (or other user agent) should render sibling paragraphs, headings, line breaks, rules or logical divisions in any particular order -- they are just data buckets, and as long as the hierarchy is maintained the data set is identical regardless of the order. Documents don't work that way.

HTML is not a "poor cousin" of XML, it is a different language with a different aim, and the only thing they have in common is the superficial similarity of angle brackets to mark elements, attributes and data -- and that came from SGML. XML is the odd duck in the flock, and the one thing it cannot do properly is document markup.

> Boy, I imagine the quality of the code that you write is just superlative. Do you just vomit it out, and so long as it (sometimes) runs to the intended effect, ay okay?

Ah, that's nice. If it's not valid, then no care was put into it and it is "vomit" - Your argument is so insipid I feel like just writing this reply is a huge waste of my time. Suffice it to say, however, that just because I don't subscribe to the idea of having my mark up validated by a predetermined set of rules does not mean my HTML is not semantically relevant, well formed, and consistent across browsers. That is all.

Thank you so vary much, you have no idea how much this helped me.

Owen Briggs had an interesting point of view on this, a while back.

"This is an attempt to make a code that can go decades and centuries, getting broader in scope without ever shutting out it's early versions. Because that's what we need the code to do: this code is for recording what we think. There are no paper backups of the web. Every day we put more on it that we're not putting in our traditional medias. If we don't use extensible code, then our current history evaporates with the next minor tech change. We've never had this problem before. Before a mark on a page could go centuries; there'd always be daylight to read it by. This is a new problem and it required a new solution. ... We have to validate because that's the only way to know our code won't fail as the syntax develops."

>> http://thenoodleincident.com/tutorials/box_lesson/validation.html

I tend to agree. Plus, if you have the right mindset and are willing to think about what you're doing; its not even really that hard to write valid code that does what you want.

If you're using firefox, the following add-on is a real boon if you are doing the HTML validation exercise.

https://addons.mozilla.org/en-US/firefox/addon/249

I just wish they had something similar for CSS!

One good reason for implementing your website in XHTML:

It means your content is in XML. Hence it's manipulable with XML tools, can be generated with XML tools and packages, can be run through XML transforms to present it in new formats or organize it differently, and so on.

If you're not hand-coding your site, and you're generating the content via code - and I hope most of the readers are programmers - then it's at least worth considering.

A better and more in-depth explanation from the Deki-Wiki folks at MindTouch, here: http://www.mindtouch.com/blog/2009/02/23/is-that-xml-in-your-wiki/

Using divs and CSS to manage site layout is what matters.

"I couldn't help feeling that validating as HTML 4.01 strict, at least in our case, was a giant exercise in to-may-to versus to-mah-to, punctuated by aggravating changes that we were forced to make for no practical benefit. "
Indeed, I think a good compromise is to validate as HTML 4.01 Transitional.

or you could use a view engine that outputs xhtml like
http://code.google.com/p/nhaml/

The reason why coding "correct" html is such an important issue, is because it's a standard. As a software engineer you should be aware of the importance of standards. It minimizes ambiguity

The fact that browser cover for our mistakes is besides the point.

Nice blog.......I'm glad you have brought attention to this issue...

Jeff did a reddit engineer quickly fixup the site or did you make a mistake first time around, I think that was fast.

Of course everbody could use his own language, and ignore conventions. But it complicates understanding each other. Errors aren't errors when there are no rules, it's anarchy - and anarchy is seldom useful.
I'm a good example: i'm not a native englisch-speaker, and that makes it catchier to understand me in that language. Same goes for HTML and Browsers.

I prefer to stick to a standard, so i could proof it automatically with tools. I'll spider my sites periodically and get a report, and when a page does not conform to a standard, i'll get a message. In most cases it is an error, which could harm the layout on some browsers, in rare cases severe disfunctions results.
With wespiva (http://www.wissing.com/wespiva) all the xhtml-sites under my liability were spidered from time to time, with no effort, and errors are reported and corrected.

I find life is this way much easier, better i find the errors before the customers do.

It is not very professional to live with errors and accept them, only hobbyist may do so. It is easy to avoid these html-mistakes, i'll see no important reason not to follow some standards. It makes life with a group of developers much easier. If every member would follow his own "standard", chaos is programmed.

What I don't get is first building a site and then validating it...

When writing the (X)HTML, try to write it valid from the start.

Web pages are not "software." By definition they are documents.

Excessive script and CSS is an attempt by secretaries to pad their parts. This breaks presentation more than faulty HTML anyway. HTML documents are supposed to use flow-based rendering.

Trying to make a silk purse of a sow's ear is ridiculous anyway.

A lot of people on here are saying the battle for validation can't be won.

One thing I've certainly noticed in my experience is that older developers are the ones that tend to not care about validation and younger ones, brought up on CSS floats, XHTML and jQuery, make valid sites without seeing it as a chore as it's the only way they know how.

Not that older developers aren't good at their jobs, but as the first generation web developers retire there will be a lot of developers left over who don't need convincing.

I find that if you validate your markup as you go you are prone to much less errors.

A good validation tool allows you to find structural flaws otherwise difficult to see.

And, in my expericence, CSS & JS behave much better with valid markup than otherwise.

>Ah, that's nice. If it's not valid, then no care was put into it and it is "vomit" - Your argument is so insipid I feel like just writing this reply is a huge waste of my time.

Then why did you lower yourself to reply? Ultimately you know your lazy, hackish rhetoric is a scarlet letter that you have no business in this profession.

What your reply ultimately screamed out was "I am a hack, and Jeff just validated my hackishness so I feel that I am among friends. Let it all out!" Jeff, as I think many unfavourably learned, is the king of the hacks (pretty much every one of his entries over the past year has been variations of "correctness is for chumps! Just hack it baby!"), so he has grown a larger and larger fanbase of code terrorists.

The interesting thing to do is to use Validation as a tool and not as a goal. Why my code is invalid? What is the source of errors? Which script, libraries, etc create invalid code?

So basically for me it helps me to create a better framework or script at the source. I don't want to validate every pages, but I want to be sure that the page which are produced are valid. That means I have to create "checking steps" in my code, or to use the appropriate tools. For example using an xml library to replace an element by another more than doing a regex, checking and sanitize the input of forms, etc. etc.

Here's a thought. If everyone used valid html there would be no monopoly by MS on the web browser space...

Think about it this way, designers spend their lives ensuring that the produce websites that render correctly in the "majority" of browsers. So it becomes a self-fulfilling prophecy that the most popular browsers stay the the most popular browsers.

I can't bring out a new browser tomorrow that will knock the socks off IE, Firefox, Safari or Opera because for anyone to use my browser it has to render all their favourite sites well, which as it turns out were designed to "just work" on the common browsers rather than be valid.

So I have to replicate the rubbish that already clouds the big name browsers just to get a seat at the table. Rather than simply producing a browser that displays valid content correctly.

Think or all the extra processing power and resources that our browsers consume so they are able to account for the numerous invalid commonalities that may exist out there.

In my opinion, the onus is on the designers to produce valid markup, and then encourage their users to use a browser that respects and correclt displays that valid markup.

Oh glory be the day when content providers have the balls to say, "Sorry this site might not work on your browser because... well... it rubbish. We design according to accepted standards which are respected by these browsers..."

Pigs may fly...

Yeah, old developers (40+) like frames, font face tags, tables and don't understand or care about css. And the javascript they write is inline, at best a click attribute on a link or button, which I think is ok, but not the best alternative (better = mybtn.click = function() { ... }).
And those developers who can only concentrate on server code, and have designers who make their markup I think have good days, so comfortable life compared to someone who works in a smaller firm who has to do everything by himself. It's a lot harder trying to be an expert in a lot of topics than just one.

Yeah, validation is not a priority. But speaking of web pages, there is absolutely no difference for me between the red and green you choose for PASS/FAIL. (Needed source code to "see" the colors).

I'm really surprised no one has mentioned anything about performance. I tend to agree with most of Jeff's comments. I really didn't care much about validation until I looked at browser rendering performance. HTML 4.0, XHTML, Strict, Transitional or whatever, as long as it validates you will see much better performance with browser rendering. That is the difference the end user will be able to notice not whether you use <br> or <br />.

This post could only have been written by an ASP.NET developer.

Hey now, Jeff..

Looks like you need to be sent back to school since you seem to have missed the whole point of MVC, Separation of Concerns etc.

As for your examples, both are incorrect (both in concept and syntax).

(X)HTML is meant to give structure to the document.
CSS is meant to give the document a presentation.

The two should not mix.

> Ultimately you know your lazy, hackish rhetoric is a scarlet letter that you have no business in this profession.

Alright. I'll make sure I'll forward your ultimate judgment to the folks over at Digg, Yahoo, Microsoft, Google, Flickr and just about every other site in the Internet. I'll let them all know that although their websites are popular, functional, and well made, Dennis Forbes decided that they were were made by lazy programmers with no business in this profession, so they're going to have to start hiring. *rolleyes*

I'm disappointed in you Jeff. I'm pretty confident that most of what I feel the need to say has already been said above, so I'll only touch on a few things. At the company where I work, upper management puts great emphasis on being able to prove things. Prove that the bill of materials is correct. Prove that we have our costs under control. Prove how long it takes to manufacture a product.

If one of your web pages doesn't render properly, validation helps to prove that you wrote your code correctly. Sure your code "compiles", but there's warnings. I validate all my code to XHTML 1.1, even though my doctype is 1.0 Strict with RDFa support. (RDFa is not why I started using XHTML, but it's an added bonus for me. I switched to XHTML mainly because it forces you to write cleaner and more consistent HTML. It's more "strongly-typed".)

And like Andy said, as an MVC person you should appreciate keeping things separated.

What, I have to use alt in images? Why I can't use the title tag, which works in all browsers while alt doesn't work on Firefox? Why can't I use align in images? How am I supposed to center an image then?

Screw it, I'm gonna use Transitional.

Speaking as a freelance web developer, I strive to maintain (X)HTML standards in all of my work. I primarily use XHTML 1.0 Strict. I also do my best to use semantic markup. Within these limits, structure (the XHTML) is separated from presentation (the CSS). When you have valid semantic structure in your code, the presentation can be changed in a wide variety of ways simply by changing the CSS. (See csszengarden.com for many examples.)

As Scott mentioned above, I'm also using RDFa in some situations.

What's one of the best reasons to use valid code? Because it's never finished. You'll be back to work on it again later (or someone else will) and you'll thank yourself for having written code that's easy to understand.

The Browser Security Handbook paints a detailed picture of how laxness -- particular inconsistent interpretations -- leads to potential security flaws in all web browsers:

http://code.google.com/p/browsersec/wiki/Main

Good reading: http://www.cs.tut.fi/~jkorpela/html/validation.html

ignoring standards and ignoring validation is bad practise. There really isn't anything more to add.

I have to say that I disagree with this blog post. Also I myself find writing valid XHTML very easy.

There are great reasons to validate. Accessibility in all its forms is absolutely important, and coding in such a way as to protect the delivery of material to screen readers, mobile phones, and so on is indeed smart and thoughtful.

But -- as someone on Google's Search Quality team -- I would like to bust the myth expressed in the comments here that Google specifically adjusts the ranking of sites based upon how well they validate. Google does not. The Googlebot is quite hardy and is typically capable of crawling and indexing even pages that validate rather poorly. And we at Google recognize that there are many pages with original and compelling content on the web that don't strictly validate (or even come close), and it would not be in our users' interest for us to rank them under, say, strictly validating but low-quality pages.

I love XHTML, but that's a personal preference.

If you're intent on using the target attribute, though, please make sure the user always knows in advance that it will open a new tab or window. It's rude to pop things up on people without warning them about it. (Although really it should be the user's choice where they want to open the link.)

I care mainly about validation for finding malformed html like missing tags and invalid nesting of tags. This is one reason web development seems so frustrating. I just spent a few days updating some 10 year old code.

Just for fun, I tried validating my wordpress blog. It was invalid because its been hacked. Again!

Brian

cite: "XHTML offers no compelling advantage -- to me -- over HTML, but even if it did it would also offer increased complexity and uncertainty"

The opposite is the case. The complexity and uncertainty are decreased. if you have no validation-error, the reason for a crashed rendering in a browser is found much easier and faster.

The xhtml-output of your developer-team is unified and easy to understand for each member, even for new members, which know the standards.

You don't have to think how to write the tags and attributes, the rules are set and well-known.

XHTML reduces ambiguity, and there are many tools for proofing - no other way exists to find many errors so easy.

Don't make me think, use Standards!

To the validation nay-sayers, first let me say I can write valid HTML just as quickly as you can write invalid HTML, so the alleged time saving by not validating is a poor argument. What it really demonstrates is a lack of skill and understanding on your part.

A web page *IS* a data structure whether you like it or not. Your markup represents a tree -- the DOM tree -- that the browser builds when parsing your HTML. If that markup is malformed then the browser must guess what you meant, so you can't predict what tree it is going to build. This becomes important when you try to apply CSS to it: is node B a sibling of A, or a child of A? That depends on what guess a particular made. You write a style of A B { color: green; } and some blocks aren't getting the color, because the browser guess wrong and made it a sibling. How much time do you waste figuring that out? There goes your time savings (which you didn't really have to begin with).

Now try writing some javascript to modify that DOM tree to get your fancy web 2.0 effects. Good luck, because the tree structure is not what you thought it was.

Oh, you don't care, as long as it looks good in the majority browser? In case you haven't noticed IE's market share is declining. (now down to 67.44% according to http://marketshare.hitslink.com/browser-market-share.aspx?qprid=1 ) Is your audience in the tech sector? IE's share there is significantly less than in the general population. Do you have non-US users? Same there.

As for Coding Horror's "59 Errors, 63 warning(s)" -- I corrected them all in under a minute just by running Tidy against it. Wow. That sure busted my budget.

All that said, I'm not even in the 100% valid camp, but I know why we aren't valid and the effect it has. We use Dojo to enhance our pages (google for "progressive enhancement") and its "dojotype=" attribute causes validation to fail, but the page is structurally and semantically correct.

Finally, I find Paolo's actual hostility towards validation to be appalling. We're interviewing for 2-3 contractors to speed up our next project phase, and, while not a "hiring manager" (because I'm pure techie) I am an interviewer and in my position I have veto power. I'd never hire him (and I'm sure he wouldn't want to work for me, with that attitude) and I've rejected a couple of people already because in spite of their claims of being expert web developers they didn't understand separation of concerns or structural integrity. Oh well, they probably didn't need the job in today's booming economy anyway.

I'm not usually this sarcastic, but I think the attitudes expressed by several people in this thread display a total lack of comprehension of what the web *could* be, and what it could offer over traditional print media besides the obvious ease of distribution. Kudos to those that clearly do get it.

Hey, I don't care about the foundation my house sits on, as long as I can get the exterior paint in cornflower blue.

Even XHTML 1.1 is easy to validate once you get used to it. I have been building so many valid websites that I don't even have to pass the validator to know my code is valid (I do validate it anyway).

I completely agree: we live in a malformed world. Getting 58 errors for an HTML 4.01 transitional doctype on Google's main site can really discourage anyone.

"We validated as the much saner HTML 4.01 strict, and even then I'm not sure it was worth the time we spent."

Again, once you get used to it, you spend less time in things such as: why the **** that CSS selector is not working?!

What these standards are trying to do is remove the design from the content. Both the a tag target attribute, and the a tag width attribute are mixing design and functionality in with what should be the content. HTML should just contain the content of your document, while the CSS and the JavaScript should maintain its design.

There are workarounds, and these workarounds are actually better then sticking all of this design and functionality into your HTML.

I mean, come on... It's 2009, content and design should really be separate entities.

The worst website I've found for W3C recommendations compatibility is:

www.amazon.co.uk

http://validator.w3.org/check?uri=www.amazon.co.uk&charset=(detect+automatically)&doctype=Inline&group=0

Approx 1300 errors and 136 warnings.

>Alright. I'll make sure I'll forward your ultimate judgment to the folks over at Digg, Yahoo, Microsoft, Google, Flickr and just about every other site in the Internet.

Wow, so did you develop one of those sites? Hey good for you. Oh wait, no you didn't, and instead you're trying to leverage the success of another to justify your own failures. Sorry, it doesn't fly.

Sometimes, although it is very infrequent, there are somewhat justified reasons why sites don't validate. Reddit, for instance, only fails when they inject failing ads (so their core system developers did a great job, including with user contributed content, but they are too trusting of injected ads). And many of those sites have been getting much, much closer to validation. Digg has a very small number of errors now, possibly ad related. Other sites might have succeeded despite the fact that the presentation layer was put together by pure hacks, but in the case of Slashdot we know that presentation changes are a nightmare for them because of the mish-mashed hack of a presentation they have.

>The validation was marginally useful, because we did have a few extra close tags hanging around in a few pages and it helped us find those

Yeah, that's what I meant by egregious errors. Having random or mismatched closing tags isn't just a curiousity. It's usually an indication of a serious structural problem that will hose countless hours when things don't operate as expected. Being able to catch those is a massive win of having a cleanly validating page.

Web standards are bullshit. There is no official reference implementation, no quality test suite, the documents themselves are huge and often ambiguous, making writing a good implementation virtually impossible.

Thus there are none. Every implementation is different and everyone adds their own idiotic extensions to it.

Validation might check structure - though no one else does - but it doesn't check semantics, making it a waste of time.

We shouldn't spend any more effort on trying to fix the web. The whole bloody thing should be exterminated and replaced with something sane.

@Dennis Forbes >> "Wow, so did you develop one of those sites? Hey good for you. Oh wait, no you didn't, and instead you're trying to leverage the success of another to justify your own failures. Sorry, it doesn't fly."

So what have you done with your perfect, validating web pages?

>So what have you done with your perfect, validating web pages?

Such a brilliantly clever response. I am defeated.

>Dennis Forbes Who?

It burns.

I think anonymous up there captured the essence of the code terrorists. No standard? No tests? Seriously, you really think this?

These are the people who leave the legacy of garbage that other people have to replace.

To me, if you need to think about making a page valid you're looking at the problem from the wrong angle. Standards compliant design should be something you write instinctively because it feels right. How do you expect different browsers to render a page the same way if there's no set syntax.

I agree fully with this post. 100% validation is for self-important know-it-alls, most of the rules are so obscure it's simply a waste of time. And XHTML makes the language harder to write. Not getting behind that, no way no how.

@Gimlock:

Maybe I'm a "self-important know-it-all" but surely the tangled mess of different browser rendering quirks that you get with non-valid HTML/CSS are far more "obscure" than the rules which are openly published for everyone to read??

"Such a brilliantly clever response. I am defeated."

Thus why you didn't answer the question? Oooh - SNAP!!

Out of sheer curiosity I decided to go back and validate a couple of my latest projects. It took me about 30 minutes a pop and it was a bunch of meaningless edits that had absolutely no bearing on whether my HTML was well formed or not. They validate now, though, so YAY, I am not a "hack" anymore! Dennis, I crave your approval, will you hug me now? *rolleyes*

ME GLAD NO MUST FOLLOW RULES. YOU DO WORK TO GROK MESSAGE; NOT PROBLEM MY. GOOD KNOW OK TO BAD STRUCTURE, GRAMMAR, LONG AS YOU UNDERSTAND.

*ahem*

What's with so many web developers using XHTML over HTML?

Refer to
http://hixie.ch/advocacy/xhtml
and
http://www.dev-archive.net/articles/xhtml.html

> What's with so many web developers using XHTML over HTML?

Especially when no version of IE supports it.

that is probably the reason why my iphone screams when i go to stackoverflow with it. you don't care but the device does.

"Joe Audette
Founder of mojoPortal an Open Source CMS that does produce valid Xhtml."

Sounds a bit like a douch, but whatever. I thought I'd check out Joe's cool "XHTML certified" mojoportal tool. So, I went looking for a site powered by mojoportal. The first one on the list on mojoportal.com is joeaudette.com. Seems fitting that we should test his hypothesis. So, I went to the page. The front page passes the XHTML validator. Click on the Developer Articles tab on the top and of the page ( http://www.joeaudette.com/techarticles.aspx ). It has no fewer than 473 errors according to the w3c validator. He didn't even check his own page before making a post like this?

Hilarious.

I think webstandards matter, how about having a lot of extra markup:

"Each button was set up with a nine-cell table so they could place each corner image, and still allow the button to expand in all four directions according to the width and height of the text inside"

<a href="http://stopdesign.com/archive/2009/02/04/recreating-the-button.html">http://stopdesign.com/archive/2009/02/04/recreating-the-button.html</a>

"ME GLAD NO MUST FOLLOW RULES. YOU DO WORK TO GROK MESSAGE; NOT PROBLEM MY. GOOD KNOW OK TO BAD STRUCTURE, GRAMMAR, LONG AS YOU UNDERSTAND."
Huh. Bit of an "All Liars" paradox here.
If your point was that grammar makes it easier to understand your point, you've made that point very clearly. But by doing that, you've proven that good grammar is unnecessary to make your point very clearly. But then you haven't made your point very well...

My head is spinning.

Once, someone called me for a problem in a webpage.
He had no clue on what was happening, and why the design was completely broken.

Tha validator reported a problem about a UTF-8 invalid character that it could not handle.

I always validate my pages.
Non-validation is a technical debt.

@Paolo: "I decided to go back and validate a couple of my latest projects. It took me about 30 minutes a pop and it was a bunch of meaningless edits that had absolutely no bearing on whether my HTML was well formed or not."

What does "well formed" mean to you?

To me that sentence makes no real sense at all. Doesn't "well formed" imply that it follows a standard? If your HTML was invalid then surely by definition it was not well formed?

oh god, I really hate the target=blank, it just makes my experience worse, i do know were i want the webpage to be open, i don't need any web designer to tell me that i need a new windows if he thinks i need it.

other important point, there is a huge advantage to follow standards, how do you like have to make workarounds to have the layout look close, no the same just close, on IE and FF? well, i hate it, at least the standards give me a little faith that it will be the same, without workarounds.

and I do care if a website that I make is validated, it is simple, there IS people that NEED to use screen readers, they don't have option, if I have the option to make their experience better, i will try to, regardless if there is a lot of them to increse my view counter or not

@Jeff: "When it comes to #4, I'd argue you really want an *API*, not a brain damaged "wow, we can scrape your site as XML!" mentality."

Although I know of some actual programs that live "scraping" other sites pages, I was referring to what you say, an internal API to build XHTML, to build a piece of markup that may be placed inside a web page, or sent to a less forgiving parser :-)

@ Screen Reader Advocates

Does having a website validate mean that it is screen reader friendly? I'm sure it doesn't hurt, but placement of navigation links, descriptions in hyperlinks, alt and desc (used anymore?) tags on images seem to be more important than validation.

I wonder how many people actually have used their sites with a screen reader, but they can be downloaded for free (very nice plugins for FireFox).

Point is that "screen reader browsers" behave a lot like others like FireFox/Chrome/IE where they do their best to make sense of gibberish and in most cases do a great job at it, even if the page doesn't validate.

The number one reason to use XHTML over html is that it contains an X - in some way it sounds way cooler!!! That's a naming that has a lot of following nowadays. Lot's of shit contains XXX. I should say that web development has got all XXXX (X-racy) - he he!!!

"(Also, if you have a ton of user-generated content like we do, you can pretty much throw any fantasies of 100% perfect validation right out the window.)"

If it is user-generated code, it should be inside a code tag...If you're talking about posts, limit the HTML they can use and check to see if it is valid.

You don't need to use XHTML, just make sure you validate strict. It is easy to do, and important if you want to have a properly formatted page with CSS. There is no CSS for invalid HTML, there are only hacks.

As a front-end designer/developer, I'm one of the few who does actually care if a site validates or not. Sure, I don't spend all day pinging URLs at the W3C validator, but if I DO happen to discover that a site doesn't validate, it lessens my respect for the site. It's a sure sign that the person behind that site is either too lazy, too ignorant, or just doesn't care about what they're producing. Conversely, if *that logo* is present, and leads to a successful validation result, I'm immediately given confidence in that site.

I can't believe you actually thing 'target="_blank"' is reasonable behaviour in the 21st century. The rest of us have moved on.

"why write prprly f u get yr msg undrstd nywy?"

I think that's precisely why.

I must say, I'm incredibly disappointed with this post. If everyone just did as they pleased, the Web would be a very messy place. Oh wait...

Keeping standards is Web development 101. I can't believe I'm reading differently on this site.

It's one of the reasons I love Python so much. People are forced to keep their code readable, in terms of indentation standards.

i'm not trying to be mean, but having been writing html and xhtml as strictly as possible since about 1998 (html 3.2 eeewwwww), i gotta say - all i'm hearing out of this post is alot of misunderstanding and laziness.

oh yes, lazy boy! using the right spelling and the right grammar seems to be a good idea - in english as well as in html / css and javascript. it is not so difficult after all. dyslexia is a learning disability, but nothing to be ashamed of. it is diagnosed in people of all levels of intelligence. if you are not able to master the language correctly you can always stay with loose.dtd. from the accessibility point of view only correct parsing is required, not 100% validation. but if you are just too lazy, another profession might suit you better maybe.

i think marge is taking things the wrong way

i'll expand on what i mean - just a little bit. i have little interest in writing a full article here.

this may sounds counter-intuitive, but it is actually EASIER to write for strict DTD's and it's it EASIER to write for strict XHTML over HTML. there are fewer rules, less loopholes, etc - however you wish to put it.

markup isn't hard per se. it's more of an exercise in discipline and rigor than anything else. that's why i use the term 'lazy'. i'm not trying to insult anyone. there are things i'm lazy with - but i'm not lazy with my profession.

Some people on here are out of control.

1. To those who say using "target=..." is annoying... sorry! This blog is obviously filled with readers who know how to use their browser. I write web apps for a health care company and see employees who get hired and have to be shown what a mouse is. Try explaining how to open links in new tabs when desired vs. opening them in the same window. If they click an external link, they think they're booted from your app! So, as a programmer, I try not to think of the 3% of the company that can use their browser properly. I think of the 97% who can't.

2. Code validation DOES help your scripts run better. Think about one o the cardinal rules... have you ever had two elements with the same ID on a page and tried to document.getElementById() in your js? To make things FULLY cross browser compatible, it is less likely you will be able to validate your CSS, but your HTML should be ok. It's a good guide to keeping clean, but don't let it break your heart f you have to deviate to get something to work right. The question should be, if you need to hack together some malformed html / css to get your page right, how can you limit that code down to the browser you're trying to fix while getting the other browsers to ignore it?

3. If you see a set of rules as just a way to make your life harder, then get out of programming! It's all rules... and generally strict ones at that. People who throw out standards completely are just shooting themselves in the foot. I've tried to debug pages with display issues, and it is by far easier to debug when the original author at least MILDLY tried to follow the standards. It does make a difference.

Yeah let's code crap 80's html; nobody cares .. browsers should handle this; not my problem.

*ahem*

Seriously, I fully disagree with this post, it sounds like a IE6 only web-developper speaking (sorry Jeff). Hoppefully i'm not feeling alone, after reading some comments.

For a blog with a focus on best practices, this seems like a very perverse post.

From Nick on March 6, 2009 08:16 AM
> HTML is not a visual formatting language, it is a language for defining
> document structure. [...] The correct way to define the appearance of your
> site is with css styles. Doing this separates presentation from content, and
> makes your content more re-usable.

The vast majority of HTML pages are not about document structure. They are in
fact about presentation. The web designer is making content to present to the
user to read.

Style, size and font attributes let's one express visual changes succinctly and directly. Using css styles, especially with external css files is unnecessarily complicated for many common cases.

Why make things difficult?

Now, *if* you need configurable and consistent style control across a set of pages, then great, use css styles when ultimately save more trouble than they cause.

But don't force their use.

Consider (if there actually was html allowed in these comments) <b>this</b> "bolded" word. How would it help anyone if I was force to have a css style to express that the word needed to be bolded? Using the <b>...</b> conveys it directly and is easy to type. Sure, a machine could do it, but why force the use of more complex software when it is not actually necessary?

For supporting true structured data requests, HTML is pointless anyway. Just use web requests that return data in directly machine usable form.

Re: rblaa

You realise that by giving a document a presentation you're implying structure? Structure and presentation are not mutually exclusive. So yes, a vast majority of HTML pages ARE about structure.

> Style, size and font attributes let's one express visual changes
> succinctly and directly. Using css styles, especially with external
> css files is unnecessarily complicated for many common cases.

Isn't that what the inline "style" attribute is for? Rather than having a tag for EVERY type of formatting, you have css properties. Otherwise why just have <b>, <i> etc. and not the whole arsenal?

> How would it help anyone if I was force to have a css style to
> express that the word needed to be bolded? Using the <b>...</b>
> conveys it directly and is easy to type.

Isn't that what <strong> and <em> are for? They describe structure, and imply presentation. <b> just describes presentation without saying why it needs to be that way.

CSS is meant to make things simplier anyway. If you want to change the appearance of something, you don't have to go searching through all the content to change it. If you also want to "apply all" that change, you can instantly. And if you want to edit some content, you don't have to wade through a mass of presentation junk.

I would love to fix www.microsoft.com's XHTML errors, but I've got bigger fish to fry.

re: rblaa

part of the benefit of using html to describe the TYPE of content and not the appearance of the content is searchability, or in more broad terms - machine readability. xhtml rules help with this also - it's simply easier to parse something with can be counted on to have a sane structure at the most basic level.

also, who here wouldn't want a smaller, faster browser? all this cruddy, invalid html support comes at a cost. any team who makes browsers has to add in the ability to drag in garbage and spit out gold. the cost in development time, testing time, speed, and space are not insignificant.

also, i think it's shameful for people who work professionally in a craft to care so little for what they are doing. (so that's not aimed at people who don't do this for a living, please calm yourseves ;))

> also, who here wouldn't want a smaller, faster browser?

I know I would. But I don't expect to see it when the browser has to implement a thousand pages of bullshit standard.

XHTML+CSS has a lot of good ideas, it really does. Javascript isn't half bad either, but I don't think it should have much use if you design the system properly.

The problem is the system isn't designed properly. It's a giant mess. It is overcomplicated with the folly of wanting to support web applications.

A new web should be designed with a lean, meaningful standard, covering useful stuff and ignoring useless stuff. It should have a comprehensive test suite and reference implementation from day one.

But this will never happen. Everyone will keep throwing more and more at the existing garbage, bloating up the worthless standard, bloating up the unstable browsers, bloating up developer's minds.

All we can do is wait for the inevitable day when it comes crashing down under its own weight.

@Joe (three up): It's highly ironic that microsoft uses an xhtml doctype..

When it comes to validation: Know the rules, live by the rules (for a while at least) and learn when you can bend/break them. *Don't* break them out of misplaced laziness. Triggering "standards" mode makes me happy (use FFox+WebDeveloper and a green V will make you happy too).

About the "target not allowed", a workaround is fairly easy actually. Just rewrite the URL's with JavaScript :)

Since the validator doesn't run the JS, it'll never know you use target's on your website.

Working demo on my blog :)

I run a couple of non-profit sites that validate to XHTML 1.0 transitional. It's not terribly difficult to do so, but the sites are also very simple in their design.

I think the main advantage to using valid XHTML transitional is that it is always well-formed markup; browsers parse these pages more quickly and they appear to load faster. They render more predictably across different browsers and they also render very well in wireless devices with no additional modification.

If you use a good HTML editor a validator and are familiar with web standards, it's just as easy to write valid markup as not, with the advantages mentioned above. Your mileage may vary.

Snorey, is your website static or not? Makes a big difference of course... Generated HTML from a dynamic (CMS, Blog and so on) isn't always in your control (not self made) and can generate invalid code..

@Tom: "If your point was that grammar makes it easier to understand your point, you've made that point very clearly. But by doing that, you've proven that good grammar is unnecessary to make your point very clearly. But then you haven't made your point very well.."

The point I was making is that while it's true you can get the point across using poor grammar (read: standards), it's merely passing the buck - you're making the reader (user) do the work for you. Misunderstandings are far more likely.

This is the typical post that Jeff posts when audience goes a little down. Nothing gets more traffic than a debate. Ofcourse he is wrong. He knows he is, we know he is. But being wrong in the right way can be fruitful.

From Jon on March 10, 2009 03:09 AM
> You realise that by giving a document a presentation you're implying
> structure? Structure and presentation are not mutually exclusive.

Of course. My point is to argue against the notion that web designers must give an HTML document a display-agnostic structure in the usual case. In practice people don't do that. They in fact don't need to. Note that this is an orthogonal issue to the writing of clean maintainable code/html/markup.

It all depends what your goals are. Style sheets are a useful tool, but they need not be mandated for all cases.

> Isn't that what the inline "style" attribute is for? Rather than having a
> tag for EVERY type of formatting, you have css properties. Otherwise why
> just have <b>, <i> etc. and not the whole arsenal?

It is not the precise syntax I was caring about. Inline style attributes are fine too. What I really object to is the forced separation of display and content, since the work required to associate them can cause unneeded complexity for the simple case.

If I just need to bold something, why would I use anything else except <b>? It's meaning is clear, and succinct. If I am not intending for the page to used in any other content other than this particular HTML usage, then why pay the cost of maintaining a display-agnostic content?

Do the work you have to and no more, and that work you do, do it right.

> CSS is meant to make things simplier anyway.

I in fact use CSS when it helps me, notably when I have shared styles that give sets of pages a consistent look and feel.

From janos erdelyi on March 10, 2009 07:48 AM
> part of the benefit of using html to describe the TYPE of content and not
> the appearance of the content is searchability, or in more broad terms -
> machine readability

This seems reasonable on the face of it. But when you dig into each problem, there are simpler ways to do it. Instead of forcing the web designer to take the care to have display-agnostic displayable pages (!), searching is solved by stripping out all markup.

As for machine readability in general, having any sort of processing based on scraping web pages to derive query or report results is asking for trouble. It is far easier to have the web site support a reasonable web service API where the artifical HTML parsing problem can be completely avoided, and results given directly in a form where they can be readily consumed.

> also, who here wouldn't want a smaller, faster browser?

For what it's worth, I too would prefer a web standard that was not so lenient, with clean parsing rules.

A simple compromise:

Use the validator to highlight *potential* errors, then correct the ones you agree with.

This is just more communal jibber jabber. There *are* big problems with all this tag soup out there.

You really should stop advocating sloppy quality. We all get that you're a kickass programmer, but as of late, you've been making people have doubts. First you say that the SOLID principles are bureaucratic and moot, and now you say that validating HTML is not that important.

Most novice developers will read your blog and fail to take your advice with a grain of salt. You have a large influence in the software development community and lately, you've been very callous. The more experienced devs will instantly recognize when you start spewing non sequiturs such as this blog post and actually give you the reasons on why you're wrong. Unfortunately not everyone will instantly recognize this or take the time to read the comments especially if they are being read in an a blog reader such as GReader which does not show comments.

Please be more careful on what you write in your blogs.

Validation will be more important when google decide to make it a variable in the pagerank algorithm

Not writing valid XHTML because you can get away with it is like saying you don't have to write good code if the compiler lets you get away with it. People need to realize that HTML is not just for making text look pretty. HTML IS code, and should be respected accordingly.

As what stated before, you should want to use XHTML and serve with an XML content type so you can use SVG. SVG is being supported a lot more on the mobile space and even though Adobe has dropped it it is still a very important technology.

Yes, IE doesn't understand it, which is why you need to do some content negotiation on the server. And, in some cases, it might be possible to serve up some VML for IE. Also, you can always generate PNGs from your SVG if you need to.

Yes, it takes more work to do this, but just because doing something is hard doesn't mean you shouldn't do it. The user experience comes first, always. If you don't respect your users they won't respect you.

Jeff: There's no need to make a horrible aliasy version of the "valid HTML 4.01" icon by scaling up the thumbnail: W3C have an <a href="http://validator.w3.org/images/valid_icons/valid-html401-v.svg">SVG version of that icon</a> and you can either use it directly, or scale it to a size of your choosing and then rasterize the result.

Hear hear! I can still remember being chastised in front of the class by one of my tutors at University for not validating HTML - I should have asked him how many validation errors he thought Amazon had. (hint: lots more than mine).

Eh, I can sympathize with both sides. Yes, standards are important, and yes, as a programmer I vastly prefer strict error handling than sloppy "ah, we'll make sense of your code somehow, don't worry". In theory, XHTML is nice enough. In practice, it's almost useless because of lack of support, inconsistent backwards compatibility (allow the same MIME type as HTML for backwards compatibility and make a few other concessions and then pretend it's compatible, and ignore the half dozen differences that would make a proper HTML parser choke on even the simplest XHTML document.

And then we have the even older HTML4.01 which was just a huge mess from the beginning and just.... sucks. It's a pain to parse, not a single browser does it correctly (it's ironic that the article Jeff linked to actually uses browsers shortcomings at parsing HTML as a reason not to use XHTML) and other agents have a hell of a time extracting data from it too (Certainly doesn't make it easier for the semantic web or microformats to take off if parsing a web page is all but impossible)

So we have a choice between the spec that works in theory, but not in practice, and the one that's completely flawed in theory, but which actually works ok'ish in practice because everyone are willing to bend the rules a bit, and browser vendors go to the most insane lengths to make sense of malformed HTML.

Thank you, W3C, for making web development such a hell. It's like every other bad decision in the history of computers rolled into one. All the messiness of the Windows API, x86 CPU's and C++ rolled into one.

I agree, nobody gives a rat's ass about validation in the real world. Only overstuffed pompous web developers who probably sucked up to their mother's all their lives and still do at the age of 35. Just give it 5 to 10 years (if the web is still around), either validation will kick in and a web page won't display at all until it's valid -or- validation standards will become such a problem, they'll just fall off the end of the earth and be one of those "I remember the day when..." things. For the time being, who cares if if validates!

To answer your question "I mean, who makes up these rules? And for what reason?", this is why:

HTML: HyperText Markup Language

What wikipedia says about markup language: "A markup language is a set of annotations to text that describe how it is to be structured, laid out, or formatted."

Markup language describes the *STRUCTURE*, not whether that structure should float: right or have a red background. This is what makes width="80" bad and style="width:80px" good.

At first everyone complained about the apparent lack of standards on the web, and now that we have them everyone started complaining it's too strict.

Yes, damn it all, let's make it even more strict! I don't see anyone complaining about C++ compilers not allowing sloppy code mixed with..oh I don't know..PHP? ..yet everyone picks on HTML. WTH?

Actually the doctype trick works well in Konqueror as well (as of 4.2.61 at least).

As a web developer, I can't understand why people make such a big deal about coding in html or xhtml, I prefer xhtml because it appears much cleaner in my eyes and validating isn't hard, we do it on every project and very rarely have to bend the rules for complete cross browswer compliance. Whats the big deal? if you find it that hard, what else do you struggle with?

next thing you're going to proclaim 'vote tables for layout'...

In my opinion with a valid code by W3C you will be sure that your content will be indexed by crawlers.

In my opinion with a valid code by W3C you will be sure that your content will be indexed by crawlers.

http://www.otimizacao-de-websites.com

Badly need your help. Awesome website, glad we found you. Help me! There is an urgent need for sites: kitchen islands. I found only this - <a href="http://purifiersair.biz/">Air purifiers uk</a>. Select flights to track from airline websites with the yapta browser add on. To book your flight visit palas travel cheap airline tickets travel deals. Best regards :mad:, Lobo from Kyrgyzstan.

Excuse me. If we fall, we don't need self-recrimination or blame or anger - we need a reawakening of our intention and a willingness to recommit, to be whole-hearted once again.
I am from Ireland and too bad know English, give true I wrote the following sentence: "Low on thyroid, use synthroid to your benefit."

Best regards :-D, Lloyd.

Sorry. What more felicity can fall to creature, than to enjoy delight with liberty.
I am from Cape and learning to write in English, give please true I wrote the following sentence: "Purchase synthroid without a perscription."

Thanks for the help :o, Melba.

Very good your site ..
Structured content and relevant .. congratulations!

http://www.sexshopvendas.com.br

The very good post
the congratulations of this blog .. I will return several times
to check the content!

xhtml strict and all this fucking bullshit validation garbage is for those cum lickers who think validation is so important to our lives.
validation is a load of old cum shit.

those that think its so important need to fuck off and stop fucking their mothers.

people are dying in third world countries, and you think by making a shitty piece of html or css valid is going to improve your life?

life is too short to fucking waste on "validation".

validate my big black cock if you are so enthusiastic about it people.
fucking pricks

This goes to Nick, whos site is http://www.charcoaldesign.co.uk/

You talk a big game here, yet your site is invalid.

Do not speak when you can not backup what you act like you do yourself.

A lot of people make their own website. They are not pro designers and they have no clue about validation, and they are not departing. Their number is increasing and they will sometimes use tools that produce fairly valid code, but often not.

Most comments here are entirely focused on pro web development, but that's not 100 percent of the web and it never will be. Sorry, but you will never have an exclusive web club that eschews imperfection.

this is a test here.

www.codinghorror.com/blog/ got :42 Errors, 57 warning(s)

Google Seo,search engine optimization,seo techniques,google adsense

The concepts mentioned above are not olmassa for a site ..
Thank you for this article .. Anyone can inform ..

Google Seo,search engine optimization,seo techniques,google adsense

The concepts mentioned above are not olmassa for a site ..
Thank you for this article .. Anyone can inform ..