The Web Design Holy War


Everyone on the CTC VISTA listserv probably noticed some extra e-mail today. Thanks for taking me into your inboxes, and thank you to Matt and Dina for some solid advice!

One of my ongoing projects is creating a website for the UMass Lowell Engineering Service-Learning Program, affectionately known as SLICE (Service-Learning Integrated throughout the College of Engineering). I've been working on the site sporadically for about six months, having done most of the work in February and March. Now that the school year has started, it's time to bring the site online. That means debugging.

It might have been easier if I had used a content-management system for the site, or at the least, used a pre-canned template for the site design. I'm one of these people who likes to do things himself, however, and sometimes I take this to a fault.

I decided to go whole-hog and code the entire site from scratch. Considering that the SLICE folks just wanted a new look for their existing site (which used frames rather poorly), all I had to do was create a template page and type in some text, right? Indeed.

For me, coding a site from scratch means using Cascading Style Sheets (CSS) for as much of the styling and layout as possible. I avoid using tables to position my pages. Here's why:

  • Using a single CSS file for layout makes changing pages go more quickly than using tables, inline attributes (e.g., <div align="">) and <font> tags.
  • CSS allows me to simply use a different stylesheet to create printer-friendly pages, screen-reader-friendly pages, and compact pages for handheld PCs and cell phones.
  • One 5k CSS file services an entire site, meaning that pages will load faster. For people with broadband connections, this isn't a big issue. For dial-up users, size and speed are tightly correlated.

The use of CSS instead of tables, <font> tags, and inline attributes, along with the use of descriptive "class" and "id" attributes, is commonly referred to as semantic markup, and is a hot-button issue with web designers. The logical conclusion of this would be to design pages using XML, so that you could have a tag called, for example, "<linkmenu>." We're not quite there yet.

The advantages of CSS-based design over traditional design are so persuasive that everyone would design pages this way, right? Not so. Every browser has its own way of interpreting both HTML and CSS, which makes for a trying experience sometimes. Thus people choose to use the traditional methods of web design, involving tables, <font> tags, and inline attributes. At the Grassroots Use of Technology Conference this past June, Ben DiMaggio referred to this difference in design philosophy as the "holy war" in web design.

Taking sides has its drawbacks. For the SLICE site, I wanted to create a simple two-column layout, with a banner across the top and copyright info across the bottom. The left column should be a fixed width so that people didn't have the navigation links resize whenever they resized their browser windows. The right column should allow for browser resizing, at least down to a reasonable amount (say 400-500 pixels) . A fixed-width navigation column next to a variable-width main column? Simple. Just use CSS's "float" attribute. Except that this doesn't work.

Internet Explorer 5 and 6 don't float things very well. If you decide to have a floating left column full of links, things get goofy if you specify any heights or widths in your right column. Woe unto those who like using background images: borders and background images don't play nicely when floated in Internet Explorer. There's a funny-looking "indent" if your right column is longer than your left column.

I tried and tried to solve this with the float attribute, but never with much luck. Either I had to create <div> containers upon <div> containers, which is just as bad, markup-wise, as using tables for layout, or I had to change my CSS. I chose the latter.

With the "position" attribute, CSS lets you position things exactly, down to the pixel. Since my left column was of a fixed width, I just decided to place the main body of the web page next to the links column. The strange indent bug was gone in Internet Explorer, but now Firefox was leaving a strange gap at the right of the page. Since IE still holds the lion's share of browser usage these days, I was happy. Since Mozilla-based browsers have a good 15% share of browser usage, my solution wasn't good enough. In came the listserv.

Matt and Dina graciously offered their help: Matt suggesting that I look at my Document Type Definition (DTD), and Dina offering some tricks with the float attribute that I hadn't thought of. Not quite the right track. Finally, after a few wrong turns, one extra attribute fixed things:

<code>right: 0;</code>

Ten bytes!!! All this work to change ten bytes! And really a fairly intuitive answer: if I specify the leftmost edge of my main column, I might as well specify the rightmost edge also. Most web designers know that a <div> tag expands to fill up the entire width of its containing element. Do they know about this particular exception? I hope so, but I sure didn't.

In addition to the "right: 0;" fix, today I learned about the "Holly Hack," a workaround for Internet Explorer to keep content from disappearing when a page is loaded. Fortunately, learning about this was a 30-minute "read and imitate" fix.

And there's still more to learn. Evidently the CSS specifications changed slightly between CSS 2.0 and CSS 2.1. And I'm still not up to date with Mac IE and Safari. My position often forces me to be a "John of all trades," so I sacrifice some depth of knowledge for breadth. Guess that means that in the web design "holy wars," I'd better not get too holy, because I don't know everything.