Jeffrey Zeldman Interview · 2833 words posted 06/17/2003 05:01 PM
Web designer Jeffrey Zeldman publishes industry staples The Daily Report and A List Apart Magazine, runs Happy Cog Studios, and is the author of Designing With Web Standards (Indianapolis: New Riders Press, 2003). In 1998, he co-founded The Web Standards Project, a grassroots coalition that helped end the Browser Wars by persuading Microsoft and Netscape to support the same technologies in their browsers.
since1968: Your book was originally titled “Forward Compatibility.” Why the name change?
Jeffrey Zeldman: Marketing. Forward compatibility can be one benefit of designing with web standards, but it’s a soft hit and a slow read. While it’s great to lead with benefits, if the idea isn’t strong and clear enough to leap off the spine at Barnes & Noble, then the book will just sit there, doing nobody any good.
Plus it was important to establish the category. Nobody had done that in the book space. Moving to a more straightforward, descriptive title helped target the audience and establish a genre – so that other “web standards” books can follow, in the same way that “Don’t Make Me Think!” (Steve Krug, New Riders Press) followed “Designing Web Usability” (Jakob Nielsen, New Riders Press).
since1968: Now that you mention it, I guess “Forward Compatibility” makes me think of right-thinking people who get along well. Anyway, zeldman.com is one of my favorite destinations on the web. It’s exciting to watch you innovate in public and let us in on your design process. How do you keep things fresh after nine years?
Jeffrey Zeldman: Well, you take little trips together away from the kids; you hold hands like you did in the beginning; you take the time to listen to each other, to rediscover one another in an exotic, couples-friendly, tropical setting, complete with a private beach, where the two of you can…
Oh, I’m sorry, you meant the website.
Constantly updating the content helps. Rethinking the design as you get better at design, and as you see how people use your site (or don’t) also helps. Designing in public, like I’ve been doing over the past year, has made things more interesting, at least for me. Because in a way it’s saying, hey, I’m just a hack, I don’t know what I’m doing, let’s try something and see if it works. It’s humanizing because it reveals fallibility. Not that my fallibility isn’t painfully obvious anyway. But I’ve been online long enough and my site is well enough known that in some strange way I’m not quite human to some people who read my site. Designing in public may not be taking one’s pants off, but it is at least a loosening of the tie.
since1968: The Web Standards Project (WaSP) persuaded Netscape and Microsoft to support standards. Also, Rachel Andrew and Drew McLellan of the Dreamweaver Task Force convinced Macromedia to generate clean code with its web editor, Dreamweaver MX. But what’s happening on the server? Here’s an example: ColdFusion, my app server of choice, inserts markup above the XML declaration with its CFCACHE tag. Which means that if I want to generate valid code and cache my pages, I either have to write my own tag or choose another method to cache pages. How can developers persuade vendors to produce compliant code in their app servers?
Jeffrey Zeldman: I get into that some in Designing With Web Standards. It will happen when high ranking members of big companies demand it. For instance, it will happen when an Executive Vice President of General Motors writes to say, “We would like to keep using your product across our enterprise, but we need you to make the following changes.” It takes the lead designer, lead developer and project manager agreeing, then getting the head of IT on board, then sitting down with a VP. As I’m describing it, it may sound like a pipe dream. But companies want to take advantage of XML-based workflows. They want to do more with their shrinking resources, and more and more web professionals are agreeing that standards are key to this transformation.
Back when I was with WaSP, we gave Microsoft grief for implementing colored scroll bars in IE5.5 instead of fixing their problems with the CSS box model first. But Microsoft representatives told us a huge customer of theirs had strongly requested colored scroll bars. When a major customer demands something, it’s in the company’s interest to act. Vendors get heaps of requests – some of them about web standards, some about colored scroll bars. They can’t do everything at once, so they prioritize, and the size of the organization making the request is one factor in the way they decide which tasks to do first. As knowledge of the importance of web standards works its way up the corporate food chain, there will be more requests for improved standards support, and CMS systems and the tools that build them will get better.
since1968: Two pieces of news broke recently: AOL and Microsoft have reached a settlement, and Microsoft says it won’t release new versions of Internet Explorer that aren’t tied to OS upgrades. To my mind, the latter announcement hasn’t received enough attention. Whither Mozilla? Whither browser innovation? Does anybody actually say “whither” anymore?
Jeffrey Zeldman: While you were asking that question, Microsoft also quietly let it slip out that they will make no more versions of Internet Explorer 5 for Macintosh, which was the first browser to deliver meaningful standards compliance (back in March 2000) along with now-standard innovations like DOCTYPE switching and Text Zoom. Having won the browser wars, Microsoft is now attempting to kill the browser. But consumers have a choice, and the standards that are in Microsoft’s browsers are also in Mozilla, Opera, Konqueror, Safari, and so on – and sometimes those standards are better implemented in those non-Microsoft browsing environments.
With no new standalone versions of IE, no new Microsoft browsing application before 2005 (built into the OS code named Longhorn), and no widespread adoption of Longhorn likely before 2007, we’re going to enter a long, fairly static period where most developers don’t build anything that can’t be handled by IE6, a somewhat buggy year 2000 browser. But what IE6 can handle, all other modern browsers can also handle. So, paradoxically, I think we will see more and more use of web standards.
Designers who are using web standards in a certain way will continue to do so and feel more and more secure about it because all browsers support what they’re doing. Designers and developers who haven’t given web standards a chance will feel more and more empowered to do so, because the browsing environment won’t be changing all that quickly for years. The downside is that even if Mozilla and Opera offer complete support for CSS3, the aging and unchanging IE browser won’t, so most of us won’t use CSS3 (or will only use it for grace notes). The upside is that no one in their right mind will be afraid to design with web standards. The techniques described in DWWS will keep working presumably forever, and you won’t need to learn any new workarounds for IE’s defects, because no new IE defects will be introduced.
since1968: You know those movies where a guy gets paid to carry a box, only he’s told not to look inside the box, and he gets really curious and he opens the box, and he gets f***ed up when he opens the box because he opened the box? Can we look inside the box model?
Jeffrey Zeldman: CSS says that every element on a web page is either inline or “block-level,” meaning it’s its own thing, with an implied carriage return, as a paragraph is its own block-level entity. The CSS box model allows designers to manipulate the implied box for every block level element. It is what enables us to use CSS for layout. Without it, CSS would simply be a means of controlling fonts and colors.
IE5/Windows was the first browser to implement the box model, and they got it wrong. Their implementation was simpler and in some ways more usable than the one laid out in the CSS1 specification, which is somewhat unfriendly to liquid layouts, and which requires you to do math if your boxes include borders and padding. Nevertheless, although it was somewhat more usable, the IE5/Win box model was wrong. This sounds academic until you realize that if one browser implements the box model one way, and all others (including later versions of IE) implement it another, it becomes impossible to use CSS for layout: your stuff will either break in IE5/Win, or else it will break in IE6, Mozilla, Opera, Safari, and all the other browsers that get the box model right.
So the community developed workarounds, whereby one style sheet can send the correct layout information to most browsers and the bogus but necessary layout to old versions of Internet Explorer for Windows – without browser detection, without JavaScript, without server-side switching or all the other trickery that always gets us into trouble because it stops working as soon as a new browser or wireless device or screen reader or web phone hits the market. The most famous of these workarounds is the Box Model Hack, created by Tantek Celik, who also developed the Tasman rendering engine in IE5/Mac, and who serves on the W3C’s CSS and HTML working groups. It’s a simple, perfectly CSS-compliant technique that’s used in almost every CSS layout on the web. If IE5.x/Win ever disappears, we’ll be able to cut those few lines out of our style sheets. Meanwhile, we can do CSS design without fearing that it will break for any large user group.
since1968: You and Eric Meyer share a secret: CSS isn’t as easy as you guys claim.
Jeffrey Zeldman: The basics of CSS design are simple and intuitive. But once you get into complex descendant selectors, or start floating one element to the side of another, or abstract the markup by turning inline elements into block level elements in order to create visual effects, things naturally become trickier and less immediately intuitive. I’ve been working with CSS since 1997 and I still get momentarily confused at times about the difference between, say, td#menu and #menu td.
Add to that problem the imperfections in various browsers. You create a CSS virtual menu bar and it works in one browser but not another. Is a browser bug to blame (and if so, can you create the same effect a different way)? Or did you actually create the effect ineptly? Is the browser that displays what you expected wrong to do so? You can’t tell by validating, because the W3C CSS validation service can’t read your mind. It can flag syntactical errors, but it can’t tell if you’ve authored a technically correct rule that doesn’t actually do what you want. So you have to look at the syntax again. Maybe you forgot a semi-colon. Maybe you selected two things instead of using one to select another. It’s not hard, but it’s like proofreading: just as you can easily miss your own spelling errors in what you write, you can fail to notice a missing comma in a chain of selectors.
But the “difficulty” of CSS has been even more greatly exaggerated than the “ease” of transitioning from old school table layouts to structured, semantic markup and well-made style sheets. Remember JavaScript? CSS is much easier to learn and use. One reason some people complain is that CSS has a learning curve, like everything else, and failure to master the learning curve in fifteen minutes shames some people who consider themselves web experts. If you’ve been online for years, and you’re competent at HTML, XML, JavaScript, PHP, and other web technologies, it is embarrassing to feel like a beginner when your first CSS layouts don’t work as you expected. Most people react to that embarrassment by learning more and trying a little harder, and these efforts always pay off. Soon the budding CSS expert can’t believe he or she was ever afraid of style sheets. But a few frustrated first-timers prefer to give up and blast CSS on their web logs or on mailing lists. Some of these folks think they’re revealing the secret truth about CSS, but all they’re really showing is that they’re unwilling to make a small effort to learn a new thing.
since1968: I sense a certain dissonance in your book and your recent Daily Report postings when it comes to support for standards. You spend the bulk of the book building a very convincing case that if a designer wants her site to render predictably in current and future browsers, she’ll code to standards, most specifically XHTML 1.0. But in your web postings, your stance re XHTML 2.0 – a proposed standard which is counterintuitive, inconsistent with previous standards, and goes against the way most designers code today – is that we should feel free to ignore it if and when it comes to pass. Is that a fair assessment of what you’ve written?
Jeffrey Zeldman: What I’ve said is that, to me, the original proposed XHTML 2 spec looked unintuitive and hostile toward humans who create websites. It achieved greater semantic purity, and that’s a good thing. But in doing so, that first draft also deliberately chucked out the window various familiar and harmless elements, including the img and br elements. In pointing out these problems, I also made clear that XHTML 2 was a very early draft spec that was liable to change before becoming a final recommendation, and that the W3C actively solicited feedback from the design/development community. In other words, if you’re concerned about the direction XHTML 2 seems to be heading, let the W3C know.
Many people did, and the W3C has begun modifying the specification in what are, to me, some very good, very human-friendly ways – although there’s a lot more that could and might still be done. And that’s the way the W3C set up the process: experts huddle and come up with something, the community is encouraged to provide feedback, the experts evaluate the feedback and often make changes as a result. I should also add that there are people, and these are quite smart people, who had no problem at all with any part of XHTML 2, and who saw it as meeting their needs in a way XHTML 1.x does not.
Which led me to suggest that if the W3C was going to continue along the path it had begun clearing with the first draft of XHTML 2, it might consider calling the spec something else (like Structured Semantic Markup Language), to make it clear that there were two forward compatible paths: XHTML 1+, which was much like the HTML was all know, and SSML (or whatever), which was new and different.
Around the time of these writings I also pointed out that XHTML 2 was an unfinished spec, that it would be a while before it became a final recommendation, and that it might be years before browsers and devices supported it, if they ever did. The self-willed death of Internet Explorer makes it even more likely that XHTML 2 will be slow coming to market. My point was, the sky is not falling. If XHTML 2 comes out and works for you, you’ll use it; if it doesn’t work for you, you won’t.
since1968: Let’s say a developer wants to build a web application with data-binding on the client, the sort that feels like a desktop application. Does it make more sense to work with the DOM or with Flash?
Jeffrey Zeldman: Depends. For hesketh.com it makes more sense to work with the DOM. For We Work For Them it makes more sense to use Flash.
since1968: Which new technologies or techniques excite you?
Jeffrey Zeldman: Call me old-fashioned. I like good writing, clean design, arresting yet appropriate uses of typography and color. Give me a well-executed, brand-appropriate, user-oriented design with a real tone of voice and I’m happy.
As to technique, I’m kind of enamored with the Fahrner Image Replacement (FIR) method, where you write structural markup, assign a background image to the element, and then hide the text from CSS-capable browsers. In this way you can have beautifully typeset headlines, for instance, while delivering pure structural semantics. If your site includes a user-selectable style sheet switcher, you can change the presentation to suit each CSS layout. As the visitor switches from the white layout to the blue layout, the headline style changes, the headline art changes, even the size of the element can change. A simple demonstration is available on the front page of The Daily Report. Change styles and the rooster changes colors. It’s not done to be super-cool or amazing, and it’s not super-cool or amazing. But it’s cool – and useful and fun.
since1968: Thank you for your time.
Jeffrey Zeldman: The pleasure was mine. Thanks for the great questions!
~~~
Buy Designing With Web Standards from Amazon.
* * *