Eric Meyer is a Standards Evangelist for Netscape Communications: hetries 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 innature. 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'treally 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 ofalmost 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 adoptingCSS 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 supportThat 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 implementationThis 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 subjectI 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 obviouslyI 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, theirvalidation 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 somepoint, 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.