It seems like only yesterday that the HTML5 Super Friends asked the HTML5 working groups to rethink footer’s content model to avoid web developer misuse and frustration. Okay, it wasn’t yesterday, it was Monday. Close enough. Today comes word that footer is indeed being redefined as we requested. This is a wonderful usability improvement to HTML5, and we salute the working group(s) for listening and acting.
The HTML5 specification runs on for over 900 pages, and much of what it covers, while vital to browser makers, is meaningless to people who create websites. If thousands of irrelevant details in the HTML5 spec have you crossing your eyes and crying for Mama, Michael™ Smith’s HTML 5: The Markup Language is just what the HTML5 doctor ordered: lean, clean, and content-author-focused. Until there’s a plain-language HTML5 Pocket Guide, Smith’s edited presentation of the spec will do. (It’s also available in a single page format.)
ShortURL: zeldman.com/?p=2561
Half of standards making is minutia; the other half is politics. Rightly or wrongly, I’ve long suspected that Atom was born, not of necessity, but because of conflicts between the XML crowd and the founders of RSS. Likewise, rightly or wrongly, I reckoned HTML5 was at least partly Hixie’s revenge against XHTML served as text/html.
And then a funny thing happened. Some friends and I gathered at Happy Cog’s New York studio to hash out the pros and cons of HTML5 from the perspective of semantic-markup-oriented web designers (as opposed to the equally valid perspectives of browser engineers and web application developers—the two perspectives that have primarily driven the creation of HTML 5).
Our first task was to come to a shared understanding of the spec. During the two days and nights we spent poring over new and changed semantic elements, we discovered that many things we had previously considered serious problems were fixable issues related to language.
Some of these language problems are trivial indeed. For instance, on both the WHATWG and W3C sites, the specification is sometimes called “HTML 5” (with a space) and sometimes called “HTML5” (with no space). A standard should have a standard name. (Informed of this problem, Hixie has removed the space everywhere in the WHATWG version of the spec.)
Likewise, as an end-user, I found it confusing to be told that there is an “HTML5 serialization of HTML 5,” let alone an “XHTML 5 version of HTML5.” I requested that the two serializations be referred to as “HTML” and “XHTML”—emphasizing the distinction between the two kinds of syntax rather than drawing needless attention to version numbers. (Again, Hixie promptly updated the spec.)
Some language problems are tougher—but still eminently fixable, because they are language problems that mar the presentation of good ideas, not bad ideas that require rethinking.
For example, in order to choose suitable names for the new semantic elements in HTML 5, Hixie analyzed classnames on thousands of websites to see what web designers and developers were already doing. If many designers and developers use classnames like “header” and “footer” to contain certain kinds of content, then HTML 5 should use these labels, too, Hixie and his colleagues reasoned. Doing so would make the purpose of the new elements intuitively obvious to working web professionals, removing the learning curve and encouraging proper element use from the get-go.
It’s a beautiful theory that comes straight out of Bert Bos’s W3C Design Principles. There’s just one problem. Header, and especially footer, behave differently from what their names will lead web designers and developers to expect. Developers will use it for the footer of the page—not for the footer of each section. And they will be frustrated that the footer in HTML5 forbids navigation links. After all, the footer at the bottom of web pages almost always includes navigation links.
To avoid misuse and frustration, the content model of footer should change to match that of header, so that it may be used concurrently as a template level element (the expected use) and a sub-division of section (the new use). Alternately, the element’s name should be changed (to almost anything but “footer”). Expanding the content model is clearly the better choice.
HTML5 is unusual in many ways. Chiefly, it is the first HTML created in the time of web applications. It is also the first to be initiated outside the W3C (although it now develops there in parallel).
Not surprisingly in a specification that goes on for 900 pages, there are at least a dozen places in HTML5 where a thoughtful standardista might request clarification, suggest a change, or both. My friends and I have taken a stab at this ourselves, and will soon publish our short list of recommendations and requests for clarification.
Nevertheless, the more I study the direction HTML5 is taking, the better I like it. In the words of the HTML5 Super Friends, “Its introduction of a limited set of additional semantic elements, its instructions on how to handle failure, and its integration of application development tools hold the promise of richer and more consistent user experiences, faster prototyping, and increased human and machine semantics.”
[4:47 PM EST] Calling all cars! The HTML5 Super Friends declaration of support is now live, as is the Super Friends Guide to HTML5 Hiccups (i.e. our technical recommendations).
ShortURL: zeldman.com/?p=2438
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:
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.
@ilovetypography tackles the question we’ve been pondering. After setting out what web designers want versus what type designers and foundries want, the author summarizes various new and old proposals (“I once heard EOT described as ‘DRM icing on an OpenType cake.’”) including Tal Leming and Erik van Blokland‘s .webfont, which is gathering massive support among type foundries, and David Berlow’s permissions table, announced here last week.
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.)
Just like it says.
[tags]@font-face, berlow, davidberlow, CSS, permissionstable, fontbureau, webfonts, webtypography, realtypeontheweb, HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards, typography[/tags]
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:”
[I]f you were building a mark-up language from scratch you would include elements like
footer,headerandnav(actually, HTML 2 had amenuelement for navigation that was deprecated in 4.01).You probably wouldn’t have loads of computer science oriented elements like
kbd,var,sampin preference to the structural elements that people “fake” with classes. Things liketabindexwouldn’t be there, as we all know that if you use properly structured code you don’t need to change the tab order, andaccesskeywouldn’t make it because it’s undiscoverable to a user and may conflict with assistive technology. Accessibility would have been part of the design rather than bolted on.But we know that now; we didn’t know that then. And HTML 5 aims to be compatible with legacy browsers and legacy pages. …
There was a cartoon in the ancient satirical magazine Punch showing a city slicker asking an old rural gentleman for directions to his destination. The rustic says “To get there, I wouldn’t start from here”. That’s where we are with HTML. If we were designing a spec from scratch, it would look much like XHTML 2, which I described elsewhere as “a beautiful specification of philosophical purity that had absolutely no resemblance to the real world”, and which was aborted by the W3C last week.
The third point is Lawson’s key insight, for it illuminates the dilemma faced by HTML 5 or any other honest effort to move markup forward. Neither semantic purity nor fault-tolerance will do, and neither approach can hope to satisfy all of today’s developers.
A markup based on what we now know, and can now do thanks to CSS’s power to disconnect source order from viewing experience, will be semantic and accessible, but it will not be backward compatible. That was precisely the problem with XHTML 2, and it’s why most people who build websites for a living, if they knew enough to pay attention to XHTML 2, soon changed the channel.
XHTML 2 was conceived as an effort to start over and get it right. And this doomed it, because right-wing Nativists will speak Esperanto before developers adopt a markup language that breaks all existing websites. It didn’t take a Mark Pilgrim to see that XHTML 2 was a dead-end that would eventually terminate XHTML activity (although Mr Pilgrim was the first developer I know to raise this point, and he certainly looks prescient in hindsight).
It was in reaction to XHTML 2’s otherworldliness that the HTML 5 activity began, and if XHTML suffered from detachment from reality, HTML 5 is too real. It accepts sloppiness many of us have learned to do without (thereby indirectly and inadvertently encouraging those who don’t develop with standards and accessibility in mind not to learn about these things). It is a hodgepodge of semantics and tag soup, of good and bad markup practices. It embraces ideas that logically cancel each other out. It does this in the name of realism, and it is as admirable and logical for so doing as XHTML 2 was admirable and logical in its purity.
Neither ethereal purity nor benign tolerance seems right, so what’s a spec developer to do? They’re damned either way—which almost suggests that the web will be built with XHTML 1.0 and HTML 4.01 forever. Most importantly for our purposes, what are we to do?
As the conversation about HTML 5 and XHTML has played out this week, I’ve felt like Regan in The Exorcist, my head snapping around in 360 degree arcs as one great comment cancels out another.
In a private Basecamp discussion a friend said,
Maybe I’m just confused by all the competing viewpoints, but the twisted knots of claim and counterclaim are getting borderline Lovecraftian in shape.
Another said,
[I] didn’t realize that WHATWG and the W3C’s HTML WG were in fact two separate bodies, working in parallel on what effectively amounts to two different specs [1, 2—the entire thread is actually worth reading]. So as far as I can tell, if Ian Hickson removes something from the WHATWG spec, the HTML WG can apparently reinsert it, and vice versa. [T]his… seems impossibly broken. (I originally used a different word here, but, well, propriety and all that.)
Such conversations are taking place in rooms and chatrooms everywhere. The man in charge of HTML 5 appears confident in its rightness. His adherents proclaim a new era of loaves and fishes before the oven has even finished preheating. His articulate critics convey a palpable feeling of crisis. All our hopes now hang on one little Hobbit. What do we do?
As confused as I have continually felt while surfing this whirlwind, I have never stopped being certain of two things:
[tags]HTML5, HTML4, HTML, W3C, WHATWG, markup, webstandards[/tags]
AN EMAIL from Chairman Hickson resolves an ambiguity in the nav element of HTML 5.
One of the new things HTML 5 sets out to do is to provide web developers with a standardized set of semantic page layout structures. For example, it gives us a nav element to replace structures like div class="navigation".
This is exciting, logical, and smart, but it is also controversial.
The controversy is best expressed in John Allsopp’s A List Apart article, Semantics in HTML 5, where he worries that the new elements may not be entirely forward-compatible, as they are constrained to today’s understanding of what makes up a page. An extensible mechanism, although less straightforward, would offer more room to grow as the web evolves, Allsopp argues.
We’re pretty sure Ian Hickson, the main force behind HTML 5, has heard that argument, but HTML 5 is proceeding along the simpler and more direct line of adding page layout elements. The WHAT Working Group Mr Hickson chairs has solicited designer and developer opinion on typical web page structures in order to come up with a short list of new elements in HTML 5.
nav is one of these elements, and its description in the spec originally read as follows:
The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links. Not all groups of links on a page need to be in a nav element — only sections that consist of primary navigation blocks are appropriate for the nav element.
The perceived ambiguity was expressed by Bruce Lawson (AKA HTML 5 Doctor) thusly:
“Primary navigation blocks” is ambiguous, imo. A page may have two nav blocks; the first is site-wide naviagtion (“primary navigation”) and within-page links, eg a table of contents which many would term “secondary nav”.
Because of the use of the phrase “primary navigation block” in the spec, a developer may think that her secondary nav should not use a
Chairman Hickson has resolved the ambiguity by changing “primary” to “major” and by adding an example of secondary navigation using nav.
When Apple chose KHTML rather than Mozilla Gecko as the basis for its Safari browser, some of us in the web standards community scratched our heads. Sure, KHTML, the rendering engine in Konqueror, was open-source and standards-compliant. But, at the time, Gecko’s standards support was more advanced, and Gecko-based Mozilla, Camino, and even Netscape 6 felt more like browsers than Konqueror. Gecko browsers had the features, the comparative maturity, and the support of the standards community. Apple’s adoption of KHTML, and creation of a forked version called Webkit, seemed puzzling and wrong.
Yet, thanks largely to the success of the iPhone, Webkit (Apple’s open source version of KHTML) 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. Had Apple chosen Gecko, they might not have been able to so powerfully influence mainstream consumer opinion, because the fully formed, distinctly mature Gecko brand and experience could easily have overshadowed and constrained Apple’s contribution. (Not to mention, tolerating external constraint is not a game Apple plays.)
Just how has mobile Safari, a relative latecomer to the world of standards-based browsing, been able to make a difference, and what difference has it made?
Firefox and Opera were wonderful before any Webkit-based browser reached maturity, but Firefox and Opera were and are non-mainstream tastes. Most people use Windows without thinking much about it, and most Windows users open the browser that comes with their operating system, again without too much thought. This doesn’t make them dumb and us smart. We are interaction designers; they are not.
Thus, the paradox: even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a comparatively poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. If you knew enough to want Firefox and Opera, those browsers delivered features and experience that confirmed the wisdom of your choice. If you didn’t know to want them, you didn’t realize you were missing anything, because folks reading this page sweated like Egyptian pyramid builders to make sure you had a good experience despite your browser’s flaws.
Firefox and Opera are great browsers that have greatly advanced the cause of web standards, but because they are choices in a space where most people don’t make choices, their power to convert is necessarily somewhat truncated. The millions mostly don’t care what happens on their desktop. It’s mostly not in their control. They either don’t have a choice or don’t realize they have one, and their expectations have been systematically lowered by two decades of unexciting user experience.
By contrast, the iPhone functions in a hot realm where consumers do make choices, and where choices are badges. Of course many people are forced economically to choose the cheap or free phone that comes with their mobile service. But many others are in a position to select a device. And the iPhone is to today’s urban professional gym rat what cigarettes and martinis were to their 1950s predecessors. You and I may claim to choose a mobile device based on its features, but the upwardly mobile (pardon the pun), totally hot person standing next to us in the elevator may choose their phone the same way they choose their handbag. And now that the iPhone sells for $99, more people can afford to make a fashion decision about their phone—and they’ll do it.
Although there were great phones before the iPhone, and although the iPhone has its detractors, it is fair to say that we are now in a Mobile 2.0 phase where people expect more than a Lynx-like experience when they use their phone to access the internet. Mobile Safari in iPhone, along with the device’s superior text handling thanks to Apple and Adobe technologies, is changing perceptions about and expectations of the web in the same way social networking did, and just at the historical moment when social networking has gone totally mainstream.
Oprah’s on Twitter, your mom’s on Twitter, and they’re either using an iPhone or a recently vastly upgraded Palm or Blackberry that takes nearly all of its cues from the iPhone. Devices that copy the iPhone of course mostly end up selling the iPhone, the same way Bravo’s The Fashion Show would mostly make you miss Project Runway if you even watched The Fashion Show, which you probably haven’t.
Safari isn’t perfect, and Mobile Safari has bugs not evident in desktop Safari, but Webkit + Apple = secret sauce selling web standards to a new generation of consumers and developers.
[tags]webdesign, webstandards, design, standards, browsers, CSS, webkit, gecko, mozilla, firefox, opera, safari, mobile, mobilesafari, iphone[/tags]
It has only been a few days but I am already sick of the “XHTML is bullshit, man!” crowd 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.
A coterie of well-informed codemeisters, from ppk to Ian Hickson, has always had legit beefs with XHTML, the most persuasive of which was Hickson’s:
It is suggested that HTML delivered as text/html is broken and XHTML delivered as text/xml is risky, so authors intending their work for public consumption should stick to HTML 4.01, and authors who wish to use XHTML should deliver their markup as application/xhtml+xml.
This problem always struck me as more theoretical than real, but I pointed it out in every edition of Designing With Web Standards and left it to the reader to decide. When I wrote the first edition of the book, some versions of Mozilla and IE would go into Quirksmode in the presence of HTML 4, breaking CSS layouts. To me, that was a worse problem than whatever was supposed to be scary or bad about using well-formed XHTML syntax while delivering it as HTML all browsers could support.
The social benefit of rethinking markup sealed the deal. XHTML’s introduction in 2000, and its emphasis on rules of construction, gave web standards evangelists like me a platform on which to hook a program of semantic markup replacing the bloated and unsustainable tag soup of the day. The web is better for this and always will be, and there is much still to do, as many people who create websites still have not heard the call.
A few who became disenchanted with XHTML early retreated to HTML 4, and as browsers stopped going into Quirksmode in its presence, valid, structural HTML 4 became a reasonable option again. But both HTML 4 and XHTML 1 were document languages, not transactional languages. They were all noun, and almost no verb. So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.
And guess what? HTML 5 is as controversial today as XHTML was in 2000, and there are just as many people who worry that a specification of which they don’t entirely approve is being shoved down their throats by an “uncaring elite.” Only this time, instead of the W3C, the “uncaring elite” is Mr Hickson, with W3C rubber stamp, and input from browser makers, including his employer.
All of this is to say that XHTML is not dead (XHTML 2 is dead, thank goodness), and HTML 5 is not here yet. Between now and 2022, we have plenty of time to learn about HTML 5 and contribute to the discussion—and browser makers have 13 years to get it right. Which is also to say all of us—not just those who long ago retreated to HTML 4, or who became fans of HTML 5 before it could even say “Mama”—are entitled to be pleased that standard markup activity will now have a single focus, rather than a dual one (with XHTML 2 the dog spec that no one was willing to mercy-kill until now).
Entitled to be pleased is not the same as entitled to gloat and name call. As DN put it in comment-44126:
What is really rather aggravating is how many people are using this news as a stick with which to beat any developer or freelancer who’s had the audacity to study up on and use XHTML in good faith–or even, much to the horror of the Smug Knowbetters, admire XHTML’s intelligible markup structure–for the brand-new-minted sin of doing the most with XHTML that’s possible. The ‘unofficial Q&A’ is ripe with that kind of condescension. …[D]on’t pin users (front-end developers are merely users of specifications) with Microsoft’s failure to support the correct MIME type.
[tags]HTML, HTML5, W3C, WTF, XHTML, XML[/tags]
Firefox developers who were initially alerted to a problem on this page, please view the Firefox test page and the page that explains its use. — JZ
The web’s future isn’t what the web’s past cracked it up to be. 1999: XML is the light and XHTML is the way. 2009: XHTML is dead—kind of.
From the W3C news archive for 2 July 2009:
XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5
2009-07-02: Today the Director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C’s position regarding the future of HTML. A FAQ answers questions about the future of deliverables of the XHTML 2 Working Group, and the status of various discussions related to HTML. Learn more about the HTML Activity. (Permalink)
Please note that this thread has been updated with useful comments and links that help make sense of the emergence of HTML 5, the death of XHTML 2.0, and what designers and developers need to know about the present and future of web markup.
[tags]W3C, XML, XHTML, HTML, HTML5, WTF[/tags]
A “Not Safe for Work” Tag has been proposed for HTML 5:
One of the most common descriptive notes people have to write using text when they post links or images to blogs, comments or anywhere in HTML is to say “this link is not safe for work” or simply “NSFW”. By adding the <NSFW> tag, this could be made much simpler and standardized. Browsers could then have an option to automatically hide all <NSFW> content. A tag is preferred to an attribute since it could then also be used around content and not just links.
Examples:
<nsfw><a href=”http://www.example.com”>Pics here!</a></nsfw>
<nsfw><img src=”badkitten.jpg”></nsfw>
(Via Bruce Lawson)
Drew McLellan of The Web Standards Project thinks it’s a nice idea that won’t work:
@brucel we looked into #nsfw in microformats. It’s an unworkable minefield. #
it’s used when linking to something that you might want to save until you get home. e.g. http://ampleboobies.info (NSFW) #
So a browser could conceivably be configured not to follow links or display content tagged nsfw. Sounds a good idea, but unworkable. #
The use of tags (rather than CSS and JavaScript) to hide or show content is an intriguing and controversial aspect of HTML 5. It’s intriguing because using a standard tag—instead of writing custom CSS and JavaScript that someone else may someday have to maintain—potentially simplifies web development and maintenance, bringing advanced techniques of content presentation to more sites for less money. It’s controversial because it sticks presentation and behavior back in markup, after we all just spent a decade separating site structure and semantics from behavior and presentation.
We’re going to be following these developments and trying to make buzzword-free sense of them for you.
[tags]standards, webstandards, HTML, HTML5, tags, NSFW, W3C[/tags]
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.
Tim O’Reilly: Google Bets Big on HTML 5
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]
In Issue No. 284 of A List Apart, for people who make websites:
by THIERRY KOBLENTZ
Have you ever wanted to resize a video on the fly, scaling it as you would an image? Using intrinsic ratios for video and some padding property magic, you can. Thierry Koblentz shows us how.
by SCOTT BOMS
Does every day feel like a bad day? Blurry boundaries between work and home, and the “always on” demands of the web can lead to depression and burnout. Learn the signs of burnout and how to maintain your bliss.
And don’t miss this issue’s Editor’s Choice:
by ERIN LYNCH
New to A List Apart? Welcome! ALA’s own Erin Lynch suggests a few good places to start reading. (Originally ran: September 12, 2006.)
Comments off.
Working on the footer of zeldman.com redesign. Once footer is done, going to adjust header and Twitter sidebar blip.
[tags]zeldman, zeldman.com, design, redesign, css[/tags]
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.
Still can’t get enough of that AEA stuff? Check out the official AEA Seattle photo pool on Flickr.
Wonder what people said about the event? Check these Twitter streams: AEA and AEA09.
And here are Luke W’s notes on the show.
Our thanks to the photographers, sketchers, speakers, and all who attended.
[tags]aneventapart, aeaseattle09, AEA, AEA09, Seattle, webdesign, conference, Flickr, sets, Twitter, photos, illustrations, sketches, aneventapart.com[/tags]
City of Puget Sound, Jimi Hendrix, and the space needle, here I come for An Event Apart Seattle 2009—two days of peace, love, design, code, and content.
[tags]seattle, aneventapart, webdesign, webstandards, design, conference, conferences, webdesign conference, webdesign conferences, standards, IA, UX, ericmeyer, jeffreyzeldman, zeldman, meyerweb[/tags]