Interview With Eric Meyer

Eric Meyer is a Standards Evangelist for Netscape Communications: he

tries to spread the word about why standards are good and devise

standards-based solutions for Webmasters.

He is the author of three books and a large collection of articles.

Eric kindly accepted to answer some provoking questions concerning the role and the future of Cascading Style Sheets.

If you are Italian, you can read the translation: "Intervista con Eric Meyer".

You're delighting us with another book. What is the approach of this new manual — theoretical or practical? How did you choose your case studies? Is there a site related?

The new book ("Eric Meyer on CSS") is almost entirely practical in

nature. It's composed of 13 projects, each of which starts with a

simple document and styles it in increasingly complex ways. The text

is written so that users can follow along with the book and see the

project evolve for themselves. The base project files, as well as

the files that were used to produce all of the screenshots in the

book, are available from Eric Meyer on CSS.

I actually created all the projects from scratch, choosing each one

with an eye toward exploring some aspect of using CSS. For example,

two projects deal almost exclusively with positioning, one

concentrates on styling for print, another looks at form styling, the

first one examines converting a table-and-font design to use CSS for

its styling, and so on. The Web site has details on all 13 projects,

as well as some bonus material, including some appendixes that were

cut from the book at the last minute in order to save space.

Are we ready for your book? No more tables for layout and spacer gifs...what can we say to our customers when they complain that they can't experience the site with Netscape 4.x?

Well, I don't think tables are dead just yet, and the book doesn't

really make that claim. What I would say is that if you use simple

tables to lay out the main areas of a page, and then use CSS to style

the contents of those table cells, you'll get a decent page in

Netscape 4.x and the intended page in more recent browsers. I admit

that the book doesn't give much consideration to NN4.x but let's face

it-- it's a five-year-old browser. That's more than half the age of

the "popular Web," which was launched by the release of Mosaic 1.0.

Its contemporary was IE3, which nobody really cares about any more.

That said, if a Webmaster is in charge of a site that has a large

NN4.x visitor population, then they should obviously do a little more

to cater to that browser. The question is this: must the page look

exactly the same in NN4.x as it does in IE6? I would say no. As

long as the page is readable in old browsers, it can look a little

different. An example of this is the Fox Searchlight Web site. It's not precisely the same to the

pixel in NN4.x as it is in recent browsers, but it's still usable and

it looks pretty good. If you didn't compare it side by side in NN4.x

and Mozilla, for example, you probably wouldn't realize there was

anything different.

How complex is the learning curve for a developer coming from the old school named "Tables for layout"?

It's not too bad, really. The main obstacle is just letting go of

almost everything you learned when you learned table-based layout.

When you move to purely CSS-based layout, there are some changes, but

they all make sense. If you stick to basic tables and CSS for the

content, then the learning curve is really almost flat. Practically

every author I've ever met who made the transition has said that they

can't believe they ever messed around with complicated table-in-table

tricks and spacer GIFs, when CSS makes things so much easier.

Among the causes that keep developers away from adopting

CSS in their layout, there is the buggy support of browsers. Why are browsers so buggy and in particular their CSS engines? Here are some possible causes that we want to explore with you:

Very few developers use CSS for layout so browser vendors don't see the need to improve their CSS support

That may have been true in 1998, but it's completely untrue today.

Almost any site you can name is using CSS in some fashion. I'll

agree that many are using it in very limited ways, but the majority

are using it at a moderate level at least. Of course, some sites use

font tags and CSS in conjunction, which is sort of silly. Authors

should use one or the other, but not both in the same design.

CSS specifications are written in English, and every language is by definition ambiguous (mostly are not bugs, but different interpretations)

That's part of it. There have been cases where the CSS2

specification was self-contradictory, as might be expected from any

large document, and others where multiple interpretations of a given

statement are possible. The CSS Working Group is trying to iron out

those wrinkles in CSS 2.1, which is currently nearing completion, but

any human-language document is likely to be open to interpretation.

CSS is complex and so it's complex its implementation

This is the core problem. CSS looks pretty simple when you first

glance at it, but it's so sophisticated that a lot of unexpected

behaviors fall out of its simple rules. In the late 1990's, vendors

didn't pay enough attention to the subtleties of CSS, or else just

ignored them. Recently, they've begun fixing the mistakes they made.

CSS layout is are a relative new subject

I think CSS layout feels new because it's only been recently that

browsers had advanced enough for us to even think seriously about

such things.

Sometimes it's possible to see CSS files where the author uses tricky solutions to deal with buggy browsers (import to hide CSS for Netscape 4 and comments for IE5 and Opera). Others try to detect the browser using client side or server side scripts and then send it a custom version of the CSS file. Others simply do nothing. What is your opinion?

I use the @import trick to hide CSS from Navigator 4.x, so obviously

I think such tricks have their uses. I also use some tricks in at

least one of the projects in the book. However, I do think it's easy

to overdo it. If your stylesheet is half tricks and extra workaround

rules, it's probably time to consider another approach to whatever

you're trying to do. I've had a few designs that I scrapped because

they were just too advanced for current browsers without massive

trickery. That happens in any medium, so it shouldn't come as a

surprise that it happens on the Web.

Personally, though, I'm not a fan of server-side detection. it

introduces extra load on the server and it's rarely if ever needed.

The only cases I can think of where server-side detection is

necessary is if you're going to be serving up different content to

one browser versus another. If your only intention is to hand over

different CSS based on the browser, there's a good chance you're

making things too complicated, and that one stylesheet would suffice.

Surfing the Internet, it's possible to encounter many personal sites or blogs where the layout is ruled exclusively using CSS. However, the same didn't happen with commercial sites and in general with sites with lot of content. Wired is one of the first examples and yet suffers of some problems with validators. Is it more difficult to use CSS with complex sites? Why? What are the trade-offs?

Actually, once Wired had converted to CSS-driven layout, their

validation problems were all badly encoded URLs, not the markup

itself. They will have pages that don't validate because the page

content was written three years ago, but they can also fix that

gradually over time. The main page of the site does validate,

though, or at least did as I wrote this.

In fact, if you're doing CSS-driven layout, validation actually

becomes easier to achieve because your markup is simpler and more

logical. Instead of wading through nested tables and TD tags, you

can concentrate on paragraphs and DIVs. When I dropped tables from

my personal site in January of 2002, I had a much easier time with

validating and correcting validation errors.

Do you think that the CSS standard is complete or does it lack something important?

CSS will never really be complete. It may stop developing at some

point, but there will always be something it doesn't do that somebody

wants. For example, CSS as it stands doesn't have a way to relate

elements to each other in layout terms-- you can't say "make this

element as tall as this other element." That would be useful for

positioning, and maybe it will be added to CSS some day, but then

we'll just come up with something more complex that we want to do. I

don't think any presentational language, no matter how complex or

powerful, can ever cover every single thing authors will want to do.

Similarly, whether a missing feature is important or not depends on

who you ask. What I think is a critical flaw may be of no concern to

someone else, just as I tend not to be bothered by what some people

consider important missing features. One example is "variables"--

the ability to define a keyword to mean something else, and then

refer to it throughout the stylesheet. I know a few people who think

this is a major flaw in CSS, but it's never really bothered me.