XHTML and CSS — Don’t give up
I recently came across a site entitled “give up and use tables”, arguing that if it takes you longer than 47 minutes to produce a design with CSS then you should throw in the towel and build it using tables instead.
And recently Jeff Atwood posted that he didn’t think HTML validation was important, saying “Nobody cares if your HTML is valid. Except you. If you want to.”. We’re not talking about XHTML validation here, either, just plain old HTML.
I am strongly opposed to both arguments. So why do our opinions differ so much?
In the late 90s I built all my websites with tables, liberally combining <table>, <img> and <font>. My goal was to get the site to “look right”, and once the web page matched the design in my head or in my sketches then I would stop.
There are some serious (and well-documented) problems with this way of designing, and with this goal; table-based design means embedding style information within the HTML, making it big, brittle and difficult to understand; designing websites so that they “look right” fails to take issues like accessibility into consideration, or that some people might not be viewing the site using the same means as you.
The W3C provided solutions to both of these problems: CSS and XHTML. CSS allows designers to remove presentation from content by putting style rules in a .css file, removing the need for embedded styles and reducing both filesizes and complexity. XHTML (being an HTML-like subset of XML) makes web pages very easy for programs to parse, meaning that screen readers or other software can more easily process a page.
These technologies might sound great, but it’s not always easy to make use of them.
While CSS solves the problems of embedded styles and complex markup, table-based design offers designers a lot more control than CSS does. Some people feel this loss of control comes at too high a price, and use tables to get what they want rather than rethink their design.
XHTML makes web pages more parse-able and more accessible, but it can sometimes feel like there’s no incentive to avoid malformed XHTML since browsers are so lenient that even serious validation errors make little difference to the way that a web page is displayed. Some people think that trying to produce valid XHTML is a fruitless exercise, and that what the browser displays is all that really matters.
Personally I value concise and valid XHTML, with my style information cleanly separated from my content using CSS.
If you value these things too then don’t give up: do it right.
Yeah, I agree. I prefer XHTML over HTML for the same reasons. The XML base just makes the code a lot better.. But actually I don’t see using XHTML as a reason to not use tables - Of course not to make the layout, but to use it where tables should be, semantically, used. I just can’t understand when people go using div-only and then creating tables with display: table-cell; or something like that.. That doesn’t solve anything in my opinion.
Did you read what new “features” HTML5 will bring with? About all those semantical tags? I don’t really think that is an improvement, so I really hope, that browsers will accept real XHTML (application/xhtml+xml) soon.. But they won’t support all new HTML5 features that soon anyway.. *sigh* Web technologies are spreading far too slow..
pokeon Tuesday, 17th March 2009 at 01:18
Hi poke
You’re right, there’s nothing wrong with using tables in the right places. Those people who use
<div>to display tabular information are just as wrong as those who use<table>to control layout.I hadn’t heard about the new features of HTML 5, I found the preview of HTML 5 on A List Apart quite helpful.
I can see where the W3C are coming from here, even in XHTML saying that something is a “div” gives very little meaning as to what it actually is, but I think I prefer the idea of having fewer generic elements (div, span) to having many specific elements (article, section, aside).
Perhaps an alternative to HTML 5’s approach could be to assign a custom tag to a valid XHTML element, such as ‘
<aside> := <div id="aside">‘…I don’t know, I’m just thinking out loud! Maybe we will discover that any sufficiently complicated markup language contains an ad-hoc, informally-specified, bug-ridden implementation of HAML.
baxteron Tuesday, 17th March 2009 at 15:00
I really don’t mind semantic tags at all. I think it would be great to have custom tags that explain the semantics more. But in most cases it just won’t work. As soon as you put in a more complicated visual design, one tag will not suffice. For example I’m working on a website atm where I have to nest three divs inside another before I can add the content just to make the design appear correct. In a semantic-only resolution this won’t work. Of course, CSS3 will help there a lot, but depending on the layout you will still need semantically unneeded tags.
And as XHTML is based on XML, there should be a method to extend the standard doctype to add semantic tags; but the problem is - of course - the browser. As long as doctypes are just identified and not read, and the browser’s rendering result is based on internal settings and not the description of the doctype, this won’t work.
Btw. an interesting article about HTML5 is also http://www.alistapart.com/articles/semanticsinhtml5
pokeon Wednesday, 18th March 2009 at 16:37
I can’t really comment on any of the other Acronyms in this post however it’s taken me weeks to get my head around CSS, through trial and error.
My next web site could take a week, then 3 days, then a day then 50 minutes then half an hour! Does that mean I should have stopped at the first hurdle?
Freshon Monday, 23rd March 2009 at 23:32
I’d also like to add that this is from editing a blank word press theme!
Freshon Monday, 23rd March 2009 at 23:41