Eric A. Meyer is a recognized expert in the area of Web Design and Cascading Style Sheets. He has been working with the Web since late 1993. Eric coordinated the authoring and creation of the W3C's CSS Test Suite and has recently been pushing the limits of CSS-based design.

He is author of several books including, Cascading Style Sheets: The Definitive Guide 2nd Edition (O'Reilly & Associates) and More Eric Meyer on CSS. Recently, New City Media's David Poteet got a chance to chat with Eric about his work.

David Poteet: You cite a growing number of major corporations such as Microsoft, Chevy, and Disney Store UK redesigning their sites based on web standards. From a business standpoint, what do you think is driving the growing interest?

Eric Meyer: I'm seeing a growing interest in standards-oriented design as something that should be done by any organization. Various redesigns have certainly helped awareness. As many organizations make the shift to standards, others are starting to realize that they're being left behind and that they need to look into standards-oriented design and figure out how to move forward.

The driving forces are interesting and diverse. In many cases, you'll have a web team that has come to realize this is something they need to do. They won't get management onboard by saying "Hey, we need to move to standards," but by saying, "Hey, a standards-based design can make our site more efficient. It'll be faster and more accessible." Development teams can promote their cause by stating all the reasons that standards-oriented design benefits the organization as a whole.

For one of my clients, the legal team was the driving force towards standards. The legal team came to the technical team and told them, "Our web site must be accessible." This was not a business where they were federally mandated to be 508 compliant, but they were just coming from an ADA lawsuit.

It seems like development teams are learning to talk about standards in a new way, to better communicate the need to corporate leadership?

Standards-oriented design meets the first two questions that CEOs ask themselves: "How can I increase profits?", and "How can I reduce expenses?" I can answer those two questions, assuming it's a company where income is derived from the web site.

A good example is Multimap UK. Richard Rutter, who writes the blog clagnut, worked on a standards-oriented redesign with Multimap. Right after the launch, Richard wasn't exactly sure how much the redesign would save Multimap every month in terms of bandwidth, but he was confident that the savings would pay for the cost of redesigning within a month.

Then, Richard came out a couple months later and he said, "Well, it turns out that wasn't true, but here's why. We actually had an increase in traffic. We had more users because the site was more responsive." And since they actually derive profit from ad displays, they saw a smaller decrease in expenses than expected due to higher traffic, but a much larger increase in profits than expected.

Regardless, the argument that it was going to pay for itself in a short period of time was still met?

Right, just not along quite the same axis as expected. Multimap UK increased revenue while decreasing resource expenditures.

Those are generally the two questions that CEOs ask themselves. Standards-oriented design typically can satisfy both of those and some of the others as well.

I've spoken with several developers from large organizations who understand the benefit of migrating to standards, but they have too many other priorities they need to accomplish. For example, one developer told me he has so many systems that are already built and he just can't justify going back and revising them. How would you respond to this objection?

It depends on the organization. If you're an online library, then you have millions of entries and you're not going to want to try to convert all those millions of entries all at once. For large organizations with a lot of material already online, I recommend they phase in the new stuff. Then, after gaining experience, they can go back and convert the old stuff if necessary.

Maybe at some point you say, "Look, the old stuff is the old stuff and that's how it is and we're just going to leave it that way for now." There's always a risk of course that it will stop working in five or ten years, but you can't expect most organizations to think about possibilities five or 10 years from now.

When you build a site with web standards, is it all-or-nothing or are there degrees of compliance?

Yes, I think in a lot of cases it's a question of standards-oriented design. I use the term standards-oriented design because in a lot of people's minds, standards design has become associated with the idea that developers can never use tables again. To me, standards-oriented design means going in the direction of adhering to standards, not trying to cut your throat on the bleeding edge of technology.

For example, you might decide to use very simple three cell table to create a three column page layout, and then use CSS to style the content inside those cells. That's standards-oriented. It's not pure standards design, but I don't care about pure standards design. If I can get development teams to the point where they are 80% of the way there, they'll see many advantages and they'll be in a much better position to move forward in the future. That's why I say "standards-oriented design" as opposed to "standards-based design."

Which brings up an even more basic question. How do you define "standards?" To the uninformed what does that really mean?

For me, standards-oriented design involves:

Using HTML or XHTML with semantic structures, simple structures where the markup to content ratio is actually less than one.

Based on the W3C Document Object Model and not on the proprietary DOMs like those that were built in Netscape 4 and Internet Explorer for Windows

Anything dynamic is driven through what's now called ECMAScript (formerly JavaScript)

The standards effectively become best practices, not rigid standards.

Can you explain what you mean by a low markup to content ratio?

Using standards-oriented design makes it easier to have less markup than displayed content. With a table-and-spacer type design, this is not the case. You could have twice as much markup as you do text content, or three times as much or five times as much, depending on how complicated the markup is. With standards-oriented design, developers want to get that below one to one.

And why is that important?

Because it's tremendously inefficient to do it any other way.

Because of bandwidth consumption?

The bandwidth transfer is something of an argument, although I think it's really only an argument if you're an organization like Microsoft that has several hundred million visitors a day or if you're ESPN.com that gets an average of 40 million page views a day. Then you're talking about actually reducing the bandwidth bill and saving money.

For most developers, they aren't getting close to a bandwidth ceiling with their provider.But someone like eBay, I can't even imagine.

I've heard that the markup to content ratio for eBay is just heinous, like 85% markup or so?

They've got to do millions upon millions upon millions probably an hour if not a day. And a typical auction page -- just the HTML document -- is somewhere in the vicinity of 40-45KB. It's all built with font tags, tables and spacer gifs.

I've done standards-oriented re-creations of those pages, where, without changing the design, I cut the markup down as much as possible and using style sheets for display. I can go from about a 40KB page to a 20KB page.

So you could reasonably argue that eBay could be reducing its bandwidth consumption by half?

Roughly. There are definitely dollars to be saved – and given it's eBay, that's huge dollars. But the flip side of that, it's not just the bandwidth.

What are the better arguments?

For eBay I would think the bandwidth is a pretty powerful argument. More importantly, the number one factor in page response time for all sites, including eBay, is the number of bytes shifted to the user, regardless of their connection speed. It doesn't matter if it's dial up or broadband -- the time from the page request going out from the user to the page actually being rendered in their browser is almost completely dependent on just how many bytes you send over the wire.

If developers can take their web page and make it half as weighty, it will be twice as fast for the user. If it took users five seconds to get the page, it will now only take two and a half seconds.

I'm speaking in rough terms, but that's really what it comes down to. Things like whether you use CSS for layout or whether you use a table for layout, makes almost no difference in terms of page rendering time. Where the difference comes in is that by using the standards-oriented approach instead of table-driven markup, the page weights are about half. It's not that standards-oriented design has this magic property that makes the bytes go over the wire faster. It just leads to fewer bytes going over the wire, which makes the page faster.

In the case of eBay, their users really want that information right away when they're watching an auction. It's just reload, reload, reload.

And I'll attest to that. The frustration of waiting for pages to build on eBay is almost to the point where users may be ready to throw their computers down.

Exactly -- the faster this gets done, the more actual users can be served per server.

Instead of a thousand servers in a co-location farm, you can have maybe 750. I suspect that it's not as simple as reducing your page size leading to reducing your number of servers by the same amount. But fewer servers means less electricity and space and bandwidth consumed at the server farm. I get the impression that eBay could save themselves a very large chunk of money by doing this.

I hate to feel like we're leaning on eBay here, but they're sort of the edge case, the example of what happens if you take this argument to its logical conclusion. They spend millions of dollars a year on servers, support, and bandwidth. Just for the sake of argument, let's assume for the moment that eBay decided to go completely standards based. And eBay decides not to waste any server resources on browser detection to deliver a different version of the site to users with older browsers that don't support web standards. What would happen?

Users with browsers like Netscape 4 or Internet Explorer 3 would not see any of the CSS styles applied to the content. However, this would not limit their ability to participate in auctions. It wouldn't limit their ability to sell stuff and buy stuff and let eBay get its percentage. In fact, some users in that group may find that preferable because instead of the servers and their computer wasting time trying to figure out all this markup, they're getting their pages faster.

What would happen if we asked a really hardcore eBay user, "What would you say if I had a product that made the page less pretty but made it respond twice as fast as what you're getting now?"

They'd say "Sign me up."

Yeah, they'd say, "Here's my $39.95 a month."

So the question is, would the benefits of moving eBay and its users to a standards-based site outweigh the drawback of people with Netscape 4 not getting any pretty eBay stuff?