Related
Is there any reason to consider XHTML related details for web development for someone who works with HTML4 and plans to work with HTML5?
Or was XHTML a "side" development in web technology which is not related to the current mainstream of web development (which I guess is HTML5)?
Rationale for asking
The reason I'm asking is that a StackOverflow answer I previously posted was recently commented on to the effect that "You should NOT use upper case HTML tags". When I asked "why" the commenter pointed me to a couple of articles, both of which gave the reasoning for lowercase-only tag names as "Upper case tag names are not allowed in XHTML" as the main reason.
Since I don't currently do web development in XHTML (pure HTML4.0) and only plan to use HTML5 as the next step, I'm interested in whether XHTML should be a factor in assorted decisions I make as far as web development
Please note that this question is NOT asking whether one should use upper or lower case tag names in pure HTML - merely whether the upper-case-tag prohibition in XHTML should be a factor in my decision making, or I should ignore XHTML related rules.
Most of the info you will find on XHTML fails to mention that the whole purpose of XHTML is to be used by both humans and computers for data exchange. XHTML was created so that computers could talk to each other, but in the same time remain readable by humans.
The most crazy thing is that various code monks became obsessed with XHTML compliance, without any intend of using the XHTML for data exchange and without understanding what XHTML actually is.
Edit:
A good example of XHTML use is an airline company publishing its flights. The company can utilize XHTML to produce a single list of flights that will be both consumable be humans visiting online and by services that will read the data for their needs.
On the other hand if you own a hair-salon, there is no need for your site to validate against XHTML standards.
Directly, there's no reason to take into account XHTML rules when marking up documents for the HTML serialization of HTML5.¹ However, it seems to be the modern practice to use lower case for tags, and that has been partly influenced by XML and XHTML. So if you find yourself working in a large team of developers, it is quite likely that the coding guidelines for the team will mandate lower case just for consistency's sake. So, it might be worth getting into the habit of doing so.
¹ Note that there's also the possibility of using the XHTML serialization of HTML5, in which case it would matter of course, but I don't think that's what you are asking about.
As far as I can tell, XHTML was intended to be a kind of combination between the features of HTML and the strictness of XML. For example, in HTML you can write <b><i>test</b></i> and the browser won't care, it knows what you meant. Whereas in XHTML that would cause an error and block the entire page from showing.
However most browsers just tolerated errors in XHTML as well, so it became kind of pointless.
Personally, the only reason I can give for choosing to use lowercase tag names rather than uppercase is because I'm too lazy to hold the Shift key and I remapped my CapsLock key to something more useful.
From what I've personally observed about XHTML, the only "benefit" of it is the versatility—for example, it is my understanding that with relative ease, one can create a custom tag/element or attribute and still validate with XHTML.
I see no need for custom tags, since if there isn't one that doesn't fit semantically (though the cases are minimal due to HTML5's improvements in semantic markup), you can just use a div or span and use a class or id to make it "fit." And HTML5 does allow custom attributes anyways.
So I see no direct relationship—or at least, I don't think there should be one—between HTML5 and XHTML (and anyways, XHTML 1.0 is meant to be a combination of HTML 4 and XML). The spec doesn't recommend one over the other, it just notes the fact that in HTML5, they are case-insensitive.
I personally use lowercase tag names for two reasons:
It's a nuisance to hold shift every time (though one could argue that you hold shift to get the angular brackets, but whatever).
It's a style preference—I truly think it looks much cleaner with lowercase tag names as well as a lowercase doctype (<!doctype html>). Uppercase tag names are really old-fashioned, and you don't really see them anymore. It may just be a thing with newer generation programmers such as myself.
And either way, you should pay no mind to rules that apply to a doctype you're not even working with.
First of all let's emphasize that syntax rules don't work alone, but they need the correct Content-type header to be fully interpreted by the clients. Currently web pages cannot be served with the correct XHTML header because Internet Explorer doesn't understand that.
The first advantage usually mentioned is that XHTML requires pages to be well-formed: true, but when browsers treat them as (malformed) HTML nothing enforces this rule, so it's up to you being a disciplined developer -- but you can be as disciplined writing good well-formed HTML too.
Another point often mentioned is that XHTML promotes the separation between content and presentation, but even in this case it doesn't really offer anything that can't be done with HTML -- it still depends on the developer since nothing is enforced, and no exclusive tools are offered.
So why do so many developer (including those of famous CMS/blogging softwares) still use XHTML syntax instead of directly writing what those pages will become anyway (i.e. plain HTML)?
Related fact: Stackoverflow uses HTML strict.
http://en.wikipedia.org/wiki/XHTML
From the wiki:
"The only essential difference between XHTML and HTML is that XHTML must be well-formed XML, while HTML need not be."
It's up to you which one you choose. There is no real difference in terms of what the user sees. Whichever you choose, please try to make it well-formed and make sure that your HTML/XHTML validates and follows the standards.
This probably isn't the actual reason, but it makes them parsable using a regular XML parser.
Sadly, XHTML syntax isn't as widely used as the XHTML doctype. You'd think people would be conscious about it, but a lot of the time (at least a few years ago), an XHTML doctype was used mostly because HTML 4 was being "dissed". That hasn't stopped people from continuing to use HTML syntax though. Open ended <li> and <p> tags, non-terminated <br> and <img> tags, tag attributes not enclosed in quotes, and more hypocritical nonsense.
Currently web pages cannot be served with the correct XHTML header because Internet Explorer doesn't understand that.
Sure they can, provided you're prepared to use content negotiation to serve a application/xhtml+xml content type to those user-agents that say they accept it.
There a number of reasons both good and bad why xhtml is so widely used. Jay Askren has a point about people who use XML in other contexts, (I'm one of them), but I doubt if that accounts for much use. If there is a good reason why XHTML is popular, it's most likely that the orthogonality of XML is a very seductive idea. It's simply easier remembering "Always close every tag, always quote the attribute values" than trying to remember all the rules about when you can safely omit tags and leave attributes unquoted etc., even though it results in a more verbose document.
There are other reasons like the fact that it's easier to indent your code if every opening tag has a matching closing one, and if you do, you've got a pretty accurate picture of the DOM laid out in the source code, which can aid with scripting. But I doubt that this is a primary reason.
Using XHTML states an intent, don’t underestimate that (but don’t overestimate this either). Web standards are politics: if nobody cares, nothing is gonna change. Using XHTML (or HTML5) signals “yes, we are in fact interested in the continued development of the standards.
Furthermore, while clients certainly don’t enforce XHTML rules with a text/html content type, design tools still can do this. XHTML is much easier to support for editors than real HTML (with “real” I mean the whole ugly SGML package). There are good XHTML validators that do much more than HTML validators can (e.g. Schneegans’ XML schema validator).
All in all, many arguments against XHTML are in fact straw-men that aim at some of the poorly-formulated arguments for XHTML. For instance, Microsoft is responsible of publishing long lists of purported XHTML advantages (such as semantic web design). Attacking those arguments is like reductio ad absurdum. But there are good arguments for XHTML.
I suspect a major reason xhtml is so popular is cultural and historical more than anything. XML became quite popular some time ago and it is still used quite heavily. It is good for for defining a data model that can be sent over the wire using webservices. There are lots of tools/technologies that work with it such as xslt and many others. It is natural for a developer to use html which is structured like xml, even if there is no real advantage just because they use xml in other contexts.
My company is looking to replace all websites in the group with a new CMS-based system and similar designs/styling, with E-Commerce functionality being added in a future phase. It's too big a job for me to do in a reasonable time-frame, so we are going to be inviting tenders from agencies.
I'm currently in the process of defining the technical requirements, and I'm intending to dictate that the selected system must have a Strict DOCTYPE and must trigger Standards mode (or Almost Standards Mode) in common browsers, or something to that effect [We have to allow Almost Standards Mode to cater for IE, obviously].
I've done a bit of homework an all of this - I don't want the spec to be limited by my ignorance, after all - but it won't surprise you all that I've found that 'current opinion' is completely divided on what is good practice.
There are plenty of people who advocate HTML4.01 Strict (fair enough), plenty of people who recommend XHTML1.0 Strict served as text/html (I'm OK with this too), some who recommend HTML5 but restricted to HTML4.01 tags (erm... still not sure if this is a good idea or not, but I see the principle), but also a not-inconsiderable number (including people on other SO threads) who recommend XHTML1.0 Transitional.
I just don't understand the reasoning for this... OK, you may happen to want to temporarily use something that been deprecated, and thus Transitional seems sensible, but some people recommend XHTML Transitional for new build.
After checking out other companies' sites for design inspiration, I've notice that many sites (if they have any DOCTYPE specified at all) will refer to a Transitional DTD. OK, we all know there is plenty of crap on the web, so perhaps I shouldn't draw too many conclusions. But checking out Web Design Agencies that we've come across, there are an amazing proportion of them (the vast majority of them, I would say) are using XHTML 1.0 Transitional.
Fine, so you don't necessarily have to be an expert to call yourself a Web Designer, but the sheer volume of Transitional layouts makes me wonder... Most of the sites seem to be otherwise reasonably designed (CSS layout, validating, accessible etc).
So, having finally got to the point(!), is there some reason why such a large proportion of these agencies are opting for Transitional DOCTYPEs? Am I missing something, something that I need to consider for my new sites?
Edit: Yeah, I realise the purpose of the Transitional DTD - I was just suspicious that so many otherwise-competent web developers are clinging on to deprecated markup. I wonder if you guys are correct and the answer is simply that they are a) are too lazy to get their own website to validate, or b) sticking with the default DTD of their preferred IDE.
The key re-assurance for me is that (according to your responses so far) I don't seem to be missing out on some key reason to use a Transitional DTD.
Edit 2: Regarding our CMS project - all the short-listed agencies thankfully seem to have their heads screwed on - Strict, valid and accessible.
I'm going to take a hard-nosed approach and say that Transitional doctypes are popular because some people are lazy or just don't care. Somebody told them they should validate their code, and transitional is the easiest to validate because it allows deprecated markup.
I agree with those who answered this previously and said that transitional doctypes are for transitioning to strict. Those are the only situations where I've used them.
Any new development should definitely be with a strict doctype. The choice of Strict vs. Transitional is more important than XHTML vs. HTML4. I would strongly recommend to you that in your technical requirements you require Strict.
Simply put, XHTML Transitional allows developers to more easily migrate a legacy HTML codebase over to that doctype. The Transitional doctype is more forgiving than Strict, but is meant as a stepping stone toward Strict.
Here's a good article talking about Transitional vs Strict: http://24ways.org/2005/transitional-vs-strict-markup
The default of DOCTYPE of MS Visual Studio is XHTML 1.0 Transitional.
XHTML 1.0 Transitional is more forgiving than its Strict counterpart and is the easiest to transition to.
For example in Strict DTD, you would need to write JS to open linked pages in a new window... and target="_blank" would flag an error (eg. from Designing with Web Standards...)
Strict is definitely the way to move forward, but transitional is the best choice for, Transitioning.
I think many people use XHTML 1.0 Transitional because it seems advanced, up-to-date or even beyond (XHTML is the future, dude!) on the one hand but on the other hand still does allow this “nasty stuff” like center, font, align, border, target etc.
Most of the web doesn't validate, as either transitional or strict. Transitional is generally easier to work with, but I think a more telling reason it's used more frequently is that it's also the default for editors like Dreamweaver and many CMS's use it as their default doctype.
Most web authors don't validate their pages, in which case, there's very little to choose between the DOCTYPEs and no good reason to change from the IDE default. The only practical difference to browsers between Strict and Transitional is that strict triggers Standards mode and Transitional triggers Almost Standards mode in gecko, presto, webkit, etc. Pages that actually require Standards mode behaviour are very few and far between and certainly won't affect the overall proportions that you see on the web.
It's worth noting that HTML 5 is being written without a Strict/Transitional distinction, largely because the authors of that recognise that the Transitional DOCTYPEs of XHTML and HTML4 are widely misused.
In XHTML 1.0 Transitional you have <center> <font> and <strike> which is not allowed within the strict version.
The reason is mostly portability between other templates. A nice article about that is here.
Good luck bludgeoning your pages into validating if you're using user input in a CMS. XHTML Strict doesn't like really common things like target="_blank" (we can have a debate about that, but people still use it). Additionally, if anyone adds the default youtube embed html, it won't validate.
I really don't understand the fascination with XHTML strict. Inline JavaScript typically requires a rats nest of escapes to make it compatible with XHTML and semi-backwards compatible with MSIE 5 & 6. Then there is the issue of not being OCD enough on user input to make sure you don't miss any illegal characters. It just seems like more effort then its worth. Nevermind that almost every developer I've worked along side of keeps forgetting to ensure the content-type returned from the server is reset for XHTML pages from text/html to application/xhtml+xml.
Wish I knew the name of the blogger, but someone else pointed out that a majority of supposedly XHTML compliant websites and open source packages are actually not because of that last issue, forgetting to set the content-type header correctly.
I'm looking to understand why XHTML is useful, or build enough of an arsenal of arguments to prevent it ever being used in future projects that I have influence on.
XHTML1 vs HTML4 and Strict vs Transitional are completely orthogonal issues.
XML might not give any huge advantage to browsers today, but on the server end it's an order of magnitude easier to process documents using XML than trying to parse the mess that is old-school-SGML-except-not-really HTML4.
Restricting yourself to [X]HTML Strict doesn't achieve anything in itself, other than simply that it discourages the use of old, less-maintainable techniques you shouldn't be using anyway.
Inline javascript typically requires a rats nest of escapes to make it compatible with XHTML
You can get away without any escapes as long as you don't use the characters < or &. And ‘// < [CDATA[’ isn't really much worse than ‘< !--’ was in the old days.
In any case, keeping the scripting external is much more manageable; you don't want to be doing anything significant inline.
Then there is the issue of not being OCD enough on user input to make sure you don't miss any illegal characters.
Out-of-band characters are exactly as invalid in HTML4 Transitional as in XHTML1 Strict.
If you're accepting user-submitted HTML and not checking/escaping it with enough of a fine tooth comb to prevent well-formedness errors you have much bigger problems than just complying with a doctype. You'll be letting injection hacks through and making your site vulnerable to cross-site-scripting security holes.
forgetting to ensure the content-type returned from the server is reset for XHTML pages from text/html to application/html+xml.
It's not ‘forgetting’, it's deliberate: there is not really that much point in serving application/xhtml+xml today. To account for IE you have to sniff UA, and then make sure you understand the CSS and JavaScript differences that pop up in both parsing modes... you can do it to prove your technical prowess, but it doesn't really get you anything.
Serving XHTML as legacy HTML may not be ideal, but it lets you keep the simpler, more processable syntax of XML (and potential interoperability with other XML languages like SVG) whilst still being browser-friendly.
People complain about the pickiness of the well-formedness errors, but having those errors picked up straight away for you to fix them is way better than leaving them there silently, ready to trip up some future browser.
there is a great post about the usage of XHTML # Beware of XHTML.
Hope it helps,
Bruno Figueiredo
XHTML 1.0 Strict tries to solve four problems:
XML is W3C technology and HTML4 wasn’t using it. Not your problem.
Strict seeks to be more theoretically pure than Transitional when it comes to presentationalism. But this is not an XHTML vs. HTML issue.
XML parser is supposedly simpler. (Not entirely true; the code for dealing with the DTD part is pretty complex.) These days, you get both XML and HTML parsers off-the-shelf, so this isn’t your problem. (Aside: the mobile argument is utterly bogus.)
application/xhtml+xml (though not valid XHTML 1.0 Strict!) allows you to mix other vocabularies. If you want to use inline MathML or SVG today, this is the main reason to use application/xhtml+xml today. However, the direction the HTML5 work is taking is making it possible to use MathML and SVG in text/html.
XHTML is useful because it's much easier to create a simple transforming stylesheet or roll your own parser for it, than it is for HTML.
Do you have to parse your HTML with a program, o for some tests? Then, use XHTML.
For everything else, HTML 4.01 (strict, loose, transitional, whatever) is perfectly "standard" and less "troublesome".
XHTML enables you to advanced rendering like SVG (Scalable Vector Graphics), which itself is an XML, but can easily be embedded in XHTML through the XML namespace extension without <embed> or <object>. Unfortunately, only Firefox and Safari does support it. Sorry IE6 users.
For more on SVG at http://en.wikipedia.org/wiki/Svg
XHTML makes HTML orthogonal with all the other xml-based structures in our universe, which has two primary benefits.
Design patterns we use in dealing with xml can be applied to html.
Software tools ditto.
XHTML has the advantages of xml. But then why the strict variant?
I see some similarities with deprecated functions. You can still use them this version, but they are possibly removed the next version. So I see the transitional version as deprecated use. It still works and it will work for a couple of versions, but if you want to build for the future, use the strict version.
Strict is intended to formalize the separation between content and style by making it more difficult to commingle the two. Elliotte Rusty Harold has a good write up on XHTML in one of his books, here's the relevant excerpt on 'Why XHTML'.
The only thing I've seen solved by XHTML is the "problem" of users using Safari: I don't know if the bug is still there, but when we were last asked to write in XHTML, we ran across a bug that made XHTML unusable with Safari. In XHTML, the following URL isn't allowed in anchor tags, because the ampersand isn't escaped:
http://www.example.com/page.php?arg1=val1&arg2=val2
so what you have to do is replace it with & like this:
http://www.example.com/page.php?arg1=val1&arg2=val2
but Safari converts & to & so you get this URL:
http://www.example.com/page.php?arg1=val1&arg2=val2
...and the hash symbol ends the URL as far as PHP is concerned. I know that there are ugly hacks that allow you to pass two variables in other ways, but if XHTML is going to force you to use ugly hacks, then you're better off without it.
Personally, I liked the concept of XHTML: much cleaner than most HTML we can see, easier to parse and validate. Like everybody, I started to code XHTML pages. BTW, I don't see an issue with inline JavaScript, no need for escapes if you put the code in CDATA. And IE5 is fortunately a bit out of the browser landscape, like Netscape 4 which forced us to write / > instead of />, thing I still see in pure XML sometime...
Now, I have read a number of articles, like the one linked by Bruno, which has lot of good arguments against its use in most cases. Basically, it says most browsers aren't just ready for strict XHTML (served as XML), it doesn't make much sense to server XHTML as HTML, and anyway it isn't that useful in the majority of sites.
Look at the arguments above: they are perfectly valid, and it is great to be able to put MathML or SVG directly in the page, to transform XML with an XSLT parser, to process the page with an XML parser.
But how often do you do that? Parsing the page is most often the problem of end users, which can use a good HTML parser. And given the number of browsers able to manage MathML, SVG or XSLT, it is more a need for intranet than for the vast Internet.
You can have an e-commerce or a blog or a forum, which spits out good XHTML pages. And the persons writing the descriptions, articles or messages insert <p><p><p> to skip some lines, when it isn't <p/> or some other exotic construct...
I believe in XHTML, but I think I will no longer use it for the little pages I do for my site. I will use HTML 4 with well written code (quoted attributes, closing tags even if optional, etc.).
And after all, if W3C is working in HTML 5, it is for a reason: HTML has still a live ahead, otherwise it would have been killed in favor of XHTML 2.
XHTML is by definition XML, unlike HTML.
This means you can do funky useful stuff with it, such as easily validate and parse it (since you know it's XML and thus can use the myriad of tools available).
Also, geeks like to make things "more correct" ;-)
This is a global standard issue
This is not just about xHTML, but about all the standards in the world. You need to make things clearer, from version to version.
xHTML is square and pushes coders to add semantic value to the code. It's fully XML compatible and therefor more easyly parseable, stylisable, etc.
Remember that a code is not just for coders, bot for machines too. In 10 years, people creating browsers or libraries won't want to implement the same complexes rules for old HTML processing but will rather expect something as clean as possible.
Search engine needs something to rely on to build semantic links between value and so it's better if there is only one easy way to do it.
And I am not talking about screen readers...
Standard, is above all, about going toward one unique open solution that fit everybody's need. Not just about adding new shiny features.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When developing a new web based application which version of html should you aim for?
EDIT:
cool I was just attempting to get a feel from others I tend to use XHTML 1.0 Strict in my own work and Transitional when others are involved in the content creation.
I marked the first XHTML 1.0 Transitional post as the 'correct answer' but believe strongly that all the answers given at that point where equally valid.
HTML 4.01. There is absolutely no reason to use XHTML for anything but experimental or academic problems that you only want to run on the 'obscure' web browsers.
XHTML Transitional is completely pointless even to those browsers, so I'm not sure why anyone would aim for that. It's actually pretty alarming that a number of people would recommend that.
I'd say aiming for HTML 4.01 is the most predictable, but Teifion is right really, "anything that renders your page will do".
in response to Michael Stum:
XHTML is XML based, so it allows easier parsing and you can also use the XML Components of most IDEs to programatically query and insert stuff.
This is certainly not true. A lot of XHTML on the web (if not most) does not conform to XML validity (and it needn't - it's not being sent as XML). Trying to treat this like XML when dealing with it is just going to earn you a lot of headaches. This page on Stack Overflow, for instance, will generate errors with many unforgiving XML tools for having invalid mark-up.
I'd shoot for XHTML Transitional 1.0. There are still a few nuances out there that don't like XHTML strict, and most editors I've seen now will give you the proper nudges to make sure that things are done right.
Transitional flavors of XHTML and HTML are deprecated. They were intended only for old user-agents that don't support CSS. See explanation in the DTD.
W3C advises that you should use Strict whenever possible, and these days it's certainly possible.
Transitional version has already been removed in XHTML/1.1 and HTML5.
XHTML/1.0 has exactly the same elements and attributes (semantics) as HTML4. The XHTML/1.0 specification doesn't even specify any elements! For anything else than syntax, it refers to HTML4.
Additionally, you'll be unable to use any feature of XHTML that is not available in HTML (namespaces, XML DOM) if you send documents as text/html, and unfrortunately that is required for compatibility with IE and other HTML-only browsers.
In 2008 the correct choice would be HTML4 Strict:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
but as of 2016, there's only one version of HTML that matters.
<!DOCTYPE html>
Dillie-O is right on with his answer of XHTML 1.0 Transitional but I would suggest shooting for XHTML 1.0 Strict and only falling back on Transitional if there's some piece of functionality you absolutely need that Strict is not allowing.
#Mike:
While I agree that validity is not needed to make a page render (after all, we have to keep IE6 compatibility in...), creating valid XHTML that IS compatible AND valid is not a problem. The problems start when people are used to HTML 4 and using the depreciated tags and attributes.
Just because the Web is a pile of crap does not mean that every new page needs to be a pile of crap as well. Most Validation errors on SO are so trivial, it shouldn't take too long to fix, like missing quotes on attributes.
But it may still be kind of pointless, given the fact that the W3C does not have any idea where they want to be going anyway (see HTML 5) and a certain big Browser company that also makes operating systems does not care as well, so a site could as well send out it's doctype as HTML 1337 Sucks and browsers will still try to render it.
There are some compelling warnings about the usage of XHTML, primarily centering around the fact that the mime-type for such a document should be sent as:
Content-type: application/xhtml+xml
Yet IE 6 and 7 don't support this, and then websites must send it as:
Content-type: text/html
Unfortunately that method is considered harmful.
Some also bemoan the fact that although the intent of XHTML is to make web pages parsable by an XML parser, it has in practice failed due to incorrect usage on existing websites.
I still prefer to write documents in XHTML 1.0 Strict, mostly because of the challenge, and the cleanliness and error-checking that a validator gives. I enjoy the syntax a bit better, because it forces me to be very explicit in when tags end, etc. It's more for me a personal choice than purely technical.
Anything that renders your page is will do so regardless of which popular standard you use. XHTML is stricter and probably "better" but I can't see what advantages you will get with one standard over another.
Personally, I prefer XHTML 1.0 Transitional.
XHTML is XML based, so it allows easier parsing and you can also use the XML Components of most IDEs to programatically query and insert stuff.
Transitional is not as strict as strict, which makes it relatively easy to work with, compared to strict which can often be a PITA. Comparison between Transistional and Strict
1.0 is "more compatible" than 1.1 and 1.1 seems to be still under some sort of development.
I aim for XHTML 1.0 Trans. It's better to conform so when bugs are fixed in the browsers you won't suddenly be working against the clock trying to figure out what actually needs changing.
In my opinion 1.1 is borked and 2.0 has been smashed to smithereens: Do I really need/want a header/footer tag?
I'm all for XHTML Strict every time. I strongly believe that HTML should be more like XML. It's not hard to validate it if you know XML and the W3's validator ipoints you on the right track anyway.
XHTML 2.0 is heading toward what the W3 have been aiming for for a long time - the semantic web. The best benefit of XHTML 2.0 for me is that every conformant page on the web will be understandable as content, or an article (for that's what pages are - documents) becuase they all apply to the same standard. You would then be able to construct intepreters (i.e. browsers) that present the content in a completely different manner - there's literally thousands of ideas waiting here.
If you want to use XHTML 1.0 in an HTML-compatible way, that's fine. However, do note that the W3C validator and the XHTML DTDs know nothing about mime types and how browsers behave differently (like <map> name/id matching) between them. The DTDs know nothing about how well browsers support certain elements (like <embed> for example) either.
What this means is that the XHTML DTDs and the validator don't reflect reality and trying to conform to them is pointless.
If you want to use XHTML just so you can close certain elements with /> (where html-compatible), just use HTML5 markup (so the browser is in full standards mode). HTML5 allows the use of /> in an HTML-compatible way (the same HTML-compatible way you have to do it when using XHTML 1.0 markup with text/html). Then, just stick to what works (you know better than some DTD) in browsers.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<title></title>
</head>
<body>
<p>Line1<br/>Line2</p>
<p><img src="" alt="blank"/></p>
<p><input type="text"/></p>
<p><embed type="application/x-something" src=""/></p>
</body>
</html>
Then, use http://validator.nu/ to make sure it's well formed at least.
If you have tools to generate your XHTML like any other XML document, then go with XHTML. But when you just use plain text templates, text concatenation, etc. you are OK with good old HTML 4.01.
Browsers now start to support this 10 year old standard.
Important: Avoid being called a bozo when producing XML
I don't think it actually matters whether you use XHTML or plain HTML. The end goal here is to have low maintenance and quick development through a predictable rendering. You can get this from using xhtml or html, as long as you have validating code. I've even heard arguments that it's best to target quirks mode, because new versions of browsers don't change quirks mode, so maintenance is easy.
In the end, it all becomes tag soup, for good reason, because getting web app developers to write error-free html means asking them to write bug-free code. Validators are no help, because they only validate the initial page view. This is also why I've never seen the point in xhtml served as xml for anything beyond static sites. The level of arrogance a web apps developer would need to have to serve up their web app as xml is staggering.
HTML 4.0 Strict, or ISO HTML.