Welcome to WebmasterWorld Guest from 22.214.171.124
It really "depends." Depends on whether it's a valid doctype (not quirks mode,) depends if your site relies on functions specific to XHTML or if plain HTML will work. XHTML is meant to be extensible, if you're not creating your own XHTML definitions, there's really no reason at all to use XHTML.
XHTML, was the way to keep up with and learn the XML syntax (always closing tags, lowercase etc..) it exists as a transition between HTML and XML in order to promote good coding practice. It has helped many people understand how their CSS is applied, better because of the closing tags and nesting hierarchy, e.g. some wouldn't know that in HTML with its optional closing tags for some elements that their <p> elements would auto close before a ul or div, it has had its benefits to a whole generation of coders learning CSS/HTML.
A lot of CMS's and developers in the last 10 years have simply used XHTML as their coding style of choice because that's how they learned - it is nothing more than HTML with a few extra restrictions, if you're into validation. Hence its widespread use still. It's not wrong to use it but if you are perhaps understand that you're not using it because it's a 'better' level of coding just one with a different benchmark for validation.
just my thoughts..
why is it so widely used?
Suzy's first comment is spot on for the ORIGINAL reason, IMO. XHTML was the predicted future standard because of extensibility, which creates smart documents. Example:
The titanic was indeed a titanic undertaking, eventually they made a movie about it called The Titanic.
A search engine has no clue of the context of the three references to titanic above. But if I do this,
The <ship>titanic</ship> was a <size>titanic</size> undertaking, eventually they made a movie about it called <movie>The Titanic</movie>.
And create my own DTD (Document Type Definition) for this document that pre-defines ship, size, and movie, I can now supply context to the search engines so they know what I mean. Searchers can find more relevant documents in this way.
This concept is fascinating. I thought this would be awesome but guess what? It never really took hold, most likely because it presented far too many opportunities to spam pages.
Returning to the original question, I have the following real-life experiences as to WHY people still use XHTML:
So the software manufacturers are both lazy and lead unaware developers in the wrong direction.
I think those two reasons are why you see XHTML and XHTML markup in what are, in fact, HTML documents.
That's why I stick to HTML 4.01 Strict -- though I have prepared my MarkUp so it could be converted into XHTML in a short amount of time (if needed).
xhtml is readable and renderable by a good percentage of mobile browsers
I would add this to rocknbil's excellent summary as the third reason.
In fairness to mack (who posted it) it was necessary to use XHTML for many mobile devices (especially Japanese ones) a few years ago when XHTML Mobile Profile was being touted as "WAP 2.0" and XHTML generally as the "one web" solution, but these days - with the exception of WML only browsers - they all seem capable of handling well-formed HTML, or at least the basic stuff that you would feed to a small-screen device with limited capabilities.
The good news is that, while there is generally no benefit to changing to XHTML, there is no apparent harm in leaving it in place if that is what you already have.
some organizations are choosing to develop in XHTML simply in order to enforce certain coding standards.
in the absence of a paper/recognised qualification I'd say yes that's about it, a least if you have an opinion of one or the other it means you know there is at least a small but subtle difference?
Aside from additional compatibility and standards compliance, it makes it easy to catch bugs (typos, logic issues occasionally, etc) in development. It also helps you learn a lot of in and outs of html/xhtml and why things are done the way they are and I feel I am a better developer for it. It's pretty easy to implement, though if your development environment is generating a bunch of issues you have to correct I could see a point of how fiscally sound the idea is. We code everything by hand and I would wager very little time is added to development (I actually think its a net gain because of the issues mentioned above) using it.