Published on June 11, 2002
Digital Web: In English for those of us who don’t like to read W3 specs, what is the difference between in CSS-1 and CSS-2?
Eric Meyer: In geekspeak, CSS2 is a superset of CSS1. In other words, CSS2 includes all of CSS1 in addition to the new stuff. Even that isn’t quite true, though: Although CSS2 is basically CSS1 with a whole bunch of stuff added on, there were a few changes between CSS1 and CSS2. They’re listed in an appendix to CSS2, and are generally minor changes. One not-so-minor change was the initial value of
display, which went from
inline. But this is fairly esoteric stuff—very few authors will ever get tripped up by these sorts of changes.
Digital Web: What it’s like to be working with the W3C? What are your thoughts are for the next generation of CSS?
EM: Working with the W3C is like working with any large committee that is dependent on group consensus, only multiplied by about a hundred. I actually suspect it’s a lot like working with the United Nations, although of course the stakes at the W3C are rarely as high as those over at the UN.
I think the next generation of CSS will be very interesting, but at the moment I’m more interested in what browsers are (or aren’t) doing with the current generation of CSS. Consistent positioning support, generated-content and counter support—these are the things we could use today, if only browsers would get their acts together. Of course, this isn’t a new story—the leading edge of CSS support has always been pretty ragged. The big change in the last two years is that the basic stuff has become consistently supported.
Digital Web: Will XSL / XSLT with XML will be the next step or will we always have a need for XHTML/HTML and CSS? Why?
EM: It depends on what you’re doing. XSLT is pretty cool stuff, allowing authors to rearrange raw XML into whatever the like. That isn’t an area where CSS is meant to operate, so the two will never really compete.
XSL:FO, on the other hand, could be a next step. It would take three things for XSL:FO to catch on in the mainstream Web:
- editors that support it and are easy for average authors to use, because almost nobody can read XSL:FO markup and decipher it, let alone write it by hand;
- native browser support for XSL:FO; and
- a fairly major miracle.
After seven years, CSS still isn’t completely and correctly implemented by any known browser, and CSS is a pretty simple and uncomplicated specification compared to XSL:FO. Why anyone thinks that XSL:FO is going to replace CSS is beyond me. CSS is human-readable and writable, which gives it a major advantage over XSL:FO, which requires something like ten lines just to make an element’s text red.
I doubt we’ll always have need for (x)HTML and CSS. Eventually, something will replace it. Maybe it will be Flash, or XML+CSS, or XML with some other easily authored style language. For that matter, maybe authoring software will advance far enough that XML+XSL:FO will actually become a viable option. It’s hard to see that far ahead.
Digital Web: CSS has been slow to catch on with corporate or large sites other than for font control. What kind of future for CSS do you see for these types of Web sites?
EM: Over time, more corporate sites will make better use of CSS. The problem most sites have is that they’re bound by people who think that a good Web page is one that looks exactly the same in “all browsers.” Of course, when pressed, these people will admit that they don’t actually care about Mosaic, Lynx, OmniWeb, CyberDog, Sypglass, or really anything besides Netscape 4.x and up and Internet Explorer 4.x and up. It’s that 4.x part that’s holding us up; if we could get beyond it and decide that we only care about browsers with versions of 5.x and up, the CSS story would be a lot richer.
In the meantime, using CSS to affect font styling is a perfectly legitimate use, at least if you do it right. (If I had a dime for every corporate site that tries to set text size in points—or, worse still, does browser sniffing expressly to give different browsers different point values—I could retire tomorrow.)
Digital Web: You’ve written Cascading Style Sheets: The Definitive Guide and you recently completed a new CSS book with New Riders titled Eric Meyer on CSS. How do the two books differ? What can we expect with the new one?
EM: CSS:TDG is an exploration of the theory. I tried to support the theory with lots of practical examples, but the book’s purpose is to explore every nook and cranny of CSS1, even the parts that no author will ever care about. My new book flips that around and presents 13 projects that yield a design that’s cross-browser consistent in v5+ browsers, without taking a lot of time on theory. There are notes on theory, but only in support of the practical advice I set forth. The reader will, I hope, learn by doing and get a feel for the theory as a byproduct.
Digital Web: The word is to toss the tables and go table-less with CSS. However, tables were created for a reason, to manage tabular data. When, if at all, should tables be used?
EM: I’d like to counter that with a few words of my own, actually. Tables are not the spawn of Satan, and they are not going away any time soon. Not every site will benefit from a full-blown conversion to a totally non-table strictly conformant XHTML 1.1-based CSS2-driven layout. Sooner or later, such sites will become more common, because that kind of layout is no more complicated than traditional table design, and it’s about a billion times more flexible.
We’re still in an adjustment period, where authors are starting to break their old table-based authoring habits and learn a new way to design. That’s going to take time, and expecting authors to change overnight is no more reasonable than expecting them to learn a new language in a day.
Digital Web: However, tables were created for a reason, to manage tabular data. When, if at all, should tables be used?
EM: The purist’s view is that you should only use a table element when you have a table of data, like a financial summary or a chart of survey results. But it turns out that the lines between what’s tabular and what isn’t are pretty blurry. For example, if I have a gallery of professional photographs that includes the titles of the images, is that tabular data? What about if I want to include information about where the pictures were taken, and the size of available /files/includes/print.csss? Does the data become more or less tabular if I want to lay it out in different ways? Everyone will have an opinion, and not everyone’s opinion will agree.
Al Sparber of Project Seven, one of the most practically-minded folks I know, has observed that if tables should only be used to hold tabular data, then by definition any data inside a table should be tabular data. In that view, there is no such thing as an inappropriate use of a table element. And as far as I’m concerned, authors are free to do whatever the markup language permits. My primary objection to table-based markup is that it’s so clumsy. You end up with these amazingly convoluted structures whose sole purpose is to create a fairly simple visual effect. The page bloat and mental gyrations that are required to make it work is just a colossal waste.
As an example, in chapter 1 of Eric Meyer on CSS, I take a typical table-based layout and convert it to a simple table with some classes and divs inside the table cells. This is a fairly simple layout, too; very few colspans, and no sliced-up images. The weight of the markup dropped 52%—no kidding! And I didn’t even go to any effort to make it particularly complex before I started. Even if you left the stylesheet inside the HTML document, the page was still 30% smaller than when it was all tables and spacer GIFs, plus it went from using 17 images to only using three. To top it off, the markup became so much simpler that it was easy to figure out at a glance how the various pieces of content related to each other.
Digital Web: WAP doesn’t have the capability to view CSS. How does this impact those development Web sites that need to be wirelessly accessed?
EM: I’m not very familiar with WAP, so I think I should keep my mouth shut until I have something useful to say.
Digital Web: From an accessibility perspective, how do you ensure CSS pages are accessible? Any dos and don’ts to remember?
EM: Do validate your markup, and use actual elements like
p instead of turning everything into
span. Do use classes and IDs to attach your styles to the markup. Don’t make the structure more complicated than it has to be. If you follow those basic ideals, then you can style to your heart’s content without touching the structure of the page. If you’ve done your job, that structure will be accessible.
It really is that simple.
CSS Positioning and Flexibility
Digital Web: For the beginner who may have used CSS for font control, what advice do you have for moving to the next level with CSS?
EM: The next step is usually working with box properties; that is, margins, padding, and borders, as well as backgrounds. The methods are pretty simple, but the ways these combine can be surprisingly complex. Once you get comfortable with styling boxes, try floating and maybe some limited positioning, just to see how it goes.
I still think the biggest challenge for any CSS author of any level of expertise is in making the presentation and the structure work together intelligently. It’s awfully tempting to just add classes and IDs to everything in site and style based on those values. That’s an approach that can work, but it ignores the whole point of CSS: to let authors write highly structured markup, and then style it.
Digital Web: Positioning is confusing for many. What are some ways to learn and understand CSS positioning concepts?
EM: Is this where I plug my new book? No? Darn. Actually, it makes more sense to start with really simple examples and work your way up from there. I sometimes go look at Little Boxes and glish.com’s layout examples just to remind myself what’s possible. By taking those layouts and experimenting with them, you can learn a lot about how positioning works.
Digital Web: Older browsers have varying degrees of CSS complaints and we’ve gotten into a bad habit of adding workarounds. What workarounds, if any, should we use or stop using?
EM: Use the workarounds that make the most sense for you. There are many standards-compliant ways to hide CSS from browsers—Johannes Koch has documented most of them at pixelpark.com, complete with a summary table showing which “hacks” will exclude which browsers.
Digital Web: Some like to use WYSIWYG editors like Dreamweaver and GoLive, but they don’t correctly display Web sites using CSS positioning. What advice do you have for them?
EM: Always, always, always preview your pages in multiple browsers. Never rely on the “preview” pane in an editor. In fact, some Dreamweaver experts I know advise other DW users to just avoid its preview feature altogether, and use browsers for previewing instead. Previewing in an editor is like previewing in a four-year-old browser that nobody has ever seen before, and whose standards support doesn’t match anything in the field. It’s just not a good idea.
Digital Web: You’ve done some amazing stuff with CSS/Edge. What can we do with CSS?
EM: Nobody really knows, and that’s what I find so exciting about CSS, even after six years of working with it. Just within the last couple of years, CSS browser support has improved to the point that we can stop worrying about flaws and start digging into what CSS really makes possible. There are bound to be limits, as there are with any technology, but I don’t think we have a clear idea of just how much visual design freedom CSS allows us.
Digital Web: You’ve experimented with liquid CSS design. What tips do you have for constructing flexible layouts?
EM: I don’t think we have time for a real answer, so let’s settle for this: giving up pixel-sized elements and working with “liquid” designs is a major shift, and one shouldn’t expect to master it overnight. There will be stumbling blocks. The design will not behave as you expect, and it will turn into a train wreck. There are myriad variables that have to be considered all at once.
I’m sure it’s possible to approach liquid design in a logical fashion, but my experience has been that liquid design is more art than science. I also believe that the best designs come from people who have played long enough that they develop an intuitive feel for what will happen, and what to do when the unexpected happens. It’s often the unexpected that becomes the design, in fact.
Netscape and Radio
Digital Web: What’s it like to work for Netscape?
EM: It’s probably like working for any large corporation, except I get to work from home and do a job in which I truly believe. The people I work with all seem to have the same outlook I do, which is that creating a decent browser that supports open standards is the best possible thing we can do for the Web. Providing such a browser as a way to foster diversity in the Web space is a close runner-up.
Consider that Netscape hired me to be a Standards Evangelist, as opposed to a Technology Evangelist. My job doesn’t involve telling people that our product is the greatest and will solve all your problems. It’s about finding standards-based solutions that will work in multiple browsers, not just ours, and promoting them. What other company would fund full-time salaried positions for almost a dozen people just to have them work on improving standards support and helping Web developers come up with solutions that will work as well in competing products as their own? I’m constantly amazed that they pay me for this, but almost as amazed that they pay anyone to do it.
Digital Web: Without revealing any company proprietary information, what can we expect to see from Netscape?
EM: More standards support, fewer bugs, faster performance, and better stability. The days of NN4.x and Netscape 6.0 are long behind us, and anyone who hasn’t given Mozilla or Netscape 6.2 a try really should. Mozilla 1.0 in particular has been getting a lot of rave reviews recently, with people lavishing a lot of praise on tabbed browsing, the return of Print Preview, and of course its standards support.
Digital Web: Many claim that Microsoft’s IE has won the browser wars. What does the future look like for browsers?
EM: I’ve seen those claims, but they’re misleading. Microsoft didn’t win the browser wars, standards did. The fact that I can write cross-browser DOM scripts without checking the user agent string proves that. Now that the wars are over, we see browsers constantly adding support for more standards. As an example, Netscape, Opera, and Explorer have all improved standards support in their most recent browser releases, and have publicly announced plans to keep going. The future is open standards: no browser will be taken seriously without them.
Digital Web: You have a weekly radio show in Cleveland called “Your Father’s Oldsmobile.” Tell us about it.
EM: It’s a two-hour show devoted to American music from the 1920-1950 period. I concentrate mostly on Big Band, small-group swing, and Dixieland, but the blues and early jazz also make it onto the show. It runs from 7:00 A.M. – 9:00 A.M., Eastern U.S. time, every Wednesday morning on WRUW 91.1-FM Cleveland (www.wruw.org). You can listen to the live audio stream, or get a copy of the most recent show from the station archives.
Digital Web: There are so many radio programs out there, how did you decide to do your show?
EM: I didn’t, actually. A student at CWRU started it in the early ’90s, and when he graduated it passed on to a friend of mine. When he got ready to leave town, he was talking about how it was a shame that so unique a show would die out. Well, I’d had a show as a student myself, and although it had been years since I’d been on the air, I said I’d like to keep it going. The station management gave the blessing, and I ran with it. That was almost six years ago now; 1996 was definitely a watershed year for me.
When I started out, I knew almost nothing about the music from that period—I’d heard of some of the big names, like Glenn Miller, but that was about it. I’m more of a rock and techno guy on my own time, so my callers usually knew far more than I did! Over time, I’ve gotten used to the different band styles and I think the show’s really started to gel in the last couple of years. It’s a whole lot of fun to do.
Meryl K. Evans, content maven, is a WaSP member even though she’s far from being a WASP. The content maven writes a column for PC Today and blogs for the Web Design Reference Guide at InformIT. Meryl provides the home for the CSS Collection and she’s the editor of Professional Services Journal, meryl’s notes :: the newsletter as well as other newsletters, so tell all your friends, families and animals to subscribe. Her ancient blog keeps cluckin’ since its arrival on the web in 2000.