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
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.
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.