XHTML 1.0 Strict, Transitional .. or XHTML 1.1?

Ah, this topic again.

I do not choose my doctype for the reasons other people do. I do not choose it because I want the 'latest and greatest' since that is usually a miserable /FAIL/ on browser support. I do not choose it because it's 'trendy'. My choice is based on which one has the most consistant clean rules... So my choice is XHTML 1.0 Strict.

XHTML brings ordered structure do what is, frankly, a complete MESS.

HTML is such a sloppy inconsistant markup method BECAUSE it lets you omit things that make determining where 'blocks' even begin or end a complete mess - AND it can (theoretically) take longer to parse because while in XHTML you can find the end of a section by it's closing tag, you can make no such assumptions with HTML where people will often omit entire tags like </head>, </body>, </li>, put stuff in 'invalid' locations like scripts and content AFTER </html> etc, etc... Certainly non-content tags like IMG, BR and HR could be assumed, but without a proper ending tag you are pretty much leaving a LOT of guesswork to the various browsers.

I come from a backround of working in Wirth family languages (pascal, Modula) and I like to have clear defined opening and closing structures. HTML lets coders get away with sleazing their way through the markup resulting in code that most of the time isn't fit to wipe with.

You'll also notice I say STRICT - I design in strict because it gives me stops me from being tempted to use methodologies (iframe, target, align) that have NO PLACE IN MODERN MARKUP. Certain tags and attributes were deprecated FOR A REASON, and not using them usually leads to cleaner code - especially once you STOP using presentational attributes and tags and do PROPER separation of presentation from content.

XHTML 1.0 was meant as a bridge between HTML and XML, unlike 1.1 and later which want to do that whole 'XML Application' nonsense which frankly, overcomplicates something that is supposed to be simple.

...and for the people who say serving it with the text/html mime-type is 'not using it as it was meant to' - BULLSHIT. Oh noes, the 'wrong' mimetype that it EVEN SAYS IN THE SPECIFICATION IS OK TO USE!!! Whatever shall we do?!?

The point of XHTML 1.0 is to provide a working bridge between XML and HTML, bring a consistant simpler to parse AND follow structure, with the option of full backwards compatability to SGML/HTML. If we're talking XHTML 1.1 or later, that arguement WAS entirely valid - but being it's still completely undeployable in the wild who gives a flying fig leaf about this XML Application NONSENSE.

The whole XML application thing burns me, much like XSLT it has the problem of being used by people who claim it's faster and saves bandwidth, when in every case I've seen it used it introduces two or three extra layers of date parsing AND shoves more data around - but then we're talking the same people who seem to have it in their heads that XML is a machine readable format, which is the farthest thing from the truth. XML was developed to be HUMAN readable and Machine PARSEABLE. Machine readable means null-term or start-sized strings, integers stored as integers NOT strings, reals stored as single/double/extended NOT strings, etc, etc.

Topic drift aside some people have talked about what the client wants - In my experience most clients web developers have don't know enough about web developement to know the difference between HTML and XHTML from the hole in their arse... Generally they don't care about that, they want something easy to maintain, stable, secure, fast and with accessability to as many users as possible... and they are willing to sacrifice everything for the first of those, as evidenced by the popularity of the steaming pile of manure known as turdpress.

 

Tell me about it.

I agree with everything you say except:

Yes, the spec says it's OK to do that as long as you remember the caveat that it is no longer xhtml and will be treated as html.

There are quite a number of companies that use xml in applications, converting, as necessary, between html, xhtml, pdf, ps, and all sorts of documentation. Recently, a web app I was working on had a lot of debate on whether to use xml or not, but that app is definitely small time and not as documentcentric as those purposes.

Yep.