Oh, I agree wholeheartedly with that - and that statement can be applied across the board to every "recommendation" the W3C has ever released! The vagaries of the language and worse, outright omissions in the specifications (think HTML is bad? Take a look at the CSS docs) are 99% of why we have cross browser headaches in the first place. Look at the 'default' line height, which is 'suggested' to be anywhere between 120% and 130%, but is otherwise left ENTIRELY to the discretion of the UA... or how about there being ZERO information on how INPUT is even supposed to receive styling in the first place, or even IF it's supposed to accept it... Which is why Gecko, Trident, Presto and Webkit all handle the INPUT tag differently.
As Dan used to say, when the specification is vague the browser makers all up and go their own direction, and to hell with how anyone else is handling it.
You hit the nail on the head - it's TOO open to interpretation and it's BUILT using contradictory language! What it says in one section as should, it contradicts in the next section... and it's filled with "Would, May and Can" language instead of as xhtmlcoder steered it towards "Must and Is". A pen and paper gaming rules lawyer would have a field day.
Really if you are using XHTML 1.0 and following the compatibility guidelines, it makes no difference either way. You do everything appendix C suggests for compatibility, and there is ZERO difference between the two.
You ignore the optional compatibility guidelines and the advantage lies in serving it as the application types and NOT as text/html - which is what MOST of the people arguing this are ACTUALLY talking about. That allows you to 'extend' the specification with your own rulesets and use XML modules - the full functionality of a XML application.
But that's also a disadvantage as none of that actually WORKS in IE - which as a general rule makes the application mime-types (and by extension XHTML 1.1 which can ONLY be served as app types) undeployable "in the wild" on real-world websites.
... and since you can't use any of that stuff and have it work right across all browsers (and large sections of XML applications still don't work entirely right in gecko, webkit or presto) there's no legitimate reason to waste your time even WORRYING about the mime-type.
It's the difference in intent between 1.0 and 1.1 - 1.0 is there to bridge the gap while being compatible to BOTH specifications. 1.1 is to let you build XML applications using the HTML reference set as a baseline... at which point IMHO you might as well say screw it, forget HTML and just use straight XML apps at that point since you're no longer building websites.
Really that is the only reason to pick XHTML over HTML at this point - unless you also want to data scrape the page easily using something like PHP's XML Parser, which won't choke on XHTML 1.0 code that validates. (but don't trust the validator to check for well formedness! parsers that care WILL choke on poorly formed code that gets past the validator!).
I wouldn't say the validator is more likely than you are to notice the mistake so much as you are - but there are exceptions. Under 'true' html a bunch of structural elements suddenly become optional - you have jokers out there omitting HTML, HEAD, BODY because according to the spec, none of them are 'necessary'. The worst part is when optional closing tags on elements like LI crop up. You don't have to close your LI, you don't have to close your P... you put a P after the LI and don't close either, you hit the UL and IE will suddenly need to have haslayout and display:inline thrown a dozen elements further down the page even though
Explicit closings are a really good idea, required structural tags are a really good idea... Throwing the "would/may/can" attitude at them ends up with the same nonsensical mess that led to this whole "real or fake" discussion in the first place
I reckon that anyone who doesn't know about closing tags probably won't know about validators either, so it might not make any difference whether they are using an HTML or XHTML doctype.
I like 'em, but that probably goes with how I format my code. Something has more than one attribute, I like to put each attribute on it's own line for clarity... so the ending /> lets me know I'm actually closing the tag...
onfocus="showText(this.parentNode); return false;"
onblur="hideText(this.parentNode); return false;"
title="Abort, cancel, bugger out"
Get me out of here
The difference between the two starts getting pretty handy visually... but I'm a total zealot when it comes to tabs and carriage returns. The run-on single line messes most people make drive me nutters since really I can't read code that way...
Which is why I REALLY should like python a hell of a lot more than I do.
Nope, the mime-type is actually a pretty small and petty thing to be arguing about in the first place... The only reason to use the 'proper' application mime-type is for functionality that breaks backwards compatibility. Serving it as either really makes no difference in rendering anywhere if you actually follow the guidelines as to what's safe to use in the first place. (again, appendix C)
... and really if you care about any of that stuff, you should be using 1.1, not 1.0... and then it should only be for things like in-house crapplets where you can dictate what browser the end user is using... at which point you might as well be using a real programming language, and if you need a crutch grab a copy of XULRunner, or for the wheelchair-bound any of the visual languages.