I’ve been threatening to write an article about XHTML for a while now and so here goes. I’ll also talk about CSS and table-less web designs, because in the Web world right now XHTML and CSS are as hot a couple as Ashton and Demi (who may’ve broken up now, but I couldn’t think of another celebrity couple).
Recently I converted my Radio Userland weblog to a CSS table-less design. That is, the design you are looking at right now does not use tables for its layout and all the style is entirely defined using CSS (cascading style sheets). I used a CSS design from the CSS Zen Garden, one by Michael Landis (who kindly gave me permission to use it). I don’t have a lot of experience designing CSS, so I thought it would be best to start with an existing design by someone who’s already mastered the art of CSS. That way I can learn by doing, which I discovered long ago is the best way to upskill on the Web. At the same time, to give my CSS design the best chance of success, I decided to make my site XHTML compliant.
XHTML is basically a combination of HTML and XML. It is a bridge between two worlds – the semantic expressiveness of XML and the hypertext standard of HTML. So what are the main differences between XHTML and its predecessor HTML 4? As defined by W3Schools:
– XHTML elements must be properly nested
– XHTML documents must be well-formed
– Tag names must be in lowercase
– All XHTML elements must be closed
In a word, XHTML is a lot fussier than HTML. The reason for this is that XML requires a strict adherance to syntax rules, so that there is no ambiguity for computers. Machines can’t handle ambiguity, but humans (and most web browsers) can. The upshot of this is that XHTML, because the syntax requirements are tougher than with HTML, requires a lot more work and effort to write. Even writing this post will be extra work for me, because I’ll need to run it through HTML Tidy to fix up all the HTML errors the Radio Userland WYSIWYG editor produces.
So if it’s more work, you may be wondering why bother with XHTML? After all, web browsers today still use HTML 4. So it’s not as if you have to use XHTML in order to publish on the Web. The answer is all about future compatibility. By using XHTML, you are pretty much assured that your designs will work not just today – but in a few years time too. Why? Crudely put, it’s because XML is here to stay whereas HTML 4 is on the way out.
One of the most entertaining arguments for XHTML is this Jeremy Keith essay, which uses The Matrix as its inspiration:
“Web development is a war and we are soldiers, writing hacks and workarounds to make designs look right in buggy older browsers.
What if tomorrow the war could be over? What if we could build sites that won’t fall apart in future browser releases? Isn’t that worth fighting for? Isn’t that worth developing for?”
Ha ha, so you have a choice – the red pill or the blue pill?
Cristian Vidmar ranted recently against table-less CSS designs. He’s just released a nice looking table-based theme for Radio Userland. Cristian’s point, re-iterated today, is that CSS designs don’t necessarily need to exclude tables. If the layout will be complex and/or graphical, then Cristian reckons it’s better to style your site using CSS and tables. This is a fair argument – for practical purposes tables are very handy and are less work to implement than CSS positioning. However the main argument against tables for layout is that tables don’t convey any semantic information about the structure of the site. Tables are a presentation device, whereas using DIV tags in CSS for layout not only takes care of presentation but additionally conveys information about the structure of the data. A List Apart explains this quite well:
“DIVs imply a logical, or structural grouping. Even when they are nested they remain structural markup…However, TABLEs imply a relationship between column and/or row headers, and the data in the TABLE cells. When we use them for layout, we lose the structural semantics of a TABLE. And we are back to using HTML for layout. Nesting TABLEs only compounds the problem.”
I don’t deny though that CSS div tags are a lot harder to implement for layout purposes than HTML tables. You’ll need to bury your head in a good CSS book by a true master such as Eric Meyer in order to understand CSS positioning. So in terms of simplicity and amount of effort required, table designs still reign supreme. However, that is the short term.
In the medium term, what about maintenance of the design? When you need to update it, you’ll need to meddle with tables. I know from experience that having to fuss around with a bunch of table cells in order to re-jig a design layout, is more hassle than simply modifying a couple of lines in a CSS file. Personally I also find CSS div tags a lot easier on the eye than a great jumble of HTML table, TR and TD tags.
And in the long term, CSS table-less designs make sense because they convey semantic information about the structure of your site. I don’t think we fully understand yet how important semantics will be in 5-10 years time on the Web. But we do know that our web sites will be deployed on a number of devices or appliances – big and small. Having a semantically-structured design allows your site to be rendered more easily in any type of device, because div tags can convey a logical order that table cells can’t.
I don’t claim to be an expert on XHTML and CSS – people like Zeldman and Mark Pilgrim know much more than me about these things. But I’m a curious type and I like to experiment with new web technologies. Hence my gung-ho implementation of CSS and XHTML into my Radio Userland weblog. Incidentally, I didn’t find many other people who have table-less CSS Radio designs. Joe Gregorio was the only one I found with a CSS design – does anyone know of any others? In my blogging neighbourhood, I noticed Danny Ayers has recently done a CSS design but he doesn’t use Radio. I’ll gladly write up some notes about my experiences if there’s any demand for it from Radio users. My next step will be to design my own original CSS design – and yes I’ll be using a table-less design again. I probably won’t tackle this for a while, but I’m always looking to the future 😉
