Kiss My Classname

SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.

I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.

I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.

Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.

The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.

Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.

The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.

You’re welcome: cutting the mustard then and now.

EVERY TIME I hear a young web developer cite the BBC’s forward-thinking practice of “cutting the mustard,” by which they mean testing a receiving web device for certain capabilities before serving content, I remember when my team and I at The Web Standards Project invented that very idea. It’s a million web years ago, by which I mean fourteenish human years ago, so nobody remembers but me and some other long toothed grayhairs, plus a few readers of the first edition of Designing With Web Standards. But I like you, so I will tell you the story.

Back then in those dark times, it was common practice for web developers to create four or more versions of the same website—one for each browser then in wide use. It was also a typical (and complementary) practice to send server-side queries to figure out which browser was about to access a site’s content, and then send the person using that browser to the site version that was configured for her browser’s particular quirks, proprietary tags, and standards compliance failings.

The practice was called “browser detection.” Nobody but some accessibility advocates had ever questioned it—and the go-go dot-com era had no time or care for those folks.

But we at The Web Standards Project turned everything on its head. We said browsers should support the same standards instead of competing to invent new tags and scripting languages. We said designers, developers, and content folks should create one site that was accessible to everyone. In a world like that, you wouldn’t need browser detection, because every browser and device that could read HTML would be able to feast on the meat of your site. (And you’d have more meat to share, because you’d spend your time creating content instead of crafting multiple versions of the same site.)

To hasten that world’s arrival, in 2001 we launched a browser upgrade campaign. Those who participated (example participant here) employed our code and content to send their users the message that relatively standards-compliant browsers were available for every platform, and inviting them to try one. Because if more people used relatively standards-compliant browsers, then we could urge more designers and developers to create their sites with standards (instead of quirks). And as more designers and developers did that, they’d bump against still-unsolved standards compliance conundrums, enabling us to persuade browser makers to improve their standards compliance in those specific areas. Bit by bit, stone by stone, this edifice we could, and would, erect.

The code core of the 2001 browser upgrade campaign was the first instance of capability detection in place of browser detection. Here’s how it worked. After creating a valid web page, you’d insert this script in the head of your document or somewhere in your global JavaScript file:

if (!document.getElementById) {
window.location =

We even provided details for various flavors of markup. In HTML 4 or XHTML 1 Transitional documents, it looked like this:

<script type="text/javascript" language="javascript">
<!-- //
if (!document.getElementById) {
window.location =
// -->

In STRICT documents, you’d either use a global .js file, or insert this:

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
// -->

You could also just as easily send visitors to an upgrade page on your own site:

if (!document.getElementById) {
window.location =

Non-WaSP members (at the time) J. David Eisenberg, Tantek Çelik, and Jim Heid contributed technical advice and moral support to the effort. WaSP sysadmin Steven Champeon, the inventor of progressive enhancement, made it all work—under protest, bless him. (Steve correctly believed that all web content should always be available to all people and devices; therefore, in principle, he disliked the upgrade campaign, even though its double purpose was to hasten the arrival of truly standards-compliant browsers and to change front-end design and development from a disrespected world of hacks to a sustainable and professional craft. ((See what I did there? I’m still respectfully arguing with Steve in my head.)))

Discovering rudimentary DOM awareness or its absence in this fashion was the first time web developers had tested for capabilities instead of chasing the dragon in a perpetual and futile attempt to test for every possible browser flavor and version number. It was the grandparent, if you will, of today’s “cutting the mustard.” And it is analogous as well to the sensible responsive design practice of setting breakpoints for the content, instead of trying to set appropriate breakpoints for every possible device out there (including all the ones that haven’t been invented yet).

Which reminds us that the whole point of web standards was and is forward compatibility—to create content that will work not only in yesterday’s and today’s browsers and devices, but in all the wonderful devices that have yet to be invented, and for all the people of the world. You’re welcome.

—CHICAGO, Westin Chicago River Hotel, 1 September 2015

Hat tip: John Morrison

HTML5, CSS3, UX, Design: Links from An Event Apart Boston 2011

Meeting of the Minds: Ethan Marcotte and AEA attendee discuss the wonders of CSS3. Photo by the incomparable Jim Heid.

Meeting of the Minds: Ethan Marcotte and AEA attendee discuss the wonders of CSS3. Photo by the incomparable Jim Heid.

THE SHOW IS OVER, but the memories, write-ups, demos, and links remain. Enjoy!

An Event Apart Boston 2011 group photo pool

Speakers, attendees, parties, and the wonders of Boston, captured by those who were there.

What Every Designer Should Know (a)

Jeremy Keith quite effectively live-blogs my opening keynote on the particular opportunities of Now in the field of web design, and the skills every designer needs to capitalize on the moment and make great things.

The Password Anti-Pattern

Related to my talk: Jeremy Keith’s original write-up on a notorious but all-too-common practice. If your boss or client tells you to design this pattern, just say no. Design that does not serve users does not serve business.

What Every Designer Should Know (b)

“In his opening keynote … Jeffrey Zeldman talked about the skills and opportunities that should be top of mind for everyone designing on the Web today.” Luke Wroblewski’s write-up.

Whitney Hess: Design Principles — The Philosophy of UX

“As a consultant, [Whitney] spends a lot of time talking about UX and inevitably, the talk turns to deliverables and process but really we should be establishing a philosophy about how to treat people, in the same way that visual design is about establishing a philosophy about how make an impact. Visual design has principles to achieve that: contrast, emphasis, balance, proportion, rhythm, movement, texture, harmony and unity.” In this talk, Whitney proposed a set of 10 principles for UX design.

Veerle Pieters: The Experimental Zone

Live blogging by Jeremy Keith. Veerle, a noted graphic and interaction designer from Belgium, shared her process for discovering design through iteration and experimentation.

Luke Wroblewski: Mobile Web Design Moves

Luke’s live awesomeness cannot be captured in dead written words, but Mr Keith does a splendid job of quickly sketching many of the leading ideas in this key AEA 2011 talk.

See also: funky dance moves with Luke Wroblewski, a very short video I captured as Luke led the crowd in the opening moves of Michael Jackson’s “Thriller.”

Ethan Marcotte: The Responsive Designer’s Workflow (a)

“The next talk here at An Event Apart in Boston is one I’ve really, really, really been looking forward to: it’s a presentation by my hero Ethan Marcotte.”

Ethan Marcotte: The Responsive Designer’s Workflow (b)

Ethan’s amazing talk—a key aspect of design in 2011 and AEA session of note—as captured by the great Luke Wroblewski.

An Event Apart: The Secret Lives of Links—Jared Spool

“In his presentation at An Event Apart in Boston, MA 2011 Jared Spool detailed the importance and role of links on Web pages.” No writer can capture Jared Spool’s engaging personality or the quips that produce raucous laughter throughout his sessions, but Luke does an outstanding job of noting the primary ideas Jared shares in this riveting and highly useful UX session.

An Event Apart: All Our Yesterdays—Jeremy Keith

Luke W: “In his All Our Yesterdays presentation at An Event Apart in Boston, MA 2011 Jeremy Keith outlined the problem of digital preservation on the Web and provided some strategies for taking a long term view of our Web pages.”

Although it is hard to pick highlights among such great speakers and topics, this talk was a highlight for me. As in, it blew my mind. Several people said it should be a TED talk.

An Event Apart: From Idea to Interface—Aarron Walter

Luke: “In his Idea to Interface presentation at An Event Apart in Boston, MA 2011 Aarron Walter encouraged Web designers and developers to tackle their personal projects by walking through examples and ways to jump in. Here are my notes from his talk.”

Links and Resources from “From Idea to Interface”

Compiled by the speaker, links include Design Personas Template and Example, the story behind the illustrations in the presentation created by Mike Rhode, Dribble, Huffduffer, Sketchboards, Mustache for inserting data into your prototypes, Keynote Kung Fu, Mocking Bird, Yahoo Design Patterns, MailChimp Design Pattern Library, Object Oriented CSS by Nicole Sullivan and more!

An Event Apart: CSS3 Animations—Andy Clarke

“In his Smoke Gets In Your Eyes presentation at An Event Apart in Boston, MA 2011 Andy Clarke showcased what is possible with CSS3 animations using transitions and transforms in the WebKit browser.” Write-up by the legendary Luke Wroblewski.


The “Mad Men” opening titles re-created entirely in CSS3 animation. (Currently requires Webkit browser, e.g. Safari, Chrome.)

CSS3 Animation List

Anthony Calzadilla, a key collaborator on the Mad Men CSS3 animation, showcases his works.

Box Shadow Curl

Pure CSS3 box-shadow page curl effect. Mentioned during Ethan Marcotte’s Day 3 session on exploring CSS3.

Multiple CSS Transition Durations

Fascinating article by Anton Peck (who attended the show). Proposed: a solution to a key problem with CSS transitions. (“Even now, my main issue with transitions is that they use the same time-length value for the inbound effect as they do the outbound. For example, when you create a transition on an image with a 1-second duration, you get that length of time for both mousing over, and mousing away from the object. This type of behavior should be avoided, for the sake of the end-user!”)

Everything You Wanted to Know About CSS3 Gradients

Ethan Marcotte: “Hello. I am here to discuss CSS3 gradients. Because, let’s face it, what the web really needed was more gradients.”

Ultimate CSS3 Gradient Generator

Like it says.

Linear Gradients Generator

By the incomparable John Allsopp.

These sessions were not captured

Some of our best talks were not captured by note-takers, at least not to my knowledge. They include:

  1. Eric Meyer: CSS Anarchist’s Cookbook
  2. Mark Boulton: Outing the Mind: Designing Layouts That Think for You
  3. Jeff Veen: Disaster, DNA, and the Fathomless Depth of the Web

It’s possible that the special nature of these presentations made them impossible to capture in session notes. (You had to be there.)

There are also no notes on the two half-day workshop sessions, “Understand HTML5 With Jeremy Keith,” and “Explore CSS3 With Ethan Marcotte.”

What have I missed?

Attendees and followers, below please add the URLs of related educational links, write-ups, and tools I’ve missed here. Thanks!

Link Relations in HTML5

Mark Pilgrim has turned the WHAT Working Group’s blog into a tool of genuine outreach and tremendously helpful (even entertaining) information. His “Road to HTML5” column “explain[s] … new elements, attributes, and other features in the upcoming HTML 5 specification” with frank clarity and developer-focused practicality.

The April 17th installment all about link relations. And while that may sound confusing, boring, or pedantic, it is actually clear, fascinating, and quite useful. If you’ve dabbled in Microformats or used rel= in your header, you’ll recognize the material and appreciate the way HTML5 is attempting to bring order to it.

And speaking of HTML5, don’t just eat the sausage, help make it. Although not a democracy, the WHAT WG is the most open standards-making activity seen on the web. To participate (even just by following along), join the mailing list.

Gowalla My Dreams

What if Gowalla and Foursquare could communicate seamlessly with Address Book? What if Google Maps contained the postal address, company names, and primary phone numbers of every pin on the map? All this information could be marked up in Microformats and standard HTML on optional detail pages you could visit with a click from your web browser or phone. Heck, while we’re at it, let’s add Bump, an iPhone app that lets two people share contact data the same way they share DNA—except that in this case they bump iPhones.

What if every time you used Gowalla to check into or found a spot, you had the option to add that spot’s street address, company name(s), and so on to your Address Book? Imagine meeting a potential client for the first time in an unfamiliar city or neighborhood. No longer simply a passive repository of spots you create, Gowalla or Foursquare could function as a guide, helping you locate the unfamiliar address to make your meeting on time.

As you check into your meeting in reality, you could notify not only Facebook and Twitter (as you can today) but also Basecamp, which would optionally check off a radio box, marking you as having arrived at your meeting.

Something like this (and much more than this) will surely happen soon, thanks to APIs and ubiquitous standard platforms. You just feel, when you’re around people developing the best new web software, that something new is happening, and that many strands are coming together.

We used to imagine a dystopian future in which Big Brother knew everything you did. Later it was the machines that knew. We’ve been talking about ubiquitous computing for years, and we’ve pictured it happening somehow without necessarily addressing the how—that is, some of the brightest and most inspiring futurists have concerned themselves more with the ethical and cultural transformative dimensions of ubiquitous computing than with the technical nuts and bolts of how it’s supposed to get done.

I’m thinking the nuts and bolts are here. To me it seems that it is already happening. The web is the platform. HTML, CSS, JavaScript/JQuery, Ruby, and PHP are the tools. I’m thinking an uplifting (non-dystopian) ubiquitous computing is going to get done with the stuff we already use every day. Am I dreaming?

Chicago Deep Dish

Dan Cederholm and Eric Meyer at An Event Apart Chicago 2009. Photo by John Morrison.

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:

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.

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[/tags]

ALA 288: Access & semantics

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.

A List Apart, for people who make websites.

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
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[/tags]

HTML 5: nav ambiguity resolved

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.

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