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?
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.
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
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.
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.
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).
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:
–
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.
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: