An experiment with xhtml strict
I met with a company recently about doing some work for them. During the meeting one of the UI developers let me know that they were using xhtml in strict mode. Now I have to admit it has been a while since I looked at xhtml and I’ve never actually done anything with the strict variant before. So I got a little curious and decided to spend some time and see what it was all about.
I pulled up the xhtml specification the next day and read through it. The name “xhtml strict” kinda hints at what you would expect to find and it does a pretty good job of living up to its name. It’s a very precise way of working with xhtml, it doesn’t allow you to “get away” with sloppiness, it requires that all attributes must be quoted, all tags must be well formed, and closed properly, attributes must be lowercase, you can’t have “name” attributes they are all id attributes and a bunch of other things like that. My initial impression was that this doesn’t seem that arduous, it’s simply a way of enforcing a convention upon a document. .
In order to see how it stands up in the “real world” I decided that I would update hamtesting.com to be xhtml 1.1 strict compliant just to see what sorts of things a developer could run into while working in this environment. Below are some of my thoughts about the process.
My initial efforts at getting all of the templates into shape went pretty quickly in about 45 minutes I was able to get all of the main site templates updated to be compliant. Things like updating the br’s and hr’s and adding /’s to input items on forms were all of the things that I expected. Also expected was that all attribute values need to be lowercased. So if you have an onclick defined for something in your page it can’t be onClick or ONCLICK or anything else, it needs to be onclick.
The first thing that kinda gave me pause for a bit was that it is really picky about which elements can be just below the root element in a document. This ends up not being an issue and actually leads to a lot more consistence in the document structure. It was a little bit of a pain at first but it quickly got into shape. The specification does spent a certain amount of time talking about which elements can contain other elements and such things, so it’s probably good to have that floating around in your head. Or use a validator plugin ( see below )
The second thing that was a little difficult was that I had used the name attribute in a lot of places for some of my javascript interactions. So first I made everything xhtml compliant by switching things from name attributes to id attributes, with this done the site didn’t work terribly well. So I updated one javascript routine in my main library and then whammo everything was working well again.
With this all done I spent a bit of time and knocked the css document into shape and got it validated as well. So now when you go to www.hamtesting.com you will see badges from w3c for the site being both xhtml compliant and css compliant. Kinda fun.
Probably the biggest lesson learned was that while the w3c’s online validator services are fine for a page or two they can be a pain after a while, especially if you are trying to validate pages that are in an authenticated area of your site. Do yourself a favor and go get a html/sgml/xhtml validator plugin for firefox so that you can just pull up the errors as you run across them.
In the end, this wasn’t as difficult as I thought it was going to be. My impressions are that xhtml is kinda nice, and using the strict variant definitely enforces a certain amount of discipline into your efforts. It’s a good exercise if you have some spare cycles and want to dig in a little.