Is writing XHTML Strict markup worth it?

I've noticed that many web sites are being designed under XHTML Transitional despite adhering to most modern web design practices. I thought transitional was meant as a temporary solution f开发者_运维问答or porting over old markup that may require too much effort to redesign.

And many web sites don't even validate properly under Transitional. I try very hard to adhere to the strict standards under the belief that improper markup leads to much difficulty debugging when something doesn't work. However, it is a lot of work writing 100% valid code.

I'm curious as to whether or not it's worth putting in the effort to learn and write XHTML strict compliant markup.

EDIT: And if it is, why don't more people do it? It seems rather rare for me to stumble upon a proper XHTML strict web page.

Short answer: no.

I've never found Strict XHTML to be worth the effort.

The first problem with it is that it deprecated a number of HTML features which were actually useful, and for which there were no good alternative solutions. This was a particular problem if you needed backward compatibility with older browsers (which of course everyone does). The Transisional spec didn't deprecate these features, which is why people use it rather than Strict.

Features that were deprecated included the <center> tag (CSS alternatives were not cross-browser compatible at the time) and the target attribute for the <a> tag (which allows you to open a link in a new window, tab or frame; there still isn't any other way to do this, no-one stopped using it, and HTML5 has re-introduced it). There were quite a few other features along the same lines, but it's been a long time, and I can't remember them all.

Secondly, it was designed to cause the browser to fail if your markup had even the smallest error. This sounds great in theory, but was always doomed to failure. It was basically a reactionary step taken by the specification writers against the proliferation of poor-quality HTML code that was (and to some extent still is) a major issue for the web. But they forgot a key rule for designing client-server protocols, which is that the server should be strict about what it sends, but the client should be lenient. All successful client-server protocols follow this rule.

It is good to care about your markup being valid - in fact, it's very important, regardless of what (x)HTML dialect you're writing in - but you should be checking that in the development phase, not letting the end user's browser do your validation for you. If you're a good developer, you should know that your code is good before it gets anywhere near the user. And in fact, if that causes your site to completely break in front of the end user, then it's a disaster. With broken HTML, even if it's quite badly broken, the user can generally navigate and read the site sufficiently to be able to find contact details for you to report the error. With a browser that respects the strict XHTML doctype, a tiny markup error can cause your site to show nothing other than a standard browser error message. This is a very very poor user experience.

Finally, it didn't provide any new features. The one thing it did which older HTML versions didn't do was allow the document to be parsed as an XML document. This was good for validating that your document didn't have any errors, but didn't really achieve much else. You could also embed other XML formats into your document, using namespaces, but this was complex and didn't really achieve much new either.

XHTML was always an idealistic dream, and it is thankfully fading away now that HTML5 has taken over as the new-and-exciting-thing.

I used to write all XHTML strict, but that is because I cared about my markup being semantically correct. Unfortunately, most web developers either (a) don't care about semantically correct code or (b) are unaware there is even a problem.

Really, if you want to write in Strict, just write your page and then run it through the validator. It's going to tell you what's wrong and what you need to fix. You'll learn as you go along what things you should or shouldn't do. Looking at the official spec can help tremendously.

On another note, I'd also recommend moving to HTML5. HTML5 doesn't have types like "strict" and "transitional". If you want to write by stricter rules, you can. If you want to write by loser rules, you can. I also feel it's cleaner all around and I enjoy writing HTML5 much more than XHTML. Again, running your site through the validator is going to give you insight to stuff that you're doing that is incorrect.

As for what more people are starting to do, I would say there is a big push to HTML5. And not only because it's the new and cool thing to do, but because it fixes a lot of nuisances and annoyances that have existed in XHTML and HTML4.

So, my recommendation would be to head in that direction.

No.

I've been writing strict markup for a few years and there are no noticeable benefits that I can see.

I would much rather use the HTML5 <!DOCTYPE html> simply because it's cleaner and degrades well in IE.

I'd say Yes(ish).

Typically choosing the strict version would inicate what standards you should be adhering to going forward. i.e. deprecated attributes in xhtml strict (but allowed in transitional), would not appear in a later version of the standard.

Now my rule of thumb is kind of broken, with the movement from xhmtl to html5. As html5 doesn't have a strict version, but i'd say go for html5 (or even xhtml5) rather than xhtml strict.

But I'd say in general trying to stick to the most strictest version of anything keeps you focused on best practice ready for the next version i.e. things don't go backwards (in theory).