Why XHTML?
Filed under: web development
Number of comments: 
Number of trackbacks: 
Tagged with: I guess quite a lot of us know it. Web standards. It's cool to be part of the gang that actually cares about them. It feels great to see those blue colors of validity on the W3C validator when you click the 'Valid XHTML' button on your site. You're a web developer that cares. Aren't you great? You're part of the "valid XHTML" community and you can proudly display whatever badge or button on your site to tell the world all about it. And as if that's not enough, you're not only using valid XHTML but valid CSS too, and you killed all the poor tables in the process. Tables are evil. They needed to die! So here we are with our shiny valid XHTML websites with a "CSS Zen Garden-worthy" CSS layout. But why really?
<devils advocate mode="exaggerated-but-honest">
Web standards make your site work in many browsers
This is an often heard argument. However there are things to say. First of all, standard HTML 4.01 works just as well in 'many browsers' as XHTML 1.0 or 1.1. I don't think any browser vendor will bring up the idea of dropping HTML 4.01 support in many years to come for the simple reason that it would break way too many sites causing no one to use this particular browser. Therefore HTML isn't gonna go away any time soon. Also, HTML saves bytes because you don't have to close all your tags in order to be valid. Let's face it, adding extra slashes to tags or adding closing tags doesn't really do anything in the real world except for the w3c validator to tell you how much your code rocks for being valid. Sure the extra couple of keystrokes don't hurt but one can argue about their real world use. If we combine the quite probably assumption that HTML 4.01 isn't going away any time soon with the fact that most websites are relatively short-lived (3 years is already very long for a site to remain unchanged) we can quite safely assume that there's absolutely no reason or whatsoever to use XHTML.
Table layouts suck! go semantic XHTML with CSS or we'll shoot this dog!
I have mixed feelings here besides feeling really sorry for that dog. In fact it's true that, once you know all the ins and outs of CSS it's easier to get designs transformed from photoshop to real webpages if you use the modern CSS way of creating your layout templates. However it takes considerable time to learn it and once you do you'll find that the no. 1 browser on the market doesn't really play nice with your perfectly valid XHTML website. In order to get it to look right we're forced to use all kinds of dirty hacks to get it to work in this particular browser. Now I wonder, don't these hacks sort of defeat the purpose of 'wanting to do it right' ?
The good old 'table layout' may be blasphemy in the eyes of us webstandards-loving developers but honestly, most sites that use it work absolutely fine in all browsers. Heck, they even work in really old browsers such as MSIE 4 while our shiny new XHTML/CSS designs fail horribly in them. It's something to keep in mind especially if we're creating webpages for audiences in under-developed countries who are surfing the net on trailing-edge hardware.
Accessibility
Accessibility is a hot issue these days. We need semantic XHTML in order to get our message through to our blind or otherwise disabled audience. The semantic principles however apply quite well to HTML 4.01 as well. There's no clear reason to use XHTML in order to build an accessible website that I can see.
So...
So far I haven't found any really compelling reasons to use XHTML. To make things worse, those who use it, including me, are actually doing it wrong because we're not serving application/xhtml+xml but text/html! This makes the whole thing sort of a moot point if you think about it. It's like serving a JPEG but telling the browser it's going to get a GIF and assuming the browser will be smart enough to discover what it actually is we're pushing down it's throat. There are some advantages to a CSS based layout compared to the old school table based layout but for many purposes it really doesn't matter as much as people want us to believe. I think I've covered most widely used arguments but they're rather 'thin' at best.
So explain all this CSS and XHTML vanity stuff here then will you?
Don't get me wrong. I love to work with web standards, XHTML and CSS based layouts. It brings out the geek in me, wanting to create perfect code and perfect design. I guess it's also a sign of quality. It shows that the guy who made it knows what he's doing. He's been there, he's done that. He's meticulous and precise. His PHP application code will probably look just as clean. Now let's hire him!
I'm simply questioning the real-world value of it all. To me the best and most honest reason for using all this fashionable web standards / css stuff is simple and down to earth: because I can! That's all there's to it really.
Happy (X)HTML-ing!
</devils advocate>
At 07 April '05 - 17:18 Bram wrote:
At 07 April '05 - 19:11 Marco wrote:
Don’t get me wrong, I’m clearly playing devil’s advocate in this little essay. It just strikes me that it’s quite hard to bring up any REAL arguments instead of the geeky kind that the average joe user couldn’t care less about.
At 07 April '05 - 22:26 weefselkweekje wrote:
Ok, you’re welcome to use divs in 4.0 as well, but why would you? Why not go all the way and close your tags to make it xhtml? The difference is not in the syntax, it’s in the approach. The syntax only makes your pages xml, and thus readable by just about anything :).
I’ve nee doing table-based html4 for a big commercial project for the last 5 days and after doing valid xhtml for a few months it became quite apparent why the old way sucks :).
At 08 April '05 - 11:08 Max wrote:
Marco, I think you’re damn right about the nerd-factor, but I’d like to take it even slightly further: we’re not doing it for the occasional potential customer. Customers don’t look at the source. Customers don’t know shit about HTML, they don’t care, and they never will.
No, the true reason we’re coding XHTML is sheer egomania. We like to gloat about the fact that our site is semantically correct, thank you very much.
The only folks that really notice, that can really appreciate our hard labour and smart thinking… are other nerds.
Of course, I’m not saying that you should compare a 1996-style HTML4 tagsoup mish-mash thingy from Frontpage to a completely valid XHTML Strict doc. I’m talking about valid, reasonable HTML4 as coded by a pro.
And yes, I still use the occasional non-semantic table. Not because I don’t care, but because my customer wants his site live, dammit, and I really don’t have the time to keep dicking around with floating divs and having them work in most major browsers too.
Semantic is nice in theory, but unless you write a book about it, it doesn’t put the bread on the table, so to speak. Getting the job done does.
At 08 April '05 - 12:19 Marco wrote:
Clients don’t care as long as their site looks good and works in the major browsers, no matter what you did to get there, pretty or ugly code.
I STILL like Web Standards. I just wish more people would care about them, like clients for example
At 08 April '05 - 14:20 Max wrote:
At 08 April '05 - 22:33 Jeiel wrote:
Accessibility also benefits from XHTML/HTML (whatever floats your boat) that is structured well. Again, using the table layout example, I heard somewhere (okay so maybe anecdotes aren’t hard evidence but meh) that putting content in tables make screen readers say “table data” or something to that effect before reading the actual content. Partially visual impaired people can also benefit from the XHTML/CSS approach with the use of alternate stylesheets.
Also, Stuart Langridge agrees with you. http://www.kryogenix.org/days/2005/02/21..
The comments are interesting though.
At 08 April '05 - 22:49 Marco wrote:
The bandwidth usage… hmmm.. it’s a slight advantage but again: I’ve never encountered clients who made bandwidth usage a real issue to pay attention to when developing the site.
There are quite some arguments in favour of standards compliant design. I’m aware of most of them and I even agree with them. However this is all still coming from my personal purists view. I still don’t believe most clients ‘give a shit’ about all this really, no matter how many geeks like us tell them they should…
At 09 April '05 - 14:20 weefselkweekje wrote:
Check out the DENG project as well… a xhtml browser in Flash, as a potential textfield replacement… very cool.
http://claus.packts.net/
At 31 January '06 - 19:30 Berticus wrote:
However, xhtml and css keeps things clean. It’s just a method to making websites, but it makes everything clean and simple.
When you start incorperating data with styles, you have to break up the data even more. I make all my sites with valid xhtml 1.1 and css levels 1 and 2. How does it compare? It looks the same as if I just used tables and invalid html 4.0.1 transitional. But take a look at the syntax and it’s VERY clean. And it ends up being smaller than html anyway.
Another thing, with css, you have something that can reach more than just your pages. Once again I stress the separation between data and styling. Look at phpBB. You have to download quite a bit for 1 skin/theme. That can easily be done with css. I think it’s much better to skin/theme something with css. It’s easier to change. If you use tables, you have to open up the document containing the data, and change it there.
So how is xhtml really supposed to be used? It’s supposed to be a basis of documentation. I believe the full language hasn’t even really been developed. Xhtml 1.0 – all flavors – were just transitional languages. Xhtml 1.1 is still pretty transitional. I took a look at xhtml 2.0, and there are some pretty big changes, and it seems you’re now making a more separation between data and styling.
Could you do this with frames? Sure, but the problem with frames is you’re loading more than 1 page at one time, and these pages aren’t clean pages…
Like I said earlier, most people don’t use it correctly. What you’re supposed to do with xhtml is have pretty much all the data in there. Then you extend that data with other stuff like xforms instead of the forms module. Use xslt instead of css, and xslt is actually cleaner than css. With css you’re still incorperating a lot of the styling with that data, even if you use a separate file like I do.
That’s at least just my interpretation of xhtml and how it’s supposed to be used.
Validity is the key though. It makes things more portable. By that I mean it theoretically means it’s visible in all browsers, and all browsers will display it correctly. Well unfortunately Microsoft hasn’t updated their rendering engine in 8 or so years. And with IE7 coming along, they still don’t really plan to.
However, new people making rendering engines can look at the documentation, and know what it’s supposed to look like. They can make their engine based off of that, and you know you will support them.
Microsoft agreed to follow these recommendations. With my site, I’m not letting them get away with just saying, “Yeah, we’ll comply” but not actually do anything. Well, they said they would comply, and I’m holding their word to it. That was the whole point of the creation of w3c and standardization. It’s so there wouldn’t be disagreements like this in the public. That’d all be kept private between the internet engineers at w3c. So instead of arguing about whether we should all use what, we can just focus on doing what we intended to do in the first place – create beautiful pages in clean and efficient code. w3c can worry about the actual language; that’s why they were created.
At 08 April '07 - 02:07 John wrote:
No, not that!
Your mobile phone.
WML and cHTML have now moved on to XHTML Mobile Profile and it uses ONLY valid XHTML.
Why? Well if I was building a mobile phone browser with limited memory, the last thing I’d want to do is bog it down with forgiving HTML and all it’s baggage.
So …yes. There is a real world reason why we should use valid XHTML
.