For those who couldn’t be there, and for those who were there and seek to savor the memories, here is An Event Apart Chicago, all wrapped up in a pretty bow:

AEA Chicago – official photo set

By John Morrison, subism studios llc. See also (and contribute to) An Event Apart Chicago 2009 Pool, a user group on Flickr.

A Feed Apart Chicago

Live tweeting from the show, captured forever and still being updated. Includes complete blow-by-blow from Whitney Hess.

Luke W’s Notes on the Show

Smart note-taking by Luke Wroblewski, design lead for Yahoo!, frequent AEA speaker, and author of Web Form Design: Filling in the Blanks (Rosenfeld Media, 2008):

1. Jeffrey Zeldman: A Site Redesign
2. Jason Santa Maria: Thinking Small
3. Kristina Halvorson: Content First
4. Dan Brown: Concept Models -A Tool for Planning Websites
5. Whitney Hess: DIY UX -Give Your Users an Upgrade
6. Andy Clarke: Walls Come Tumbling Down
7. Eric Meyer: JavaScript Will Save Us All (not captured)
8. Aaron Gustafson: Using CSS3 Today with eCSStender (not captured)
9. Simon Willison: Building Things Fast
10. Luke Wroblewski: Web Form Design in Action (download slides)
11. Dan Rubin: Designing Virtual Realism
12. Dan Cederholm: Progressive Enrichment With CSS3 (not captured)
13. Three years of An Event Apart Presentations

Note: Comment posting here is a bit wonky at the moment. We are investigating the cause. Normal commenting has been restored. Thank you, Noel Jackson.

Short URL: zeldman.com/?p=2695

Filed under: A List Apart, An Event Apart, Appearances, Authoring, Browsers, CSS, Career, Chicago, Code, Community, Compatibility, DOM, Design, Education, Fonts, Formats, HTML, HTML5, Happy Cog™, Information architecture, Jason Santa Maria, Markup, Real type on the web, Scripting, Search, Standards, State of the Web, architecture, art direction, bugs, cities, conferences, content, content strategy, creativity, development, downloads, editorial, engagement, eric meyer, events, flickr, glamorous, industry, javascript, photography, social networking, speaking, spec

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.

For instance, in the page entitled “Use What Is There,” Bert says:

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.

I urge everyone to read “What is a Good Standard?“, and I thank my friend Tantek for pointing it out to me.

Tags: W3C, design, principles, bertbos, maintainability, accessibility, extensibility, learnability, simplicity, specs, standards, css, markup, code, languages, web, webdesign, webstandards, webdevelopment, essays

Filed under: Advocacy, Applications, Browsers, CSS, Code, Compatibility, DOM, Design, Markup, Standards, State of the Web, W3C, Web Design, Web Design History, Web Standards, architecture, creativity, spec, wisdom

In Issue No. 288 of A List Apart, for people who make websites: Margit Link-Rodrigue advises us to integrate accessibility with front-end development instead of treating it as an afterthought—an item on a checklist. And Joe Clark analyzes why some forms of writing resist being expressed as semantic HTML.

Unwebbable

by JOE CLARK

It’s time we came to grips with the fact that not every “document” can be a semantic “web page.” Some forms of writing just cannot be expressed in HTML—or they need to be bent and distorted to do so. But for once, XML can help. Joe Clark explains.

The Inclusion Principle

by MARGIT LINK-RODRIGUE

To make accessible design an organic element of front-end development, we must free our thinking from the constraints we associate with accessible design and embrace the inclusion principle. Margit Link-Rodrigue tells us how.

Tags: alistapart, semantics, accessibility, design, webdesign, markup, XML, link-rodrigue, joeclark

Filed under: A List Apart, Accessibility, Design, Markup

Comments off.

An e-mail 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.

Read more

• Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 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

Tags: HTML5, HTML 5, spec, nav, ambiguity, markup, W3C, WHATWG, Hixie, Ian Hickson, Allsopp, John Allsopp, A List Apart, ALA, alistapart

Filed under: HTML, HTML5, Markup, Standards, State of the Web, spec

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.

Read more

• Web Fonts, HTML 5 Roundup: Worthwhile reading on the hot new web font proposals, and on HTML 5/CSS 3 basics, plus a demo of advanced HTML 5 trickery. — 20 July 2009
• HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 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

Tags: W3C, XML, XHTML, HTML, HTML5, WTF

Filed under: HTML, HTML5, Markup, Web Design History, Web Standards, XHTML

It’s outrageous that the CSS standard created in 1996 is not properly supported in Outlook 2010. Let’s do something about it.

Hundreds of millions use Microsoft Internet Explorer to access the web, and Microsoft Outlook to send and receive email. As everyone reading this knows, the good news is that in IE8, Microsoft has released a browser that supports web standards at a high level. The shockingly bad news is that Microsoft is still using the Word rendering engine to display HTML email in Outlook 2010.

What does this mean for web designers, developers, and users? In the words of the “Let’s Fix It” project created by the Email Standards Project, Campaign Monitor, and Newism, it means exactly this:

[F]or the next 5 years your email designs will need tables for layout, have no support for CSS like float and position, no background images and lots more. Want proof? Here’s the same email in Outlook 2000 & 2010.

It’s difficult to believe that in 2009, after diligently improving standards support in IE7 and now IE8, Microsoft would force email designers to use nonsemantic table layout techniques that fractured the web, squandered bandwidth, and made a joke of accessibility back in the 1990s.

Accounting for stupidity

For a company that claims to believe in innovation and standards, and has spent five years redeeming itself in the web standards community, the decision to use the non-standards-compliant, decades-old Word rendering engine in the mail program that accompanies its shiny standards-compliant browser makes no sense from any angle. It’s not good for users, not good for business, not good for designers. It’s not logical, not on-brand, and the very opposite of a PR win.

Rumor has it that Microsoft chose the Word rendering engine because its Outlook division “couldn’t afford” to pay its browser division for IE8. And by “couldn’t afford” I don’t mean Microsoft has no money; I mean someone at this fabulously wealthy corporation must have neglected to budget for an internal cost. Big companies love these fictions where one part of the company “pays” another, and accountants love this stuff as well, for reasons that make Jesus cry out anew.

But if the rumor’s right, and if the Outlook division couldn’t afford to license the IE8 rendering engine, there are two very simple solutions: use Webkit or Gecko. They’re both free, and they both kick ass.

Why it matters

You may hope that this bone-headed decision will push millions of people into the warm embrace of Opera, Safari, Chrome, and Firefox, but it probably won’t. Most people, especially most working people, don’t have a choice about their operating system or browser. Ditto their corporate email platform.

Likewise, most web designers, whether in-house, agency, or freelance, are perpetually called upon to create HTML emails for opt-in customers. As Outlook’s Word rendering engine doesn’t support the most basic CSS layout tools such as float, designers cannot use our hard-won standards-based layout tools in the creation of these mails—unless they and their employers are willing to send broken messages to tens millions of Outlook users. No employer, of course, would sanction such a strategy. And this is precisely how self-serving decisions by Microsoft profoundly retard the adoption of standards on the web. Even when one Microsoft division has embraced standards, actions by another division ensure that millions of customers will have substandard experiences and hundreds of thousands of developers still won’t get the message that our medium has standards which can be used today.

So it’s up to us, the community, to let Microsoft know how we feel.

Participate in the Outlook’s Broken project. All it takes is a tweet.

Tags: browsers, bugs, IE8, outlook, microsoft, iranelection

Filed under: Browsers, CSS, Compatibility, Design, Marketing, Markup, Microsoft, Standards, State of the Web, The Profession, Tools, W3C, Web Standards, Working, XHTML, software, spec, style

What better way to begin 2009 than by looking at the future of web design? In Issue No. 275 of A List Apart, for people who make websites, we study the promise and problems of HTML 5, and chart a path toward mobile CSS that works.

Return of the Mobile Style Sheet

by DOMINIQUE HAZAËL-MASSIEUX

At least 10% of your visitors access your site over a mobile device. They deserve a good experience (and if you provide one, they’ll keep coming back). Converting your multi-column layout to a single, linear flow is a good start. But mobile devices are not created equal, and their disparate handling of CSS is like 1998 all over again. Please your users and tame their devices with handheld style sheets, CSS media queries, and (where necessary) JavaScript or server-side techniques.

Semantics in HTML 5

by JOHN ALLSOPP

The BBC’s dropping of hCalendar because of accessibility and usability concerns demonstrates that we have pushed the semantic capability of HTML far beyond what it can handle. The need to clearly and unambiguously add rich, meaningful semantics to markup is a driving goal of the HTML 5 project. Yet HTML 5 has two problems: it is not backward compatible because its semantic elements will not work in 75% of our browsers; and it is not forward compatible because its semantics are not extensible. If “making up new elements” isn’t the solution, what is?

Tags: HTML5, mobileCSS, webstandards, alistapart, johnallsopp, W3C, Dominique Hazael-Massieux

Filed under: A List Apart, Accessibility, Advocacy, Design, HTML5, Markup, Standards, Web Design, Web Standards, mobile