An Interview with Eric Meyer

Your early CSS books were instrumental in pushing my love for front end technologies. What was it about CSS that you fell in love with and drove you to write about it?

At first blush, it was the simplicity of it as compared to the table-and-spacer hacks that were so widespread at the time — this was mid-1996. CSS just felt right — the conceptual model made sense, the syntax was straightforward. It seemed like anyone who could learn HTML could learn CSS and have so much more power at their command.

From there, I think it was mostly the sheer joy of crawling through a new system, pulling it apart, figuring out how it worked, and documenting what worked and what didn't. I don't know exactly why those kinds of things excite me, but they do.

What were some of the early struggles that faced CSS? Any old stories you can share?

The biggest struggle by far was interoperability. Early implementations were rushed, partial, and often deeply flawed. One of the first major projects that got me noticed was publishing CSS support charts for early browsers. It's always fun to see some of my early design decisions in charts that have come along later — classifying support for each feature as Yes/No/Partial/Buggy, color-coding each ratings' table cell as green/white/yellow/red, and so on. It was rare in those days to have a feature's row be all green, meaning it had cross-browser support without known bugs or limitations.

So, if you wanted to do anything interesting with CSS, you had to write separate style sheets for each major browser. This was back when the only known hack was that Netscape ignored @import(), so you would write CSS for Netscape, then write styles for IE that overrode some of the Netscape styles while adding some IE-centric styles, and then import that style sheet.

We were approaching a complete deadlock at the turn of the millennium: basic box model layout was totally different thanks to the whole width/height problem, where IE didn't implement the CSS box model, whereas Netscape and Opera did, so you could set a width and some padding and get elements of completely different sizes in different browsers. Neither side was willing to change their handling of the box model, and it threatened to strangle CSS to death. DOCTYPE switching let IE implement the specification box model in its standards mode while still using its incorrect, if more intuitive, box model in quirks mode. Netscape was able to use DOCTYPE switching to bury some of its embarrassing bugs in quirks mode as well.

I often say that DOCTYPE switching saved CSS, and it's no exaggeration. Without it or something like it, we'd be struggling through the ramp-up phase of a new presentation language right about now.

What would you qualify as the top few CSS-related problems facing developers today?

Layout is A-number-one, and has been for so long now. Flexbox and grid layout promise to finally, FINALLY fill that huge hole at the heart of CSS. I'm really, really excited and optimistic about both.

Right behind layout, though, is the increasing scope and complexity of CSS, which is becoming a real challenge for authors new and old. I mean, CSS1 was really pretty simple. It's about 75 pages printed from the browser with no changes to the defaults, and it described some pretty simple stuff. Set colors, fill backgrounds, change the font face, float elements — nothing was really all that complex. Floats were as complicated as it got.

Now we have vaguely inscrutable selectors and gradients and transform matrices and keyframe animations and a whole host of other things that are really not very easy to describe in simple ways, so their descriptions are often not simple. It's hard to see what else could have been done, and yet the problem is there. When you see Bert Bos delivering talks about what's next, you know there's trouble in River City.

A lot of this is a simple side effect of success: if CSS hadn't become such a central part of user interface technologies, it wouldn't have grown as far nor become as complex as it has. Something else, or several something elses, would have already come along. CSS is everywhere now — browsers, chat clients, routers, even operating system UIs. The more places it gets used, the more things people want to add to it. There's an aphorism that's been semi-jokingly called Meyer's Law: Anything that can be done with CSS eventually will be done with CSS. I mean, have you SEEN CSS 3D Clouds? Madness. The very best kind of madness, of course, but still: madness.

Your CSS reset is one of the most widely used snippets of CSS on the web. What considerations to you take when updating your reset.css with each revision?

Generally, what I always have in mind is that my goal is not to enforce certain stylistic ideas. It's to strip all elements, aside from form elements, down to the point where they act like a div or a span, visually speaking. That creates a foundation on which authors can build their own stylistic ideas. I get people emailing me to say that I should set all elements to box-sizing: border-box or that I should define foreground and background colors, but that's not what a reset does. That's what authors do with a reset, to make it their own.

The major revision for reset 2.0 was to correct my one major blunder, which was that I reset focus outlines to zero width with a note that authors should declare some sort of visible outline. That was in keeping with the idea of "set everything to a baseline and then build your preferred effects on top". The problem is that hardly anyone ever did as I requested, leading to widespread focus-outline suppression. I really regret that I created such a huge accessibility problem. So I pulled that bit out when I revised, and publicly apologized for the unintended consequence. It was a huge unforced error, one dearly I wish I could take back.

What would you say are the mistakes developers most frequently make when it comes to CSS?

Removing focus outlines. Seriously, people, stop it. You're not helping anyone, and you're hurting people with accessibility concerns. Cut it out.

Beyond that, the biggest is probably still that developers think CSS gives them absolute control over page layout and presentation. It doesn't, and was never supposed to: CSS gives you presentational influence, and that's it. Granted, that influence is very strong, but it can still be overridden by users, by devices, by any number of things.

A closely related mistake, now starting to fade, is assuming that you can fix the width of a layout. Responsive design is finally getting people to realize that this is untrue, but unfortunately it's still a pretty common design pattern. Though I suppose that's more of a design mistake than a CSS mistake per se.

Many developers would say that CSS advancements aren't implemented within browsers quickly enough. What is your thought on the speed with which CSS features are implemented in browsers?

I think they're doing pretty well, actually. Given everything that they could add, it's impressive that they're adding as much as they are, and working as hard as they are to get their implementations right the first time.

But then, I remember the IEnterregnum, when practically nothing but bug fixes happened for years on end; and the Browser Wars, when stuff got added so fast and furiously that it was rarely ever done well, let alone done right.

Not to mention, the stuff that's coming down the pipe, like flexbox and grid layout and exclusions, is really complex and difficult stuff. I've talked with implementors about the complexity of rendering tables — not styled tables, even, just figuring out how to lay out a table based on its context and its content. Grid layout makes that look like peanuts. Gradients are no walk in the park, and there is already work on compositing and filters, and it's pretty amazing, really.

So, yes, we always want everything complete and perfect and now now NOW, and browser teams are constrained by headcounts and strategic priorities and the need to sleep every so often, so we're always going to wish they would go faster. Against the historical record, I say they're doing pretty darned well.

CSS property prefixing is a hot topic in the CSS community; what is your opinion of this practice, and is there a better solution?

I'm one of those contrarians who thought prefixes were not only a great idea, but not taken far enough. So I was always for the practice. Sadly, their actual use in the real world fell short of the ideal, and I expect them to be gone within the next few years.

I know that fills a lot of authors with embittered glee, mostly because they hated all the repetition the prefixes incurred, but I really do think it's a loss for the community. Without prefixes or something like them, it's a lot harder to get new features tested by a wide range of people in a short span of time. The fewer the testers, the fewer the found bugs, and the greater the chance of permanent incompatibility. It makes me sad.

Do you have any opinion on Opera's move to WebKit?

Oh, yes. My opinions are pretty much exactly what John Lilly, ex-CEO of Mozilla, said, so I just point people to his post. But since we're talking CSS nerdery here, I'll add that I'm also sorry to lose a rendering engine because it reduces the number of implementations that can show interoperability. No CSS module can exit the Candidate Recommendation stage unless there are two interoperable implementations of that module. It used to be there were four implementations, so you needed two of four. Now you need two of three. It's not an impassable roadblock, but there's less room to maneuver, as it were.

Any mobile CSS tips you can pass on?

Pay attention to whatever Luke Wroblewski, Scott Jehl, Brad Frost, and especially PPK have to say. That's what I do.

How can developers structure their CSS so that it can scale (i.e. be more maintainable) as their application grows?

I think Nicole Sullivan's work on OOCSS is worth studying very closely. CSS preprocessors like LESS or Sass are also very good tools for keeping things neat and tidy, though that does mean you have to keep an eye on the output to make sure it's decently optimal. Not because frameworks are inherently sloppy, but because you're relying on algorithms to generate your CSS for you. There will always be edge cases where the result will be sloppier than what you could manage by hand.

I've always contended that CSS is the bridge between designers and developers, and that CSS' simplicity is the key to its effectiveness. How can we add more logic to CSS while keeping the language simple?

That's a question for much wiser heads than mine. I always thought things like animations and gradients were too inherently complex to be added to CSS, and yet here we are. This is an area where I think preprocessors really shine: they have already experimented with ways of adding logic to CSS. Now the Working Group can look at what they've done and copy or improve on it. Thus we see formal proposals for variables, and some serious interest in formalizing extensions and mixins.

HTML5, CSS, and JavaScript will be blitzing the mobile market within Firefox OS. What do you think of CSS' role in mobile apps, and what may need to change to better accommodate mobile?

It's a little astonishing to see everywhere CSS is going, isn't it? I actually think CSS does pretty well at meeting mobile needs, assuming that you actually think of a mobile device as a mobile device and not a tiny desktop monitor. What will need to change is improving the speed of rendering engines, same as with JS.

You're a co-founder of An Event Apart. What can attendees to AEA expect to learn during these sessions?

New ways of looking at what they do, challenges to their entrenched assumptions, and inspiration to stretch their skills and scope further, plus tons of ideas they can take straight back to the office and put into practice. That sounds like a pretty tall order, I know, but the speakers are just incredible and never cease to blow me away.

What can we expect from Eric Meyer in the future? Anything you can share?

I'm working through the fourth edition of CSS: The Definitive Guide, which is being released a chapter at a time as "pre-books" available in digital or print-on-demand formats. That means you can buy the first few chapters now, and the next few soon. I'm also continuing to do a web history podcast series with Jen Simmons of The Web Ahead, with plans for some great guests in the coming months. I'm speaking a lot in 2013 — partly because I'm onstage at every AEA, but I'll also be at Rust Belt Refresh in my hometown of Cleveland, CSS Day in Amsterdam, and the CSS Dev Conference in Colorado. And who knows what else? I'm sorry I'll miss the inaugural CSSconf, but it conflicted with previous commitments.

Beyond those things, I'll be continuing to do what I've been doing for years now: working with Jeffrey to make An Event Apart better and better, writing CSS tests, and advocating for open standards in every nook and cranny of our online world. It keeps me off the street and out of trouble.