Welcome to my fun emporium!

Welcome to the new design of Taskboy!

Over the years, I’ve changed the layout on this site a few times. On the great constraints on my choice of layouts is that I’m no graphic artist. I cannot product graphics that look reasonable for love or money. What I can do is try to make smart organizational choices and bring a minimalist sensability to the layout.

This redesign taught me a lot about XHTML, a standard I’ve pretty much ignored until now. Proponents of XHTML will tell you that there is freedom in the constraints it imposes. I do know that I gave up some functionality that seemed to be fine for 4 versions of HTML just to obtain XHTML validation.

As I’ve mentioned, I’ve lately woken up to the idea of unobtrustive javascript/CSS design. CSS 2 is so widely supported now that it is time to put the old TABLE tag in semi-retirement. The fact that I was able to re-architect The Feed Bag using only DIVs is no small victory. (Note to self: perhaps each row should be a UL?).

However, before I sing the praises of XHTML further, let me chime in very late on the quirks I encountered. These annoyances were so pronounced that my wife complained that I was getting too cranky. I’m an old man.

This list is neither complete nor exhaustive, but represents the pain points as I remember them.

Item 1: XHTML docs do not look like XML docs

The target of this rant is really the way modern browsers work and can be summed up in two words: Quirks mode. To maintain “backward compatibility” with existing (crappy) web sites, some browsers have a mode of reacting to HTML in way that isn’t compliant with standards. While this may not sound like such a bad thing, there are times when quirks mode kicks in unexpectedly.

For instance, all XHTML docs are XML docs. All XML docs are supposed to start with the declaration “<?xml version=”1.0”?>”. Now, this declaration isn’t actually required, but nearly all XML docs have it nonetheless. If you start your XHTML doc with this declaration, IE 6 goes into quirks mode. That’s pretty maddening. The way to get standards complaint behavior out of it to start your XHTML this way:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

This isn’t the end of the world, but it is a pretty good “gotcha” for beginning XHTMLers.

Item 2: Nested lists don’t

In caveman HTML, the following code reliably produced nested lists:

<ul>
  <li>Item1
`  <ul>
    <li>Item 1a
    <li>Item 1b
  </ul>
  <li>Item 2

That’s not going to work in XHTML. Instead, you must start the inner list with a list item:

<ul>
  <li>Item1</li>
  <li><ul>
    <li>Item 1a</li>
    <li>Item 1b</li>
  </ul></li>
  <li>Item 2</li>

Again, it’s not the end of the world, but it is surprising behavior.

Item 3: Centering anything

In old HTML, nearly any “block display” item could be centered using the attribute “align” and setting it to “center”. What could be easier? Well, XHTML is having none of that. Firstly, the “align” attribute has been removed. This means that positioning must be done through CSS. CSS centers text and block elements very differently. Text can be centered using the CSS attribute “text-align”. Block elements require magic like “left: auto; right: auto.” Again, it sort of makes sense once you’re use to it, but come on…

Item 4: ALT is required

There are lots of good reasons to put an ALT attribute on image tags, but please don’t force me to add ‘alt=”“’ every where. Not all images are that important.

Item 5: INPUT needs cuddle time

In XHTML, INPUT tags need to be in block elements like P or DIV. That’s pretty lame, but I understand why this is.

For web browsers to display a web page, they must parse the HTML. This is act of figuring out what parts of the document are content and which are instructions. The instructions (HTML tags) are assembled into a tree structure according to the Document Object Model. Because of HTML’s SGML roots, the browser often inserts “assumed” nodes into the tree to make sense of the given HTML. For example, if just a naked line of text is found after the BODY tag, that text is wrapped in a P node. Some of the guess work the browser needs to do for HTML isn’t at all obvious or predictable. It is the reduction of these assumptions that is the raison d’etre of XHTML, by the way.

Anyway, INPUT tags used to be able to hang out by their lonesome but not anymore.

In conclusion, I’m happy I took the time to make the transition to XHTML but there was pain along the way.

Published by Joe Johnston on .