| 1:03 pm on May 23, 2008 (gmt 0)|
The mobile web is growing very fast. xhtml is readable and renderable by a good percentage of mobile browsers, it's just a question of, does your site offer services that are likely to be used by mobile users.
| 2:38 pm on May 24, 2008 (gmt 0)|
If you haven't found it yet, I would first review this document [webmasterworld.com].
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.
| 6:13 am on May 25, 2008 (gmt 0)|
Thanks, mack and rocknbil.
I just sampled some major websites, and found an even balance between doctypes "HTML 4.01 Transitional" and "XHTML 1.0 Transitional". Given the objections to XHTML explained in the referenced pages, why is it so widely used?
| 8:37 am on May 25, 2008 (gmt 0)|
I think it's widely used because at one point there was no HTML5 coming and it was thought that XHTML was going to be the way to go.
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..
| 1:04 pm on May 25, 2008 (gmt 0)|
Thanks Suzy. So perhaps in the absence of a better existing standard, some organizations are choosing to develop in XHTML simply in order to enforce certain coding standards. This would also explain why Microsoft development tools are generating XHTML (this seems to include Visual Studio 2008, I just tried the free version and that's the way it works).
| 4:32 pm on May 25, 2008 (gmt 0)|
|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.
| 5:17 pm on May 25, 2008 (gmt 0)|
I once read that todays browsers isn't prepared for XHTML -- and that they actually would 'crash' if they encountered proper used XHTML (with an correct MIME-type or so).
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).
| 5:46 pm on May 25, 2008 (gmt 0)|
|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.
| 6:18 pm on May 25, 2008 (gmt 0)|
I have several websites that use HTML 4.01 Transitional, and with 100% valid HTML and CSS code, those sites work very well on the various mobile devices I have managed to test them on... including several Nokia, HTC, and Samsung mobiles, as well as on the Apple iPhone.
| 8:06 pm on May 25, 2008 (gmt 0)|
|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?
| 5:02 am on Jun 5, 2008 (gmt 0)|
| 5:06 am on Jun 5, 2008 (gmt 0)|
Code is poetry! Nothing like that smug sense of satisfaction of 0 errors or warnings in xhtml strict :P
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.