Transitional Layouts in (X)HTML and CSS: An Interview with Eric A. Meyer

We’re big fans of Eric Meyer’s books on cascading style sheets, in particular Eric Meyer on CSS and the O’Reilly book, Cascading Style Sheets, The Definitive Guide. We were excited when we got a chance to sit down with Eric to talk about his work and thoughts.

UIE: In your full-day seminar at our last conference, you and Molly Holzschlag went over a redesign using XHTML/CSS of our Conference Site.

Eric: Don’t forget we’ll be doing the same basic makeover at the upcoming conference, with some tweaks and refinements to make it even more fun and useful than last time!

We were very impressed. However, for several reasons, we have not made all of your recommended changes. One reason is that we have a significant number of users who still use older versions of Netscape. In addition, we felt that the design is relatively successful and doesn’t warrant big changes. What do you say to companies who see the need for redesigning for the latest recommendations, but aren’t quite there yet—in terms of implementation?

My point of view is companies should push forward to this kind of design as much as is reasonable. What’s reasonable will be different for every site, though. It generally comes down to weighing each approach’s costs and benefits for a given situation.

For example, let’s assume HugeCorp has a Web site where every page has 30KB of markup devoted to presentation—font tags, tables, and the like. (That’s a reasonable number, by the way.) Now let’s also say they get a million page views each day. That’s thirty gigabytes of bandwidth they’re wasting every day, or about a terabyte every month. There’s also the extra server load in sending out the extra data, which leads to slower server response times, and also slower rendering times in browsers.

So is it worth it? That’s up to HugeCorp to decide.

Obviously, though, most Web sites don’t “look good” in the oldest browsers, such as Mosaic 1.0, which didn’t even support tables. Nobody I know would think that a problem. Why not? Most people would say it’s because nobody uses that browser any more.

Actually, I can guarantee there are at least five people out there who are using it, so what we really mean is not enough people use that browser to make it a concern. So there’s always a floor to our thinking. Figuring out that floor for each site helps figure out how much catering you have to do for older browsers.

However, there’s a difference between catering to old browsers and accommodating them. For many sites, the concept of “transitional layout,” which blends simple tables and CSS, may be the answer.

Speaking of a transitional layout, in the first chapter of your book Eric Meyer on CSS, you go through a deconstruction/reconstruction of a page so that it only uses one main table for layout. This was our model for reworking the uie.com site. Is this a best practice approach to migrating to standards?

It seems like a very good approach to me, although I hesitate to call it a “best practice”—again, what’s best for one site may not be for another. I’ve seen it work on major media sites, like Fox Searchlight, which Jeffrey Zeldman and Hillman Curtis did. They laid out the site using a simple table to block out the pieces of the design, and then straightforward CSS to style the content within the table.

Jeffrey has told me that the Fox executives (and even Hillman himself) were amazed at how quickly the pages rendered in browsers. What was the magic? Simple, structural markup. The less you throw at a browser, the less time it will take to render.

People are calling this approach “transitional layout,” in part because it is a good strategy for migrating to a standards-based site, and in part because the pages are typically done in either HTML 4.01 Transitional or XHTML 1.x Transitional.

So is there any room for table-based layouts anymore? Big sites, such as Amazon, CNN, and Netscape, still use them. Do you think these sites have decided to stick with them or that they do not have the resources to change such a big site?

There’s room for anything the markup language will permit you. Tables are not evil, and never were. The real problem with table-based layouts is the same as it always was: the markup is bloated, complicated, slow, and just generally wasteful.

This was true from the moment David Siegel showed us how to nest tables and spacer GIFs to produce compelling layout, but at the time we didn’t have another option. Now we do. The challenge is in breaking the old habits, and learning a better way to do things.

In your recent interview with Douglas Bowman of Wired News, you two talked about the benefits/drawbacks of Wired moving to a standards-based website. Douglas mentioned the fact that up to 15% of Wired’s readers wouldn’t see a properly rendered page with the new redesign. This was an issue at UIE when we talked about redesigning our site. Is this on everyone’s mind?

Amazon is actually a good example of this. Amazon has obviously put a lot of money into building a brand, and in selling to as many people as possible. Therefore, they have a stake in making their site as usable as possible in as many browsers as possible.

The usual breakdown in thinking comes when we think “usable” means “looks exactly the same.” That’s the hurdle most people have to overcome. To me, “usable” means “the content is readable and easily understood.” The page can look a little less sophisticated in a six-year-old browser—that doesn’t strike me as a tragedy.

So maybe Amazon could trim down their markup, accept some variance between browser display, and save themselves a bunch of money. All they have to do is break out of the grip of “must look the same” mania.

Looking the same really was never possible, and will never be possible. Does Amazon look the same in IE6 as it does on a cell phone? Of course not. Therefore, we’re already in a situation where different browsers present the site differently. The next step is to embrace that, and work with it to derive maximum benefit for your site.

So is it worth it to Amazon to give up a little of the illusion of consistency in exchange for saving some money? That’s for them to decide. Doing a revenue analysis by browser would help immensely in making those decisions.

Wired is a good example of a group who thought it was worth it. I do think Wired took a relatively extreme step in its all-or-nothing approach to styling the site, but it was breathtaking for its sheer nerve and forward-thinking approach.

I think designers have this idea that standards-based layout is an all-or-nothing deal. I think you can always evolve your site toward the goal of more structural markup and CSS presentation without leaping all the way to the end.

It’s harder these days to forecast the evolution of CSS for two reasons. One, CSS is getting really big. Two, it’s been split up into a bunch of separate modules, each of which progresses at its own pace. So there isn’t one big Working Draft of CSS3 to look at and say, “Here’s what’s next.”

I think the excitement is in browsers continuing to advance their support for CSS2, and continuing to become increasingly alike in how they treat the same markup and styles. Even beyond that, though, I’m excited by how many designers are moving to CSS-driven design, and discovering all its benefits. Increasingly, I see comments online to the effect of, “I finally got into using CSS and it’s is so awesome that I’m never going back to tables. I can’t figure out why I ever put up with that kind of designing in the first place.”

So I think that if you haven’t taken the plunge yet, you can get excited about is how much easier your life will be once you’ve moved away from convoluted table design. If you’ve already taken that step, then it’s time to get excited about how much more you’re going to be able to do as you learn the nuances of CSS, and as browsers improve their CSS support even further.

You Might Also Like

• The Best Interview Question for Hiring UX Designers by Jared M. Spool What if you could ask one question during an interview that would tell you everything you need to know about the candidate you’re thinking of hiring? As I’ve mentioned before,…
• Interview-Based Tasks: Learning from Leonardo DiCaprio by Jared M. Spool In interview-based tasks, the participants interests are discovered, not assigned. Because each task is drawn from the experience and interest of each participant, no two participants perform exactly the same…