Archive: March, 2012

I got an email from Ben Frain recently asking if I’d answer some questions for an upcoming article in MacUser UK about responsive design. Seeing as this is a topic I could natter on about endlessly, I happily obliged.

Here are my answers to his questions. There’s a good chance that much of this will get trimmed or altered for the final article so I figured I’d share my verbatim responses here.

When you first looked at responsive web design methodology, can you remember your initial reaction?

Before Ethan wrote his seminal article in A List Apart, I saw him giving a presentation at An Event Apart in which he outlined the ideas of responsive design. My reaction was “Yes! Yes! Yes!”

Ethan was essentially describing all-round best practices for the web in general, taking progressive enhancement to the next level. But the reason why people started paying attention was because of the timing; the idea of websites being accessed by browsers with all sorts of screen dimensions was no longer an abstract concept, it was a very real description of web browsing demographics.

So my overall reaction to responsive web design was “Finally! Maybe now web designers and developers will really start embracing the web as its own medium.” It’s no surprise that Ethan’s article in A List Apart referenced A Dao Of Web Design by John Allsopp—a piece of writing that should serve as a manifesto for everyone working on the web.

Have you been surprised that responsive web design has become the zeitgeist of the front end community for the past 18 months or so?

I’m not surprised that responsive web design has struck a chord. I only wish it could have happened sooner. While media queries are a relatively recent innovation, we’ve always had the ability to create fluid layouts. And yet web designers and developers have wilfully ignored that fact, choosing instead to create un-webby fixed-width layouts.

In taking a batch of related technologies—liquid layouts, media queries, and fluid images—and then grouping them together under one banner—responsive web design—Ethan made it a lot easier for people to talk about this approach to designing and building web sites. There’s a real power in naming related technologies like this. We saw the same explosion of discussion and creativity when Jesse James Garrett coined the term Ajax.

How long after understanding it did you create your first working example (either client work or ‘playground’ work)?

I was already making liquid layouts. In fact, every single site I’ve ever built for over a decade has used percentages by default. Because of that, I was already familiar with the challenges of fluid images and the work done by Richard Rutter (which Ethan references). I had started to dabble with media queries on my own personal projects but seeing Ethan’s proof-of-concept was just the incentive I needed to start implementing them on client sites.

As the methodology gained traction, it started to get a lot of flak from some quarters, often mobile developers. What do you put that down to?

I think a lot of people misunderstood what problems responsive design was claiming to solve. It was never specifically about mobile devices or users in a mobile context; it was always about adapting layout to varying viewport sizes.

A lot of people seemed to be angry that responsive web design didn’t appear to solve any issues relating to bandwidth or context. It’s true that responsive web design doesn’t solve those problems …it also doesn’t cure cancer. It never claimed to.

Responsive design isn’t about mobile. Neither is it about the desktop. It’s about the web.

Whilst no one set of principles can be considered a panacea or magic bullet - are there specific instances where you’d argue against a responsive web design for a clients site?

Honestly, no. But the reason I say that is that, once you’re used to creating responsive sites, it’s really no extra effort. So I’m not saying that every project needs to go that extra mile—quite the opposite. I’m saying that sites that adapt to the user’s device should be the default (and should have always been the default).

The only time I would argue that a client shouldn’t have a responsive site is if the client shouldn’t have a web site at all.

Just to clarify: I’m not saying that the client couldn’t also have subdomains or apps targeted at specific classes of device as well as their responsive web site. But the baseline to having any presence on the web should be a website that works for everyone, everywhere.

That said, it’s a lot easier to create a responsive site from scratch than to attempt to retro-fit an existing desktop-centric site. In that situation, where the desktop-centric site is just too big and bloated to serve up to mobile devices, a separate mobile-specific site can be a good stop-gap measure. But in the long run, maintaining multiple silos just doesn’t scale. Also, the fact that the site is too big and bloated for mobile probably means it’s too big and bloated for anyone, regardless of their device.

For a client who has neither the business necessity or budget for a ‘mobile specific’ website (let me qualify that by saying that I term a ‘mobile specific’ website as one that has some server side functionality to ‘sniff’ the device and serve up entirely different experience based upon it), is there any better option for clients to get themselves a mobile ready presence?

Well, yeah: a responsive web site! It might not be specifically targeted at mobile devices but, if it’s done right, it won’t be specifically targeted at any particular class of device.

At present, although server (e.g. adaptive-images) and JS (Scott Jehl’s <picture>) based solutions exist, responsive design struggles when it comes to responsive images as there is no way to provide alternate images based on media capability or connection speed (one day please!) through markup alone. What would you like to see happen to combat this issue?

There’s some great work being done by the W3C Responsive Images community group. I’m hoping to see some rapid adoption by browsers. But mostly, what I’d like to see is exactly what’s going on: a bunch of really smart people getting together to collectively solve this problem in a backwards-compatible way. I find it quite inspiring, actually.

What are some obvious pitfalls people should avoid when implementing a responsive design?

The biggest mistake I’ve seen is when developers try to treat responsiveness as an add-on, something to be bolted on at the end of the development process. That’s going to lead to a world of pain.

Responsive design makes most sense when it’s paired with the idea of Mobile First. Thinking about the screen size and capabilities of mobile devices first forces you to focus and really think about what’s absolutely essential to deliver. When you don’t have the luxury of a large viewport or a fast connection, you’ll quickly find that complicated navigation and unnecessary page cruft will quickly get trimmed.

In fact, that approach isn’t really about mobile specifically, it’s about focusing on the content. Content First.

Personally, I’d like to see some ability to visually re-construct the DOM through CSS alone - so media queries could literally place anything anywhere. Do you feel that specs like CSS Regions hold the answers to that problem?

I’m much more excited about flexbox, but that might just be because I haven’t examined CSS Regions in any depth.

Flexbox is going to be a game-changer, I think. Source order will still matter for older browsers, but we’ll be able to serve up just about any layout regardless of source order. It’ll be great to finally have that real separation of concerns.

Whether it’s flexbox or regions, I look forward to the day when we can stop using layout hacks like floats, because let’s face it, floats are a hack: they were never intended for layout.

Although tools like Adobe Shadow (Weinre) are emerging, existing prototyping tools like FireWorks are limited when it comes to fluid designs - do you prototype/design there or do you do a lot of designing in browser?

Fireworks and Photoshop are useful tools for designing elements of a site’s design but they are woefully inadequate at conveying the fluid dynamic nature of the browser. For that reason, I think it makes a lot of sense to get into the browser as soon as possible (it also means you can start testing your designs sooner).

Spending a lot of time making high-fidelity comps isn’t very efficient, I feel. A lot of that time would be better spent trying things out in the browser and reacting to how they behave at different sizes.

Some people have claimed that designing in the browser is much more limiting than designing in Fireworks or Photoshop, but I think that just comes down to what you’re used to. Those tools come with their own constraints (a fixed-width canvas and lack of interaction being the obvious ones).

Also, if there are certain things that can only be done in a tool like Fireworks and not in a web browser, then what’s the point of doing them? Unless you’re planning to just export your design as one big image, you’re going to have to translate that Fireworks comp into markup and CSS at some point. There’s no point in creating something that can’t be translated.

Graphic design tools still have their place. One of the techniques I find works really well with responsive design is the creation of Style Tiles. These allow you to nail down the visual vocabulary of a project without getting into the nitty-gritty of page layout. They are less wishy-washy than mood boards but not as time-consuming and high-fidelity as page comps.

Can you sum up, in general terms, the key things you think people should consider when building sites today?

I’ve found that it makes sense to apply the principle of progressive enhancement to everything: layout, images, and content:

• Use small images by default.
• Don’t apply any layout in your CSS.
• Start with the content that is absolutely essential.

Once you’ve got that baseline working well, then you can start to progressively enhance the site:

• Load in larger images if the screen size permits it.
• Use a grid for page layout, but keep the CSS declarations for the grid within media queries.
• Use Ajax to conditionally load non-essential content for larger screens.

Don’t start a design by thinking about the desktop layout. But don’t start by thinking about the mobile layout either. Instead, think about the content. And when I say “content”, I don’t mean “copy.” Your content could be a task, like adding an item to a shopping cart. Focus on the core task that your user wants to accomplish.

Separating out the content (reading an article, buying a pair of shoes) from the delivery mechanism (a desktop browser, a mobile browser, a tablet) requires a different mindset to the way web sites have traditionally been built. But much like the change in mindset that was required when we changed from tables for layout to CSS, it’s incredibly rewarding.

I’ve been huffduffing talks from this year’s South by Southwest, revisiting some of the ones I saw and catching up with some of the ones I missed.

There are some really design and development resources in there that I didn’t get to see in person:

• Phil’s talk on Excessive Enhancement: JavaScript’s Dark Side,
• Samantha’s talk on Faster Design Decisions with Style Tiles,
• Josh’s talk on Tapworthy Touchscreen Design, and
• Scott’s talk on Why Mobile Apps Must Die.

One talk I did get to see was Andy’s CSS for Grown Ups: Maturing Best Practices.

It was excellent.

You can have a look through the slides.

He talks about different approaches to creating maintainable CSS for large-scale projects. He touches on naming conventions for classes, something that Nicolas Gallagher wrote about recently. And while he makes reference to SASS and Compass, Andy makes the compelling point that’s what more interesting than powerful tools is the arrival of powerful approaches like SMACSS and OOCSS.

Over and over again, Andy makes the point that we must think in terms of creating design systems, not simply styling individual pages—something that Paul has also spoken about. One of the most powerful tools for making that change in thinking is in the creation of style guides for the web and Paul has even created blog dedicated to the BBC’s style guide.

Andy referenced the BBC GEL style guide in his talk but pointed out that because it’s published as a PDF rather than markup, it isn’t as powerful as it could be—there’s inevitably a loss of signal when the patterns are translated into HTML and CSS. Someone from the BBC was in the audience, and in the Q and A portion, acknowledged that that was a really good point.

After the talk I got chatting with Lincoln Mongillo who worked on the recent responsive redesign of Starbucks.com. He mentioned that they created a markup and CSS style guide for the project. “You know what would be really cool?” I said. “If you published it!”

Here it is. It’s a comprehensive library of markup patterns; exactly the kind of resource that Anna wrote about in 24 Ways.

In my experience, creating a pattern library for any project is immensely valuable, whether you’re working in a team of two or a team of two hundred. I’ve found they work well as the next step after Style Tiles: a way of translating the visual vocabulary of a site into markup and CSS without getting bogged down in the specifics of page structure or layout (very handy for a Content First approach). The modularity of a pattern library enforces a healthy separation of concerns.

I’m really pleased to see more and more pattern libraries being made public. That’s one of the reasons why I shared my pattern primer and Dan shared his Pears theme for Wordpress:

Breaking interfaces down into patterns has been immensely helpful in learning and re-evaluating the best possible code to implement them.

But Pears isn’t about how I code these patterns—it’s a tool for creating your own.

I love that. These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

For that, I am very grateful.

When I went to Webstock, I prepared a new presentation called Of Time And The Network:

Our perception and measurement of time has changed as our civilisation has evolved. That change has been driven by networks, from trade routes to the internet.

I was pretty happy with how it turned out. It was a 40 minute talk that was pretty evenly split between the past and the future. The first 20 minutes spanned from 5,000 years ago to the present day. The second 20 minutes looked towards the future, first in years, then decades, and eventually in millennia. I was channeling my inner James Burke for the first half and my inner Jason Scott for the second half, when I went off on a digital preservation rant.

You can watch the video and I had the talk transcribed so you can read the whole thing.

It’s also on Huffduffer, if you’d rather listen to it.

During the talk, I pointed to my prediction on the Long Bets site:

The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.

I made the prediction on February 22nd last year (a terrible day for New Zealand). The prediction will reach fruition on 02022-02-22 …I quite like the alliteration of that date.

Here’s how I justified the prediction:

“Cool URIs don’t change” wrote Tim Berners-Lee in 01999, but link rot is the entropy of the web. The probability of a web document surviving in its original location decreases greatly over time. I suspect that even a relatively short time period (eleven years) is too long for a resource to survive.

Well, during his excellent Webstock talk Matt announced that he would accept the challenge. He writes:

Though much of the web is ephemeral in nature, now that we have surpassed the 20 year mark since the web was created and gone through several booms and busts, technology and strategies have matured to the point where keeping a site going with a stable URI system is within reach of anyone with moderate technological knowledge.

The prediction has now officially been added to the list of bets.

We’re playing for $1000. If I win, that money goes to the Bletchley Park Trust. If Matt wins, it goes to The Internet Archive.

The sysadmin for the Long Bets site is watching this bet with great interest. I am, of course, treating this bet in much the same way that Paul Gilster is treating this optimistic prediction about interstellar travel: I would love to be proved wrong.

The detailed terms of the bet have been set as follows:

On February 22nd, 2022 from 00:01 UTC until 23:59 UTC,
entering the characters http://www.longbets.org/601 into the address bar of a web browser or command line tool (like curl)
OR
using a web browser to follow a hyperlink that points to http://www.longbets.org/601
MUST
return an HTML document that still contains the following text:
“The original URL for this prediction (www.longbets.org/601) will no longer be available in eleven years.”

The suspense is killing me!

If attending a web conference is like going to a concert, South by Southwest in Austin is like Glastonbury: a massive multi-track event where the people on stage aren’t as important as tracking down the friends you know are somewhere in the crowd.

An incredible amount of work goes into the event. When Jessica and I showed up in Austin last Thursday evening and headed straight to The Wholly Cow for a burger, there was a group of Southby volunteers at the next table, planning the next day’s activities like soldiers on the eve of battle. Make no mistake, South by Southwest is a triumph of planning and execution on a scale I can’t even begin to comprehend. I’m always amazed when I see Hugh wandering about looking cool as a cucumber—I’d be freaking out if it were me.

The interaction portion of South by Southwest has been getting bigger with each passing year. For a while this was a source of pride, then nervousness, and now …well, now it has become something quite different to what it once was. It’s not simply that the crowd is larger; the crowd is different.

Where once the core audience was made up of web-loving geeks, now the overwhelming majority of attendees are there to hawk their product/app/start-up by whatever means necessary. I tried to take a live-and-let-live attitude with those people, but it’s hard for me to maintain that attitude when I find them actively repulsive. I mean, honestly, it was like wading through a sea of spam.

I was chatting with Aaron in Austin airport afterwards and he said he was trying to take a City And The City approach to unseeing the douchebag world, but that’s difficult when they keep breaching by thrusting flyers and schwag into your face when you’re just trying to get into the Austin Convention Center (though you could potentially spend the entire event without ever entering that building, what with the panels spread out amongst many venues across town).

I did attend some great panels at South by Southwest, and I did have a great time meeting up with old friends and making new ones. But I felt like I had to work quite hard at it this year. I had a constant feeling of FOMO from all the talks I was missing and there were lots of friends who were also at the event that I didn’t even see once the whole time. So if you weren’t in Austin and you were watching from afar via Twitter, don’t worry: even the people who were at South by Southwest weren’t at South by Southwest.

Evan had a similar experience and I think he’s right about why there are so many desperate marketers showing up:

I think that’s largely Twitter’s fault; the company’s breakout at SxSW 2007 has made success at the event a Philosopher’s Stone for startups world-wide. Unfortunately, most of these folks have missed the subtle fact that Twitter wasn’t successful because it was at SxSW, but because it was useful and interesting to the kind of people who go to South by Southwest. The same goes for other South By success stories: Foursquare, Lanyrd. In other words: if you don’t appeal to that audience, dropping a trillion-dollar marketing bomb on downtown Austin for a week in March won’t make you Twitter. It’ll just make you poorer.

To be honest, I’m not sure I can justify another trip to South by Southwest if it means paying for an overpriced hotel room and wading through all the Conference Center crap to find the gems hidden within. But Evan points out the problem with simply giving up on the event:

South by Southwest has been a huge boon to the technology community. It deserves a better response than a sniffy adieu.

He’s right …but I’m not sure there’s anything that the event organisers (or the subset of attendees who aren’t meatspace spammers) can do about it. South by Southwest has become an unstoppable juggernaut.

And what rough beast, its hour come round at last, slouches towards Austin to be born?

Y’know, I’m okay with South by Southwest being a different kind of event now than it once was. I’m glad that it’s successful. And it’s not like there aren’t plenty of other excellent events for web geeks.

If I don’t end up returning to South by Southwest, I’d definitely miss it. And I would definitely miss Austin. I’m looking forward to going back to that most excellent town for An Event Apart in July—it will be my first time being there when it’s not South by Southwest.

An Event Apart, by the way, had an excellent one-page advert running on the back cover of the chunky South by Southwest printed program. It simply said: One Track.

South by Southwest has become a vast, sprawling festival with a preponderance of panels pitched at marketers, start-ups and people that use the words “social media” in their job title without irony. But there were also some great design and development talks if you looked for them.

Samantha gave a presentation on style tiles, which I unfortunately missed but I’ll be eagerly awaiting the release of the audio. I also missed some good meaty JavaScript talks but I did manage to make it along to Jen’s excellent introduction to HTML5 APIs.

Andy’s talk on CSS best practices was one of the best presentations I’ve ever seen. He did a fantastic job of tackling some really important topics. It’s a presentation (and a presenter) that deserves a wider audience, so if you’re involved in putting together the line-up for any front-end conferences, I highly recommend that you nab him.

Divya put together an absolutely killer panel called CSS.next, all about how CSS gets specced and shipped, and what’s coming down the line. All of the panelists were smart, articulate, and well-informed. The panel was very enlightening, as well as being thoroughly enjoyable.

And then there was the Browser Wars panel.

This is something of a SXSW tradition. Arun assembles a line-up of representatives from browser makers—Mozilla, Google, Microsoft, and Opera—and then peppers them with some hardball questions. Apple is invited to send a representative every year, and every year, Apple declines.

There was no shortage of contentious topics this year. The subject of Google Dart was raised (“Good luck with that,” said Brendan). There was also plenty of discussion about the recent DRM proposal submitted to the HTML working group. There was a disturbing level of agreement amongst all the panelists that some form of DRM for video was needed because, hey, that’s just the way things go…

As an aside, I must say I found the lack of imagination on display to be pretty disheartening. Two years ago, Chris was on the Browser Wars panel representing Microsoft, defending the EOT format because, hey, that’s just the way things go. Without some form of DRM, he argued, we couldn’t have fonts on the web. Well, the web found a way. Now Chris is representing Google but the argument remains the same. DRM, so the argument goes, is the only way we’ll get video on the web because that’s what the “rights holders” demand. And yet, if you are a photographer, no such special consideration is afforded to you. The img element has no DRM and people are managing just fine, thank you. Video, apparently, is a special case …just like fonts. ahem

Anyway…

The subject of vendor prefixes also came up. Specifically, the looming prospect of non-webkit browsers parsing -webkit prefixed properties was raised.

I saw a pattern amongst all three subjects: the DRM proposal, Dart, and browsers implementing another browser’s vendor prefix. All three proposals were made to address a genuine problem. The proposals all suffer from varying degrees of batshit craziness but they certainly galvanised a lot of discussion.

For example, Brendan said that while Google Dart may not stand a hope in hell of supplanting JavaScript, some of the ideas it contains may well end up influencing the development of ECMAScript.

Similarly, Mozilla’s plan for vendor-prefixing certainly caused all parties to admit the problem: the W3C was moving too slow; Apple should have submitted proprietary properties for standardisation sooner; Mozilla, Microsoft, and Opera should have been innovating faster; and web developers should have been treating vendor-prefixed properties as experimental features, not stable parts of a spec.

So the proposal to do something batshit crazy and implement -webkit-prefixed CSS properties has actually had some very positive effects …but there’s no reason to actually go ahead and do it!

I tried to make this point during the audience participation part of the panel, but it was like banging my head against a brick wall. Chaals kept repeating the problem case, but I wasn’t disputing the problem; I was trying to point out that the proposed solution wouldn’t fix the problem.

It was a classic case of the same kind of thinking we saw in the SOPA proposal:

1. Something must be done!
2. Implementing -webkit prefixes is something.
3. Something has been done.

The problem is that it won’t work. Adding “like Webkit” to the user-agent string will probably have much more of an effect and frankly, I don’t care if any of the browsers do that. At this point, a little bit more pissing into the bloated cesspool of user-agent strings is hardly going to matter. A browser’s user-agent string isn’t an identifier, it’s a reverse-chronological history of the web. Why not update the history booklet to include the current predilection amongst developers for Webkit browsers on mobile?

But implementing -webkit vendor prefixes? Pointless! If a developer is only building and testing their sites for one class of device or browser, simply implementing that browser’s prefixed CSS is just putting a band aid on a decapitation.

So I was kind of hoping that Mozilla would just come right out and say that maybe they wouldn’t actually go ahead and do this but hey, look at all the great discussion it generated (just like Dart, just like the DRM proposal). But sadly, no. Brendan categorically stated that the proposal was not presented in order to foment discussion. And in follow-up tweets, he wrote that he actually expected it to level the mobile browser playing field. That’s an admirably optimistic viewpoint but it’s sadly self-delusional.

And what will happen when implementing -webkit prefixes fails to level the playing field? We’ll be left with deliberately broken browsers.

Once something ships in a browser, it’s very, very hard to ever remove it. During the Dart discussion, Chris talked about the possibility of removing Dart from Chrome if developers don’t take to it. Turning to the Microsoft representative he asked rhetorically, “I mean, do you guys still ship VBScript?”

The answer?

“Yes.”

I had a whole day of good talks yesterday at South By Southwest yesterday …and none of them were in the Austin Convention Center. In a very real sense, the good stuff at this event is getting pushed to the periphery.

The day started off in the Driskill Hotel with the New Aesthetic panel that James assembled. It was great, like a mini-conference packed into one hour with wonderfully dense knowledge bombs lobbed from all concerned. Joanne McNeil gave us the literary background, Ben searched for meaning (and humour) in advertising trends, Russell looked at how machines are changing what we read and write, and Aaron …um, talked about the helium-balloon predator drone in the corner of the room.

With our brains primed for the intersections where humans and machines meet, it wasn’t hard to keep pattern-matching for it. In fact, the panel right afterwards on technology and fashion was filled with wonderful wearable expressions of the New Aesthetic.

Alas, I wasn’t able to attend that panel because I had to get to the green room to prepare for my own appearance on Get Excited and Make Things With Science with Ariel and Matt. It was a lot of fun and it was a real pleasure to be on a panel with such smart people.

I basically used the panel as an opportunity to geek out about some of my favourite science-related hacks and websites:

• Nathan’s ISS Notify lamp, a Kickstarter project that started life as a Science Hack Day hack,
• the magnificent Spacelog that came out of a dev fort,
• and Old Weather, which is probably my favourite of all the Zooniverse projects.

After that I stayed in the Driskill for a panel on robots and AI. One of the panelists was Bina48.

I heard had heard about Bina48 from a Radiolab episode.

Jon Ronson described the strange experience of interviewing her—how the questions always tended to the profound and meaningful rather than trivial and chatty. Sure enough, once Bina was (literally) unveiled on the panel—a move that was wisely left till halfway through because, as the panelists said, “after that, you’re not going to pay attention to a word we say”—people started asking questions like “Do you dream?” and “What is the meaning of life?”

I asked her “Where were you before you were here?” She calmly answered that she was made in Texas. The New Aesthetic panelists would’ve loved her.

I was surprised by how much discussion of digital preservation there was on the robots/AI panel. Then again, the panel was hosted by a researcher from The Digital Beyond.

Bina48’s personality is based on the mind file of a real person containing exactly the kind of data that we are publishing every day to third-party sites. The question of what happens to that data was the subject of the final panel I attended, Saying Goodbye to Your Digital Self, featuring representatives from The Internet Archive, Archive Team, and Google’s Data Liberation Front.

Digital preservation is an incredibly important topic—one close to my heart—but the panel (in the Omni hotel) was, alas, sparsely attended.

Like I said, at this year’s South by Southwest, a lot of the good stuff was at the edges.

A year and a half ago, Eric wrote a great article in A List Apart called Prefix or Posthack. It’s a balanced look at vendor prefixes in CSS that concludes in their favour:

If the history of web standards has shown us anything, it’s that hacks will be necessary. By front-loading the hacks using vendor prefixes and enshrining them in the standards process, we can actually fix some of the potential problems with the process and possibly accelerate CSS development.

So the next time you find yourself grumbling about declaring the same thing four times, once for each browser, remember that the pain is temporary. It’s a little like a vaccine—the shot hurts now, true, but it’s really not that bad in comparison to the disease it prevents.

Henri disagrees. He wrote a post called Vendor Prefixes Are Hurting the Web:

In practice, vendor prefixes lead to a situation where Web author have to say the same thing in a different way to each browser. That’s the antithesis of having Web standards. Standards should enable authors to write to a standard and have it work in implementations from multiple vendors.

Daniel Glazman wrote a point-by-point rebuttal to Henri’s post called CSS vendor prefixes, an answer to Henri Sivonen that’s well worth a read. Alex also wrote a counter-argument to Henri’s post called Vendor Prefixes Are A Rousing Success that echoes some of the points Eric made in his ALA article:

The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice.

Alex’s co-worker Paul disagrees. He recently wrote Vendor Prefixes Are Not Developer-friendly:

1. Prefixes are not developer-friendly.
2. Recent features would have been in a much better state without prefixes.
3. Implementor maneuverability is not hampered without prefixes.

All of this would have remained a fairly academic discussion but for a bombshell dropped by Tantek at a face-to-face meeting of the CSS Working Group in Paris:

At this point we’re trying to figure out which and how many -webkit- prefix properties to actually implement support for in Mozilla.

The superficial issue is that web developers have been implementing -webkit- properties without then adding the non-prefixed standardised version (and without adding the corresponding prefixes of other vendors). The more fundamental problem is that while vendor prefixes were intended to introduce experimental features until those features became standardised, the reality is that the prefixed version ends up being supported in perpetuity. Nobody is happy about this situation but that’s the unfortunate reality.

Among the unhappy voices are:

• Bruce who wrote On the Vendor Prefixes Problem,
• Aaron who wrote This Must Not Happen!,
• Remy who wrote Vendor Prefixes — about to go south,
• Rachel who wrote a Call for action on Vendor Prefixes on the WaSP blog, and
• Daniel once more entered the fray, writing Call For Action: The Open Web Needs You Now.

Once again, Eric sought to bring clarity to the situation in the form of an article on A List Apart, this time publishing an interview with Tantek. Alex also popped up again, writing a post called Misdirection which addresses what he feels are some fundamental assumptions being made in the interview.

Finally, Mozilla engineer Robert O’Callahan—who I chatted with briefly at Kiwi Foo Camp about the vendor prefix situation—wrote about Alternatives To Supporting -webkit Prefixes In Other Engines in which he makes clear that evangelism efforts like Christian’s, while entirely laudable, aren’t a realistic solution to the problem.

It’s all a bit of a mess really, with lots of angry finger-pointing: at Apple, at Mozilla, at web developers, at the W3C…

My own feelings match those of Eric, who wrote:

I’d love to be proven wrong, but I have to assume the vendors will push ahead with this regardless. … I don’t mean to denigrate or undermine any of the efforts I mentioned before—they’re absolutely worth doing even if every non-WebKit browser starts supporting -webkit- properties next week. If nothing else, it will serve as evidence of your commitment to professional craftsmanship.

Ralph McQuarrie died yesterday at the age of 82. His pre-production paintings shaped the Star Wars films …and the Star Wars films shaped me.

His work adorned my bedroom wall when I was growing up—I remember this Return Of The Jedi poster in particular.

His sweeping vistas populated with small figures dwarfed by their otherworldly surroundings helped to establish the Star Wars universe as something that existed beyond the confines of the films. George Lucas made the movies …but Ralph McQuarrie shaped the mythology.

His passing is being marked elsewhere on the web:

• Gavin Rothery’s blog,
• Ain’t It Cool News,
• Binary Bonsai and
• The Star Wars website.

On our way back from New Zealand, Jessica and I stopped off in Sydney for a day. That same evening, the “What Do You Know?” event was going on—a series of five minute lightning talks from Sydney’s finest web geeks.

Maxine asked me if I could do a turn so I put together a quick spiel called Five Things I Learned from the Internet. Those five things are:

1. How to wrap headphone cables in a tangle-free way.
2. How to fold a T-shirt in seconds.
3. How to tie shoelaces correctly (thanks, Adam).
4. How to eat a cupcake (thanks, Tara).
5. How to peel a banana (thanks, Kyle) with a bonus lesson on the bananus.

At least one of those things will blow your mind. Pwshoo!