LogicaCMG Merger Website View live site
In late 2002, with two years' experience under my belt and a long Christmas vacation already scheduled, I got a sickening surprise: our biggest client was merging with another company and needed a completely new site built. In the 30 days before the January 1 merger announcement. The job fell to me: our most senior web developer had recently been kicked upstairs to team leader, so he couldn't realistically commit himself full-time to the project, so goodbye Xmas Break.
In the shock of that meeting I did something that, looking back with the wisdom of age, was stupid. I happily accepted the project and timeline under one condition: I felt the site would need to be built as an all-CSS, no-tables site. Seems pretty obvious now, but at the time, there were no big corporate sites built in pure CSS. Sprint built one not long after we finished Logica, but when we started, it was green field to us. Literally: the only all-CSS site we'd built was an internal project I'd done a month or two before.
At the time, Pixel had something called "Management Business Objectives": you'd be assigned 5 research topics or projects to work on every 6 months and any one you completed was worth $500 (the MBOs ended soon after: between the downturn in the economy and the fact I'd collected every one I was assigned made them feel a lot more expensive than they had). One of my MBOs was to take an existing client site (picked by my good friend and team leader who made sure t pick the hardest one he could find) and rebuild it. The only concession was it did not have to work in Netscape 4 or IE4 on a Mac. Still painful, but I made it happen.
So when I was sitting in that meeting, my thought wasn't "Crap, this is our biggest client, don't want to screw this up." Oh no, not me. My two thoughts were
- They just screwed me out of my Christmas vacation
- It'd be a lot easier to re-skin the 200 or 300 or 500 pages (how many do they have, anyway?) if I do this in CSS instead of trying to replace one set of table markup with another
In the end, I was right that doing things in CSS meant it was possible to execute huge search & replaces across the existing code. The site was about 100-200 static pages and another few hundred generated by tools built in ASP, so no, there weren't a lot of shared includes in the existing codebase. This project was where we created a number of processes that streamlined our development process going forward. It made much better use of includes and shared templates, it was the first implementation of an all-CSS site and it was the first site to use the XML navigation code we'd recently developed. It also defined how we approached different browsers; given my perverse nature, as soon as I was permitted to ignore Netscape 4 and IE4 Mac, they stopped being burdens and became interesting challenges. So I tried to make the site work as well as possible in browsers that didn't have "full" CSS support.
Nowadays it's called "graceful degradation". At the time it was just one idiot showing up at 6am (after an hour commute! Ah, to be young) so he could fight with browsers. At its essence, our approach was to provide a baseline of CSS information to all browsers in a file called "base.css". Higher-level browsers were targeted by providing a file called "dom.css" in a syntax older browsers didn't understand. Looking back at that first CSS file I ever wrote in anger, it ain't pretty. I didn't understand inheritance (though I think some of that waterfall of CSS is due to the fact some browsers didn't understand inheritance or cascading any better than I did) and I was guilty of what Zeldman would come to term "classitis", creating lots of CSS classes when I could have just specified the selectors. The only reason I didn't come down with the twin disease of "DIV-itis" was because we didn't use the element much until we switched over to CSS full-time. DIV-itis would have to wait until we started using more HTML elements.
None of it was pretty behind the scenes, the heavyweight CSS, the metric ton of scripts we'd written to parse the codebase and reformat it with the new interface or the long hours and number of people involved in getting the site live, but I have a talent for focussing on what I could have done better. In the end, the site went live on the day it was supposed to without issue. To say it was a learning experience is under-selling the process. It packed a year's worth of development advancements into about 6 weeks and gave us a leg up on the competition for a long time.