They write the specs that make the whole world sing.
A Business Week slide show, “Thinking Outside the Design Box,” profiles “10 professionals working at the very edges of their disciplines in order to redefine their industries.” Included are designers Lisa Strausfeld of Pentagram, who helped design the interface for One Laptop Per Child; Robin Chase, the founder of Zipcar; and (ulp!) me.
I’m in there because they needed a pretty face, and because of the whole web standards thing.
The piece is part of “Cutting-Edge Designers 2007,” a Business Week Special Report focusing on innovation that arises out of crossing disciplines and combining technologies.
It’s worth reading, which is lucky, because I would have blogged it no matter what.
So you think you know all about whitespace. You may be surprised. Mark Boulton, type expert to the stars, shows how micro and macro whitespace push brands upscale (or down) and enhance legibility in print and online.
For designers who find web standards as easy to grasp as a buttered eel, Craig Cook shows how to stop the hurting and turn on the understanding. Learn how web standards work, and why they are more than simply an alternative means of producing a visual design.
Standardistas adore the Mozilla Firefox browser for its advanced support of web standards. (How good is it? The Web Standards Project considered declaring victory and closing shop when Netscape Corp. announced in 1999 that it would heed our advice and dump its non-compliant software in favor of the Gecko rendering engine that powers Firefox today.)
Though Firefox and related Mozilla browsers deserve credit for their unsurpassed handling of everything from the Document Object Model to MIME types, Firefox’s way with text leaves much to be desired, as the following screen shots show. Indeed, if reading is mostly what you do on the web, and if accurate typography makes reading more of a pleasure and less of a strain, then Apple’s Safari is superior to Firefox.
Lucida, Test One: with genuine italics
Zeldman.com is designed to be read in Lucida Grande, and the site originally listed “Lucida Grande” first in its style sheet. Alas, Lucida Grande lacks true italics. Fortunately, Lucida Sans has them. In a version of our style sheets used to capture the following screen shots, we’ve listed Lucida Sans first, Lucida Grande second, and substitutes thereafter. Both browers handle the site like a dream—but it is only a good dream in Safari. Open the screen shots in tabs:
In Firefox, why does the text “now in its second edition. I can’t” display midway between roman and bold, and why is it so poorly antialiased? Apparently, Firefox bungles roman text that follows italics.
In Firefox, why doesn’t hyphenation work? My gosh, people, it’s nearly 2007. IE5/Mac supported hyphenation.
Lucida, Test Two: using a font that lacks italics
Remember: Lucida Grande does not have italics; Lucida Sans does. But as Test One showed, Firefox can’t handle Lucida Sans correctly. So we’ve revised the style sheet. With Lucida Grande listed first in the style sheet, and Lucida Sans deleted, Safari still trounces Firefox. The experience of reading text is smoothly beautiful in Safari, much less so in Firefox.
Both browsers fake the italics. But Firefox does the job crudely: a child could tell that its “italics” are faked. (Firefox slants the roman text.) By contrast, Safari fakes its italics so well (by substituting a true italic from the next available listed font that contains one) that only graphic designers and type hounds will realize that the font they’re viewing contains no true italics. See reader comments for delicious details.
In Firefox, hyphenation still does not work.
It’s worth pointing out that these tests were done on Macintosh computers, which are known for their superior handling of text, and that Lucida is not some strange face chosen to prove a point. It is the default font in Mac OS X (not to mention on apple.com). Moreover, Lucida Sans Unicode, the first Unicode encoded font, shipped with Windows NT 3.1 and comes standard with all Microsoft Windows versions since Windows 98.
When I showed a friend and fellow designer these simple tests as I was working on them, he asked if I had reported “the bug” to the makers of Mozilla. But as I count it, there are multiple, overlapping Firefox bugs happening here—too many to fit into a bug-report form. I suspect that the problems have to do with Mozilla’s reliance on its cross-platform display environment. If you scuttle what an individual operating system does well in favor of what a cross-platform environment does poorly, you get what we’re seeing here. It’s not good enough.
Inferences for best practices
If your content will sometimes include italicized text, you naturally want to specify a font that contains italics. That’s just common sense. Unfortunately, as our screen shots have shown, common sense works against you here, because Firefox, although superior to other browsers in many ways, handles text like a drunken fry-cook.
When you specify the font that contains genuine italics (as we did in Test One), Firefox mishandles the roman text that abuts italicized words. When you replace that font with one that contains no italic (Test Two), Firefox fakes the italics crudely, but overall display and legibility are better than the unusable results of Test One.
Obviously there are fewer problems if you limit your website to Verdana and Georgia, but more constraints on typography are not what the web needs.
Discussion is now closed. Thanks to all who shared.
Tim Berners-Lee, inventor of the web and founder of the W3C, announces reforms:
It is really important to have real developers on the ground involved with the development of HTML. It is also really important to have browser makers intimately involved and committed. And also all the other stakeholders….
Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work.
Our Australian friends set up camp in Vancouver, for what looks like a great two-day conference on standards-based design and development (Vancouver Canada, February 6-8 2007). Speakers include Kelly Goto (Gotomobile), Andy Clarke (malarkey), Adrian Holovaty (Chicago Crime, Washington Post), Douglas Bowman (Google Visual Design Lead), Dan Cederholm (SimpleBits), Joe Clark (joeclark.org), Dave Shea (CSS Zen Garden), Cameron Moll (Authentic Boredom), Molly Holzschlag (Molly.com), Veerle Pieters (Veerle’s Blog, Duoh!), Kaitlin Sherwood (Google Maps US Census mashup), Tantek Çelik (Technorati).
By Andrew Kirkpatrick, Richard Rutter, Christian Heilmann, Jim Thatcher, Cynthia Waddell, et al. Don’t let the unsexy title fool you. Vast and practically all-encompassing, this newly updated classic belongs on every web designer’s shelf. (Better still, open it and read.)
Some of the best minds working in web standards have been quietly or loudly abandoning the W3C. Björn Hörmann is the latest. His reasons for leaving the W3C QA Group make compelling reading (hat tip: Terje Bless). I believe in W3C standards, particularly the ones you and I use every day, but I worry about the direction in which the W3C is headed.
Beholden to its corporate paymasters who alone can afford membership, the W3C seems increasingly detached from ordinary designers and developers. Truth be told, we and our practical concerns never drove the organization. But after ordinary designers and developers spent nearly a decade selling web standards to browser makers and developing best practices around accessibility and semantics, one hoped the W3C might realize that there was value in occasionally consulting its user base.
Alas, the organization appears unconcerned with our needs and uninterested in tapping our experience and insights. It remains a closed, a one-way system. Like old-fashioned pre-cable TV advertising. Not like the web.
To be fair, the W3C solicits community feedback before finalizing its recommendations. But asking people to comment on something that is nearly finished is not the same as finding out what they need and soliciting their collaboration from the start.
We require coherent specifications based on our and our users’ actual needs. Upcoming accessibility and markup specifications fail on both counts. We require validation tools that work and are kept up to date. Instead, tools are still broken years after problems are reported.
Two things could happen. Either the W3C will make a course correction, or the standards-based design community will look elsewhere.
[tags]web standards, w3c, wcag, xhtml, web design, microformats[/tags]