CSS is a very tough sell.
I’ve been doing a lot of thinking about CSS these past few days because I’ve just rebuilt this entire site to use proper, modern HTML and good CSS. Over the years I’ve built lots of web sites. Back in the dark ages of web site design, “cool” was getting Small caps by playing around with FONT tags. Anyone could make a web site using basic HTML, but it required perseverance to learn the little tricks and browser bug–workarounds involved in making web sites actually work in more than one browser.
Idealism Falters
The original idea behind HTML (roughly) was that a document would be simply marked up according to what the various pieces meant, and the web browser would choose the exact display format. HTML documents were essentially envisioned as scientific data or papers or similar things, where the exact presentation wasn’t really important; the important part was the actual text, and as long as that was preserved, it didn’t really matter how it looked. Perhaps the idea was for browser vendors to compete on how pretty they could make simple web documents look.
That lasted maybe five minutes.
The problem here is the disconnect between what the web was intended to be and what it actually became. The web was instantly accessible, instantly publishable. Hordes of people put material onto the web every day, all with different goals. Especially early on, a lot of the material on the web was marketing-driven, created by designers with a deep desire to control the exact look of a company’s promotional materials and branding. When I say “deep desire,” I mean “burning passion.” Browser makers (Microsoft and Netscape, chiefly) didn’t compete on how nicely their browsers rendered plain-vanilla HTML; instead they competed on extra features that let designers do more and more to precisely control how web pages looked. The original spirit of the semantic web—of a vast sea of purified information, ready to be transformed however the end-user needed it—was lost, as complex markup obscured text, serving only to control presentation.
The pinnacle of this madness is table-driven layout. Build a page consisting of a huge table, and partition up the page into rectangles, filling each with whatever is necessary to make that little piece of the layout work. I have built lots of sites this way, as for years it was the only consistent, reliable way to position elements in a web page exactly where the designer intended them to go. I have even written scripts to do this kind of layout automatically, given a list of elements to lay out. My co-workers used to call me “table god” because, whenever they had trouble with their table layouts getting out of whack, I could fix them.
Constantly Changing
At the same time that “web design” was gravitating towards pixel-precise control, web sites were shifting from collections of static documents to dynamic, data-driven sites that remembered things from page to page. The proliferation of shopping carts, personalized sites, web-based email, and so on show the power of this approach; the web as we know it today depends on it. But such sites present real challenges in a table-based HTML page.
A data-driven site looks at a page request, combines it with data from a database, makes some intelligent decisions, and builds a page. Instead of a document being requested from a collection of static documents, the request triggers a program that pulls in the appropriate pieces. Traditionally, that program will need bits and pieces of HTML to assemble them into a complete web page, and those bits and pieces are embedded directly into the program.
It is this embedding of program code and output HTML that is, in fact, the problem. Updating the HTML now requires modifying a program, sometimes in non-trivial ways. (For those of you who are wondering why a perfectly good and working site would be modified, let me just assure you that clients often want to change things.) Even aside from ordinary updates, many times the same program can be used for different web sites, which can have radically different layouts; certainly the program can be modified, but now there are two incompatible copies of the program—and programs are updated or patched as often as web sites change. With two (or a dozen!) copies, every change to the program has to be integrated into each copy separately, a process that is error-prone and tedious. I did not have to build many programs this way before I sought another solution.
The most obvious solution is to store the HTML outside of the program, and have the program fetch it and assemble the pieces on the fly. To re-use the program, only the external HTML files need to be modified; the program code is unaltered. The program can be updated independently from the content, too. I have used this approach in hundreds of web sites; I know it works. But it is not easy. It requires care in constructing the templating mechanism, and some languages (ColdFusion, for example) almost discourage this kind of setup in their very design.
CSS to the Rescue
The answer to these problems was supposed to be CSS. The basic premise is to return HTML to its semantic ideal—use the markup to indicate what the document means, and then use a style sheet to indicate how the document should look.
Of course this is wonderful in theory, but in practice it turned out to be iffy at best. The first version of CSS didn’t offer too much in the way of capabilities beyond current table-slicing methods, and it was poorly supported in common browsers. In the early days of the web, odd quirks of browsers required special HTML coding to accomodate various incompatibilities; such things were tame in comparison to the gross inadequacies of early CSS support. (Netscape 4 was a particularly sorry implementation.) In short, CSS1 was a miserable failure, so web developers kept right on building table-sliced pages and squeezing dynamic content into them.
Thankfully it didn’t stay that way. CSS2 is a lot more flexible, browser support for it is better, and Netscape 4 is no longer a popular browser. The web can, finally, realize the promise of CSS. As building web sites with CSS becomes more popular, HTML will become simpler. (The HTML for this site became far easier to maintain once the layout had been abstracted into the CSS.) Building scripts becomes easier too. And both CSS and HTML files occupy less space, use less bandwidth, and have more flexibility. Designers can set different styles for printing web pages, for example, hiding elements that are irrelevant and selecting appropriate font sizes.
The Unhappy Few
Sadly, not everyone is happy, because CSS is still a hard sell. While I think CSS is wonderful (and beats using many of the tools I’ve built and used in the past) it is not easy to learn to use effectively. Table slice-and-dice may look ugly, but an entire generation of web site builders are thoroughly familiar with it. I had a conversation with one of them over the weekend, when I told him I was converting my existing table-based site to CSS. I asked him why he wasn’t a fan of pure CSS; he indicated that it was more trouble to update a CSS site:
See I’m not a fan of the pure CSS sites. [It] makes updates and general maintenance a pain. We’ve done a few sites that way and they are the ones I hate working on when [the] client calls with updates, enhancements, etc. … I can make a table and format a page in two seconds, versus looking up styles or creating new ones, using guess and check, checking all browsers. … Tables don’t cause any problems if they’re done correctly, so why make my life more difficult to use pure CSS, when 9 [out of] 10 times the site is going to be very graphically driven.
I will not reveal the name of this friend in order to protect him. (smile) And while I could rebut each of his assertions one by one, that’s not why I’ve included it. Rather, it’s the viewpoint that is interesting and understandable. To learn to work with CSS requires going back and, at least partially, starting over in learning how to build web sites. My friend sees little point; he knows how to build web sites that work without relying on CSS, so for him it seems like a lot of work for very little gain. This is especially true for him, since his clients really don’t care about technical details—that’s why they hire my friend to do the work for them. Clients don’t care whether tables or CSS are used; they care about whether the site looks good and whether all visitors will see it correctly regardless of which browser they use.
The only way people like my friend will move to CSS and abandon their table-driven approach is when the benefits of such a move become obvious and the cost of maintaining tables outweighs the cost of switching. Sites like CSS Zen Garden show what’s possible with CSS without changing any HTML at all. But it will take his friends converting some dynamic sites and really showing him how much easier it can be before the majority of the dynamic web sites will really switch.
And that could take quite a while.
