Notice of Credit Limit Reduction on my personal account from American Express. “In this difficult economic environment, we all need to make choices about how we spend and save.”
Discussions of Happy Cog new business activities in various stages of ripeness.
Note about a magic berry that will make me look like a princess.
Why Standards Fail
Back in 2000, CSS co-creator Bert Bos set out to explain the W3C’s design principles—“to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, [and] longevity….”
Eventually published in 2003, the essay, although ostensibly concerned with explaining W3C working group principles to the uninitiated, actually articulates the key principle that separates great design from the muck we normally wade through. It also serves as a warning to Bert’s fellow W3C wizards not to seek the dark magic of abstract purity at the expense of the common good. Tragically for these wizards, and for we who use their technologies, it is a warning some developers of W3C specifications continue to overlook.
Design is for people
In his introduction, Bert summarizes the humanistic value that is supposed to be at the core of every web standard:
Contrary to appearances, the W3C specifications are for the most part not designed for computers, but for people. … Most of the formats are in fact compromises between human-readability and computer efficiency….
But why do we want people to read them at all? Because all our specs are incomplete. Because people, usually other people than the original developers, have to add to them….
For the same reason we try to keep the specifications of reasonable size. They must describe a useful chunk of technology, but not one that is too large for an individual to understand.
Over the succeeding 25 web pages (the article is chunked out in pamphlet-sized pages, each devoted to a single principle such as “maintainability” and “robustness”) Bert clearly, plainly, and humbly articulates a series of rather profound ideas that are key to the web’s growth and that might apply equally admirably to realms of human endeavor beyond the web.
The Web now runs on HTML, HTTP and URLs, none of which existed before the ’90s. But it isn’t just because of the quality of these new formats and protocols that the Web took off. In fact, the original HTTP was a worse protocol than, e.g., Gopher or FTP in its capabilities….
And that fact shows nicely what made the Web possible at all: it didn’t try to replace things that already worked, it only added new modules, that fit in the existing infrastructure. …
And nowadays (the year 2000), it may look like everything is XML and HTTP, but that impression is only because the “old” stuff is so well integrated that you forget about it: there is no replacement for e-mail or Usenet, for JPEG or MPEG, and many other essential parts of the Web.
He then warns:
There is, unfortunately, a tendency in every standards organization, W3C not excluded, to replace everything that was created by others with things developed in-house. It is the not-invented-here syndrome, a feeling that things that were not developed “for the Web” are somehow inferior. And that “we” can do better than “them.” But even if that is true, maybe the improvement still isn’t worth spending a working group’s resources on.
Shrinkage and seduction
In his gentle way, Bert seems to be speaking directly to his W3C peers, who may not always share his and Håkon‘s humanism. For, despite what designers new to CSS, struggling for the first time with concepts like “float” and the box model may think, Bert and Håkon designed the web’s layout language to be easy to learn, teach, implement, maintain, and (eventually) extend. They also designed CSS not to overwhelm the newcomer with advanced power at the cost of profound complexity. (“CSS stops short of even more powerful features that programmers use in their programming languages: macros, variables, symbolic constants, conditionals, expressions over variables, etc. That is because these things give power-users a lot of rope, but less experienced users will unwittingly hang themselves; or, more likely, be so scared that they won’t even touch CSS. It’s a balance.”)
This striving to be understood and used by the inexperienced is the underlying principle of all good design, from the iPhone to the Eames chair. It’s what Jared Spool would call usability and you and I may consider the heart of design. When anything new is created, be it a website, a service, or a web markup language, there is a gap between what the creator knows (which is everything about how it’s supposed to work), and what you and I know (which is nothing). The goal of design is to shrink this ignorance gap while seducing us into leaping across it.
What were once vices are now habits
You can see this principle at work in CSS, whose simplicity allowed us to learn it. Although we now rail against the limitations of CSS 1 and even CSS 2.1, what we are really complaining about is the slow pace of CSS 3 and the greater slowness with which browser makers (some more than others) adopt bits of it.
Note that at one time we would have railed against browser makers who implemented parts of a specification that was still under development; now we admire them. Note, too, that it has taken well over a decade for developers to understand and browsers to support basic CSS, and it is only from the perspective of the experienced customer who craves more that advanced web designers now cry out for immediate CSS 3 adoption and chafe against the “restrictions” of current CSS as universally supported in all browsers, including IE8.
If CSS had initially offered the power, depth, and complexity that CSS 3 promises, we would still be designing with tables or Flash. Even assuming a browser had existed that could demonstrate the power of CSS 3, the complexity of the specification would have daunted everyone but Eric Meyer, had CSS 1 not come out of the gate first.
The future of the future of standards
It was the practical simplicity of CSS that enabled browser engineers to implement it and tempted designers to use (and then evangelize) it. In contrast, it was the seeming complexity and detachment from practical workaday concerns that doomed XHTML 2, while XHTML 1.0 remains a valid spec that will likely still be working when you and I have retired (assuming retirement will be possible in our lifetime—but that’s another story).
And yet, compared to some W3C specs in progress, XHTML 2 was a model of accessible, practical, down-to-earth usability.
To the extent that W3C specifications remain modular, practical, and accessible to the non-PhD in computer science, they will be adopted by browser makers and the marketplace. The farther they depart from the principles Bert articulated, the sooner they will peter out into nothingness, and the likelier we are to face a crisis in which web standards once again detach from the direction in which the web is actually moving, and the medium is given over to incompatible, proprietary technologies.
Over the weekend, as thoughtful designers gathered at Typecon 2009 (“a letterfest of talks, workshops, tours, exhibitions, and special events created for type lovers at every level”), the subject of web fonts was in the air and on the digital airwaves. Worthwhile reading on web fonts and our other recent obsessions includes:
Responding to a question I raised here in comments on Web Fonts Now, for Real, Richard Fink explains the thinking behind Ascender Corp.’s EOT Lite proposal . The name “EOT Lite” suggests that DRM is still very much part of the equation. But, as Fink explains it, it’s actually not.
EOT Lite removes the two chief objections to EOT:
it bound the EOT file, through rootstrings, to the domain name;
it contained MTX compression under patent by Monotype Imaging, licensed by Microsoft for this use.
Essentially, then, an “EOT Lite file is nothing more than a TTF file with a different file extension” (and an unfortunate but understandable name).
A brief, compelling read for a published spec that might be the key to real fonts on the web.
Where does all of this net out? For @ilovetypography, “While we’re waiting on .webfont et al., there’s Typekit.”
(We announced Typekit here on the day it debuted. Our friend Jeff Veen’s company Small Batch, Inc. is behind Typekit, and Jason Santa Maria consults on the service. Jeff and Jason are among the smartest and most forward thinking designers on the web—the history of Jeff’s achievements would fill more than one book. We’ve tested Typekit, love its simple interface, and agree that it provides a legal and technical solution while we wait for foundries to standardize on one of the proposals that’s now out there. Typekit will be better when more foundries sign on; if foundries don’t agree to a standard soon, Typekit may even be the ultimate solution, assuming the big foundries come on board. If the big foundries demur, it’s unclear whether that will spell the doom of Typekit or of the big foundries.)
Applauding HTML 5’s introduction of semantic page layout elements (“Goodbye div soup, hello semantic markup”), author Jeff Starr shows how HTML 5 facilitates cleaner, simpler markup, and explains how CSS can target HTML 5 elements that lack classes and IDs. The piece ends with a free, downloadable goodie for WordPress users. (The writer is the author of the forthcoming Digging into WordPress.)
Web Fonts Now, for Real: David Berlow of The Font Bureau publishes a proposal for a permissions table enabling real fonts to be used on the web without binding or other DRM. — 16 July 2009
Web Fonts Now (How We’re Doing With That): Everything you ever wanted to know about real fonts on the web, including commercial foundries that allow @font-face embedding; which browsers already support @font-face; what IE supports instead; Håkon Wium Lie, father of CSS, on @font-face at A List Apart; the Berlow interview at A List Apart; @font-face vs. EOT; Cufón; SIFR; Cufón combined with @font-face; Adobe, web fonts, and EOT; and Typekit, a new web service offering a web-only font linking license on a hosted platform; — 23 May 2009
HTML 5 is a mess. Now what? A few days ago on this site, John Allsopp argued passionately that HTML 5 is a mess. In response to HTML 5 activity leader Ian Hickson’s comment here that, “We don’t need to predict the future. When the future comes, we can just fix HTML again,” Allsopp said “This is the only shot for a generation” to get the next version of markup right. Now Bruce Lawson explains just why HTML 5 is “several different kind of messes.” Given all that, what should web designers and developers do about it? — 16 July 2009
Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009
The Happy Cog-designed social network for Brighter Planet is now in public beta. Come on down and kick the tires. Brighter Planet helps you take control of your environmental footprint: measure your climate impact, discover simple ways to reduce it, track your progress, and share your experiences with other people who who want to make a difference.
Happy Cog‘s New York office developed this project. The team:
While the entire HTML 5 standard is years or more from adoption, there are many powerful features available in browsers today. In fact, five key next-generation features are already available in the latest (sometimes experimental) browser builds from Firefox, Opera, Safari, and Google Chrome.
Striving to avoid the mistake Microsoft made when it bet on binary applications over the web, Google is counting on HTML 5 adoption to expand the capability of web applications. Tim O’Reilly describes Google’s strategy and lists five key HTML 5 features that are already supported in Safari, Firefox, Opera, and Chrome.
[tags]HTML5, Google, O’Reilly, TimO’Reilly, canvas, browsers, webapps, web applications, webstandards[/tags]
AEA Seattle after-report
Armed with nothing more than a keen eye, a good seat, a fine camera, and the ability to use it, An Event Apart Seattle attendee Warren Parsons captured the entire two-day show in crisp and loving detail. Presenting, for your viewing pleasure, An Event Apart Seattle 2009 – a set on Flickr.
When you’ve paged your way through those, have a gander at Think Brownstone’s extraordinary sketches of AEA Seattle.
Recent history taught us, if something is simple, makes sense and it is easy to use, it will most likely become a standard. … Through the increasing expansion of Twitter, the at-sign (@) has become a standard reference for a sender’s name. … Another change (introduced 2007) was the usage of hashtags (#). …
To help distinguish the source of information from a person, I propose we start using the following pattern:
The Web Validator validates your HTML and CSS and verifies the proper use of microformats, including hCard and hCalendar, for single pages or entire websites.
The Web Standards Advisor checks for subtleties of standards compliance in nine different areas—everything from structural use of headings to proper ID, class, and <div> element use. Nonstandard practices are flagged and reported in the Dreamweaver Results panel for quick code correction. A full report with more details and suggested fixes is also generated.
How did it get here?
Over coffee in New Orleans last year, WebAssist’s Joseph Lowery and I chatted about a fantasy product that could improve the markup of even the most experienced front-end coder. The benefits were obvious. After all, better markup means lighter, faster web pages whose content is easier for search engines (and thus people) to find.
The product would look over your shoulder and notice things.
If you were using a class when you might be better off using an ID (and vice-versa), the fantasy product would cough gently and tell you.
If you skipped a heading level—say, if you had h4s and h6s but no h5 on your site—it would discreetly whisper in your ear.
If, on an old site (or sadly, on a new one) you used class names that were visual instead of semantic (i.e. class=”big_yellow_box” instead of class=”additional_info”), it would quietly let you know about it.
To me, this was a fantasy product, because so many of these things seem to require human judgement. I didn’t think programmers could develop algorithms capable of simulating that level of judgement. Joseph Lowery took my doubt as a challenge.
A year of collaborative back-and-forth later, Jeffrey Zeldman’s Web Standards Advisor is a working 1.0 product.
How good is it?
I ran Jeffrey Zeldman’s Web Standards Advisor on the four-year-old markup of this site’s current blog layout, and discovered embarrassing mistakes that don’t show up on validators. (I haven’t fixed those mistakes yet, by the way. For fun, or extra credit, see if you can figure out what they are.)
Then I ran the product on several new sites coded by some of the best CSS and markup people in the business, and found a surprising quantity of mistakes there, as well. Nobody’s perfect—not even the best coders.
Some of the errors the product found were mere errors of style, but were still worth correcting, if only to set a good example for those who view source on your sites. Other errors the product revealed could affect how easy it is for people to find a site’s content. Fixing such errors is a business necessity.
Some issues are purely judgement calls: is it okay to sometimes use <b> instead of <strong>? When is it perfectly fine to skip a heading level? To address those subtleties, there is a wiki where such topics are discussed, and “error” messages link to the relevant topics in the wiki, so you can click straight through to the online discussion.
Who is it for?
Jeffrey Zeldman’s Web Standards Advisor will help beginning and intermediate coders write smarter, more compliant markup that makes site content easier to find.
It will help coders at any level (including expert) who use Dreamweaver as a primary web development tool, and who know about web standards but don’t spend all day thinking about them. Now you don’t have to—and you can still create leaner sites that work for more people, and whose content is easier to find.
Site owners might run the product on their site, to see how compliant it is and how findable their markup allows their content to be.
But what about many people reading this website, who write their XHTML and CSS by hand, and who rightfully consider themselves standardistas? That’s right. What about you?
You aren’t the primary customer, but you might find the product useful. I’m a hand-coder and always will be. I own Dreamweaver mainly because it comes with Adobe CS3 and CS4. Installing Jeffrey Zeldman’s Web Standards Advisor is a no-brainer, and running it on my work (or that of people working for me) turns up enough surprises to more than justify the time and expense.
Plus, after you use it to clean up your own, small, embarrassing errors of markup, you can run it on your heroes’ websites and revel in their mere mortality.
I have a small financial interest and a gigantic brand interest in it. If it’s a weak product, it reflects badly on me, my agency, my conference, my books, and possibly even the very category of web standards. I therefore have a huge stake in making sure it’s a good product—that it’s easy to use, meets real needs now, and evolves in response to customer feedback and the slow but steady evolution of standards. (XHTML 2? HTML 5? More microformats? Stay tuned.)