text-transform:

My friend Jeremy, a stellar screenwriter/game designer, decided he needed a professional Web site, and so asked our friend Angi Shearstone to do the design, because she’s a terrific artist who has done some beautiful work with professional sites. Jeremy’s site worked fine on his local machine and on Angi’s server, but when he uploaded it to his server, it broke all over the place, so he asked me if I could take a look.

The problem turned out to be some sort of CR/LF issue, where the uploaded files were getting their end-of-line characters stripped, presumably due to a configuration with his client. As a result, the whole page ended up all one line… meaning that everything after the first // in the script got treated as one giant comment. Result: JavaScript errors all over the place.

But I told Jeremy that I was professionally obligated to fix not just the particular problem, but to rework all the code for his site. You see, I’d looked at the source.

Angi admits she’s not a developer, and so uses Dreamweaver. I can hardly fault her for that. Dreamweaver is a tool aimed at, and marketed to, people like her, and so I don’t hold her at fault one bit. However, one peek under the hood and I wanted to drive out to Adobe’s offices with a crowbar. The resulting code looked pretty good… if it were 1998.

(To be fair, I don’t know which version of Dreamweaver Angi is using, but I feel pretty confident she’s not using a copy from the mid-Clinton administration, because the page was using an XHTML DTD.)

Tables for layout? You bet. Paragraph tags with nothing in them but a non-breaking space? Of course. Lots of whitespace in the images instead of neatly-trimmed images with CSS margin or padding? Uh-huh.

…but every single link with an href of “#”? Good God. Yes, every single link relied on its onclick handler to shift the user to the next page. (Needless to say, with most of the JavaScript inadvertently commented out, this caused quite a few problems.)

I know I’m a code snob, with high standards about, well, standards. I also recognize that an automated tool is going to have limitations and can’t do things as cleanly as a human. But this episode really served to demonstrate the value of semantic code and of MVC separation. By changing the headings to actual heading tags like H1 and H2, and by moving the layout into an external .css file, the resulting HTML was tiny… and very human-readable. And that was some pretty big added value for Jeremy, who will have to maintain these pages going forward; he’d have had a lot more trouble trying to deconstruct and reconstruct Dreamweaver’s piles of glop. By moving the complicated, heavy-geek part (the CSS) into an external file, the resulting HTML was small, lean, and manageable.

Look for yourself. Note: as of right now, we still haven’t solved the CR/LF issue. Also note: since Jeremy needed the site up and running before a conference this week, what you’re seeing is not the finished product, but rather what I could deliver to him in time. I still need to add more SEO, address accessibility issues, and get it to format nicely on an iPhone. But as a first cut, from only a couple hours’ worth of work, it’s a big improvement over the bad dream that came from Dreamweaver.

I aim to code up my HTML semantically. There are a number of reasons to do so:

• It’s part of good MVC separation, which is always a win when you reach the inevitable re-design of how the site looks;
• It’s better for search engine optimization;
• It makes your page more forwards-compatible, since Web devices that haven’t yet been invented will reliably display your page with some semblance of accuracy;
• It’s simply the Right Thing to do.

For similar reasons, my workplace espouses unobtrusive JavaScript, again for good MVC reasons.

All of this came to mind when I recently built a new FAQ page for work. There’s nothing about this page that’s particularly revolutionary or awe-inspiring, but it did occur to me that this was a great example of how my own coding principles have improved over time.

Take a look at the page. The designers wanted a list of questions, each a clickable link, with an arrowhead next to each question. Click on a question and the answer would “pop open” below, with the arrowhead now pointing downward to indicate the “open” state. Click the question again and it closes.

Here’s how I would have done this five years ago: each question and answer would be a <div>, with ids with similar names, e.g. question2 and answer2. The questions would have hyperlinks in them, with an inline onclick handler like
<a href="#" onclick="javascript:toggleAnswer('2');">
That handler would take the argument and append it to the word “question” or “answer”, then use that result as the document ID to set style.display to "display" or "none". It would also change the src on the arrowhead image.

Yuck.

Instead, I did it the right way. First off, I recognized that this FAQ is a bullet list, so I coded it as a <ul>, using CSS to hide the standard bullets and instead use the arrowhead image. Each list entry has two elements inside it, with classes “q” and “a”; by default, “a” is hidden with display:none. Class “q” has CSS to make it blue and underlined so that it looks like a hyperlink. (Since it’s not actually a link, just a clickable element, I avoid the <a> tag here.)

Then I made a CSS class, li.open. That class uses the other arrowhead instead, and furthermore has
li.open .a {display:block}
Now we have a class that, when set on a list entry, puts it into its “open” state, with the proper arrowhead and with the answer visible.

Finally, we add the click handlers dynamically, using a JS library (in our case, Prototype). We take each element with class “q” in the list, and add a click handler that sets or removes class “open” as appropriate:

$$('#faqs .q').each(function(s) {
s.observe('click', function() {
this.parentNode.className = (this.parentNode.className=="open") ? "" : "open";
});
});

And that’s it. Clean HTML, CSS to handle the visuals, dynamically-added handlers to keep M, V and C separate. It’s a thing of beauty, baby.