Archive: November, 2011


                    5th                     10th                     15th                     20th                     25th                     30th


Wednesday, November 30th, 2011

Move The Web Forward | Guide to getting involved with standards and browser development

A call-to-arms for web developers combined with a handy list of projects you can get involved in.

Tuesday, November 29th, 2011

“Mobile first” CSS and getting Sass to help with legacy IE – Nicolas Gallagher

If you use Sass, this could be a really handy technique for handling IE<9 support with mobile-first responsive designs.

A List Apart: Articles: Say No to SOPA

A superb piece of writing from Jeffrey, scorching the screen with righteous anger. THIS. IS. IMPORTANT!

SOPA approaches the piracy problem with a broad brush, lights that brush on fire, and soaks the whole internet in gasoline.

Little Printer | BERG Cloud

This evolution of Tom Taylor’s microprinter looks like it’s going to be absolutely wonderful (and packed full of personality). Watch this space.

Whales | Home

Yet another fantastic citizen science project from Zooniverse:

You can help marine researchers understand what whales are saying. Listen to the large sound and find the small one that matches it best.

Monday, November 28th, 2011

Twine : Listen to your world, talk to the Internet by Supermechanical — Kickstarter

This looks truly wonderful: like a hardware version of “if this, then that.”

A Book Apart, 2011 Holiday Bundle

The perfect Christmas gift for the web geek in your life: get a discount of 30% when you buy all six books apart.

russell davies: again with the post digital

In a single post, Russell Davies manages to rehabilitate the term “post digital.” And he paints a vivid picture of where our “Geocities of things” is heading.

Saturday, November 19th, 2011

Responsive Design Essentials: Look Great on any Device - Facebook developers

The process behind the mobile-first responsive design of

Pattern primer

I’m on a workshopping roll. Fresh from running my Responsive Enhancement workshop in Belfast, I’m now heading to Düsseldorf for Beyond Tellerand where I’ll be running the workshop on Sunday (and if you can’t make it, don’t forget that you can book the workshop for your own workplace too).

As part of the process of building a responsive site from the content out rather than the canvas in, I talk about beginning with the individual components divorced from any layout context. Or, as Mark puts it, “start with the bits.”

That’s the way I’ve been starting most of my projects lately: beginning with the atomic units of content and styling them first before even thinking about layout. This ensures that those styles are extremely robust—because they don’t depend on any particular context, they can be safely dropped into any part of a page.

I’ve been calling this initial collection of markup snippets a pattern primer. To help create the pattern primer, I’ve written a little bit of PHP to automatically generate a page of patterns from a folder of HTML snippets.

In my workshop I keep promising to put that script on Github. I finally got around to doing that and you can find it at

Take a look at an example pattern primer to get an idea of what a handy deliverable this can be if you’re handing off to other developers. It also acts like a page of unit tests for CSS—whenever you’ve been messing around in the stylesheet you can refresh the page to quickly check to see if anything looks screwed up.

Grab the code; improve upon it; share your changes.

Friday, November 18th, 2011

Play me off

One of the fun fringe events at Build in Belfast was The Standardistas’ Open Book Exam:

Unlike the typical quiz, the Open Book Exam demands the use of iPhones, iPads, Androids—even Zunes—to avail of the internet’s wealth of knowledge, required to answer many of the formidable questions.

Team Clearleft came joint third. Initially it was joint fourth but an obstreperous Andy Budd challenged the scoring.

Now one of the principles of this unusual pub quiz was that cheating was encouraged. Hence the encouragement to use internet-enabled devices to get to Google and Wikipedia as quickly as the network would allow. In that spirit, Andy suggested a strategy of “running interference.”

So while others on the team were taking information from the web, I created a Wikipedia account to add misinformation to the web.

Again, let me stress, this was entirely Andy’s idea.

The town of Clover, South Carolina ceased being twinned Larne and became twinned with Belfast instead.

The world’s largest roller coaster become 465 feet tall instead of its previous 456 feet (requiring a corresponding change to a list page).

But the moment I changed the entry for Keyboard Cat to alter its real name from “Fatso” to “Freddy” …BAM! Instant revert.

You can mess with geography. You can mess with measurements. But you do. Not. Mess. With. Keyboard Cat.

For some good clean Wikipedia fun, you can always try wiki racing:

To Wikirace, first select a page off the top of your head. Using “Random page” works well, as well as the featured article of the day. This will be your beginning page. Next choose a destination page. Generally, this destination page is something very unrelated to the beginning page. For example, going from apple to orange would not be challenging, as you would simply start at the apple page, click a wikilink to fruit and then proceed to orange. A race from Jesus Christ to Subway (restaurant) would be more of a challenge, however. For a true test of skill, attempt Roman Colosseum to Orthographic projection.

Then there’s the simple pleasure of getting to Philosophy:

Some Wikipedia readers have observed that clicking on the first link in the main text of a Wikipedia article, and then repeating the process for subsequent articles, usually eventually gets you to the Philosophy article.

Seriously. Try it.

Biochemies :: DNA Molecule Plush Dolls

With magnetic hydrogen bonds!

Vendor Prefixes Are A Rousing Success | Infrequently Noted

Alex weighs in on the newly-reopened debate on vendor prefixes, roundly squashing Henri’s concerns.

Barack Obama

It’s responsive. It looks great. It’s using HTML5 structural elements and microformats.

Redesigning the Country Selector - Baymard Institute

This looks like a nice progressive enhancement pattern: convert a select element into an auto-completing input element (a country selector in this case).

Fixed Positioning in Mobile Browsers | Brad Frost Web

Brad takes a detailed look at mobile browser support for fixed positioning and how it intersects with page zooming.

Thursday, November 17th, 2011

Yelping with Cormac

Because Yelp needs Cormac McCarthy.

CERN Document Server: Powers of ten

I should just have a recurring event in my calendar set for every week that says “Go watch this again to regain your sense of perspective.”

The Social Graph is Neither (Pinboard Blog)

This post from Maciej might initially seem negative but read it through to the end: there’s a very powerful positive message.

Wednesday, November 16th, 2011

Babies and the Bathwater | Contents Magazine

Mandy’s inaugural article for Contents Magazine is a wonderful piece of thinking and writing.

Enjoy reading this.

LukeW | The Web OS is Already Here…

Luke points out that the web is everywhere: it’s accessible through the browser but also through many native applications. This is the real Web Operating System.

The Web (browser) is inside of every application instead of every application being inside the Web (browser).

Mark Boulton on designing websites using ‘content out’ | Interview | .net magazine

Mark continues to hammer home the most important thing to keep in mind when creating responsive designs: design from the content out, not the canvas in.

ART=WORK · Responsive Advertising

Some more thoughts on the challenges of combining advertising with responsive design.

Structuring a Responsive Stylesheet | Sparkbox

Some thoughts on structuring your CSS for responsive designs.

CSS vendor prefixes, an answer to Henri Sivonen -

Daniel responds to Henri’s call-to-arms on vendor prefixes. While he stridently disagrees with most of what Henri suggests, there is also overlapping agreement: they both want vendor prefixes to ship only in experimental builds, not stable browser releases.

Tuesday, November 15th, 2011

The Future of Open Fabrication

A thorough hypertext report from those good folks at the Institute For The Future on our fabrication overlords.

Speaking, not hacking

I spent last week in Belfast for the Build conference, so I did.

The fun kicked off with a workshop on responsive enhancement which was a lot of fun. Toby has written a report of the day outlining all of the elements that came together for a successful workshop.

The day of the conference itself was filled with inspiring, uplifting talks full of positive energy …except for mine. My talk—All Our Yesterdays—had an underlying sense of anger, especially when I spoke about the destruction of Geocities. If you heard the talk and you’d like to explore some of the resources I mentioned, here’s a grab-bag of links:

I thought I had delivered the talk reasonably well only to discover that my American friends in the audience misinterpreted my quote from Tim Berners-Lee as “Cool your eyes don’t change.”

Still, it was wonderfully surreal to be introduced by Jesse Thorn.

Build Jeremy Keith

My appearance at Build was an eleventh hour affair. Ethan was originally set to speak but he had to cancel. Andy asked me to step in. At first I didn’t think it would be possible. Last Thursday—the day of the conference—was the day I was supposed to fly to San Francisco for Science Hack Day. Luckily I was able to change my flight.

That’s why I was up at the crack of dawn the day after Build to catch an early-morning flight to Heathrow where I would have to dash from the lowest to the highest numbered terminal to get on my transatlantic hackrocket.

So you can imagine how my heart sank as I sat in the departure lounge of Belfast International Airport listening to the announcement of a delay to the first flight. First it was one hour. Then two.

When I did finally make it to Heathrow, there was no chance of making the flight to San Francisco. I was hoping that perhaps it too had been delayed by the foggy weather conditions but no, it took off right on time. Without me.

As my flight from Belfast was a completely separate booking rather than a connecting flight, I couldn’t get on a later flight unless I paid the full fare. So I simply accepted my fate.

C’est la vie, c’est it is.

It looks like Science Hack Day San Francisco—to the surprise of absolutely no-one—was a superb event. There’s a write-up on the open.NASA blog outlining some of the amazing hacks, including the cute (and responsive) Space Ipsum and the freakishly brilliant synesthesia mask: syneseizure.

Science Hack Day SF science hack day

Vendor Prefixes Are Hurting the Web

This is a very thoughtful piece by Henri on vendor prefixes and it’s well worth a read …however the thought of one browser implementing support for vendor-prefixed properties intended for a different browser does make me quite quesy.

Responsive Advertising| Mark Boulton

A great in-depth look at the tricky problem of advertising in responsive design from Mark.

The mobile web splash screen antipattern [Legends of the Sun Pig - Martin Sutherland’s Blog]

Excellent points, eloquently delivered, on why sites shouldn’t be shoving their native Apps in the face of people who just arrived at their website on a mobile device.

Putting up a splash screen is like McDonalds putting a bouncer on the door, and telling customers who just parked their car and want to enter the restaurant that they should use the drive-through instead.

ExtendNY - New York City Extended

Sheer brilliance: taking the street grid of Manhattan and extending it to cover the entire world. For the record, I live near the intersection of east 11,303rd avenue and 63,475th street.

Monday, November 14th, 2011

Science Hack Day, San Francisco - open.NASA

A round-up of the hacks from this weekend’s Science Hack Day in San Francisco. Sounds like it was great!

You Say Responsive, I Say Adaptive | Sparkbox

On the importance of using a fluid grid in responsive design.

HTML5 semantics and accessibility | The Paciello Group Blog

This is a great response to my recent post about semantics in HTML. Steve explores the accessibility implications. I heartily concur with his rallying cry at the end:

Get involved!

Earth | Time Lapse View from Space, Fly Over | NASA, ISS on Vimeo

Gorgeous time-lapse footage from the astronauts in the International Space Station.

Space Ipsum

This is officially the best lorem ipsum generator yet.

Sunday, November 13th, 2011

The Great Universe of Data on Vimeo

One of the opening lightning talks at Science Hack Day in San Francisco by Sean Herron of NASA.

Saturday, November 12th, 2011

A recipe for creating a great workshop | Toby’s Technical Ramblings

Toby’s write-up of the workshop I led for the Build conference. I enjoyed myself so it’s immensely gratifying to know that the attendees did too.

Pursuing semantic value

Divya Manian, one of the super-smart web warriors behind HTML5 Boilerplate, has published an article on Smashing Magazine called Our Pointless Pursuit Of Semantic Value.

I’m afraid I have to agree with Patrick’s comment when he says that the abrasive title, the confrontational tone and strawman arguments at the start of the article make it hard to get to the real message.

But if you can get past the blustery tone and get to the kernel of the article, it’s a fairly straightforward message: don’t get too hung up on semantics to the detriment of other important facets of web development. Divya clarifies this in a comment:

Amen, this is the message the article gets to. Not semantics are useless but its not worth worrying over minute detail on.

The specific example of divs and sectioning content is troublesome though. There is a difference between a div and a section or article (or aside or nav). I don’t just mean the semantic difference (a div conveys no meaning about the contained content whereas a section element is specifically for enclosing thematically-related content). There are also practical differences.

A section element will have an effect on the generated outline for a document (a div will not). The new outline algorithm in HTML5 will make life a lot easier for future assistive technology and searchbots (as other people mentioned in the comments) but it already has practical effects today in some browsers in their default styling.

Download the HTML document I’ve thrown up at and open it in the latest version of Safari, Chrome or Firefox. You’ll notice that the same element (h1) will have different styling depending on whether it is within a div or within a section element (thanks to -moz-any and -webkit-any CSS declarations in the browser’s default stylesheets).

So that’s one illustration of the practical difference between div and section.

Now with that said, I somewhat concur with the conclusion of “when in doubt, just use a div”. I see far too many documents where every div has been swapped out for a section or an article or a nav or an aside. But my reason for coming to that conclusion is the polar opposite of Divya’s reasoning. Whereas Divya is saying there is effectively no difference between using a div and using sectioning content, the opposite is the case: it makes a big difference to the document’s outline. So if you use a section or article or aside or nav without realising the consequences, the results could be much worse than if you had simply used a div.

I also agree that there’s a balance to be struck in the native semantics of HTML. In many ways its power comes from the fact that it is a limited—but universally understood by browsers—set of semantics. If we had an element for every possible type of content, the language would be useless. Personally, I’m not convinced that we need a section element and an article element: the semantics of those two elements are so close as to be practically identical.

And that’s the reason why right now is exactly the time for web developers to be thinking about semantics. The specification is still being put together and our collective voice matters. If we want to have well-considered semantic elements in the language, we need to take the time to consider the effects of every new element that could potentially be used to structure our content.

So I will continue to stop and think when it comes to choosing elements and class names just as much as I would sweat the details of visual design or the punctation in my copy or the coding style of my JavaScript.

Wednesday, November 9th, 2011

Type study: Sizing the legible letter « The Typekit Blog

A great article by guest author Ethan on the various approaches to sizing text in CSS.

Responsible responsive images

I’m in Belfast right now for this year’s Build conference, so I am. I spent yesterday leading a workshop on —the marriage of responsive design with progressive enhancement; a content-first approach to web design.

I spent a chunk of time in the afternoon going over the thorny challenges of responsive images. Jason has been doing a great job of rounding up all the options available to you when it comes to implementing responsive images:

  1. Responsive IMGs, Part 1,
  2. Responsive IMGs, Part 2—an in-depth look at techniques,
  3. Responsive IMGs, Part 3—the future of the img element.

Personally, I have two golden rules in mind when it comes to choosing a responsive image technique for a particular project:

  1. The small image should be default.
  2. Don’t load images twice (in other words, don’t load the small images and the larger images).

That first guideline simply stems from the mobile-first approach: instead of thinking of the desktop experience as the default, I’m assuming that people are using small screen, narrow bandwidth devices until proven otherwise.

Assuming a small-screen device by default, the problem is now how to swap out the small images for larger images on wider viewports …without downloading both images.

I like Mark’s simplified version of Scott’s original responsive image technique and I also like Andy’s contextual responsive images technique. They all share a common starting point: setting a cookie with JavaScript before any images have started loading. Then the cookie can be read on the server side to send the appropriate image (and remember, because the default is to assume a smaller screen, if JavaScript isn’t available the browser is given the safer fallback of small images).

Yoav Weiss has been doing some research into preloaders, cookies and race conditions in browsers and found out that in some situations, it’s possible that images will begin to download before the JavaScript in the head of the document has a chance to set the cookie. This means that in some cases, on first visiting a page, desktop browsers like IE9 might begin get the small images instead of the larger images, thereby violating the second rule (though, again, mobile browsers will always get the smaller images, never the larger images).

Yoav concludes:

Different browsers act differently with regard to which resources they download before/after the head scripts are done loading and running. Furthermore, that behavior is not defined in any spec, and may change with every new release. We cannot and should not count on it.

The solution seems clear: we need to standardise on browser download behaviour …which is exactly what the HTML standard is doing (along with standardising error handling).

That’s why I was surprised by Jason’s conclusion that device detection is the future-friendly img option.

Don’t get me wrong: using a service like SRC (formerly TinySRC)—which relies on user-agent sniffing and a device library lookup—is a perfectly reasonable solution for responsive images …for now. But I wouldn’t call it future friendly; quite the opposite. If anything, it might be the most present-friendly technique.

One issue with relying on user-agent sniffing is the danger of false positives: a tablet may get incorrectly identified as a mobile phone, a mobile browser may get incorrectly identified as a desktop browser and so on. But those are edge cases and they’re actually few and far between …for now.

The bigger issue with relying on user-agent sniffing is that you are then entering into an arms race. You can’t just plug in a device library and forget about it. The library must be constantly maintained and kept up to date. Given the almost-exponential expansion of the device and browser landscape, that’s going to get harder and harder.

Disruption will only accelerate. The quantity and diversity of connected devices—many of which we haven’t imagined yet—will explode, as will the quantity and diversity of the people around the world who use them. Our existing standards, workflows, and infrastructure won’t hold up. Today’s onslaught of devices is already pushing them to the breaking point. They can’t withstand what’s ahead.

So while I consider user-agent sniffing to be an acceptable short-term solution, I don’t think it can scale to the future onslaught—not to mention the tricky issue of the licensing landscape around device libraries.

There’s another reason why I tend to steer clear of device libraries like WURFL and Device Atlas. When you consider the way that I’m approaching responsive images, those libraries are over-engineered. They contain a massive list of mobile user-agent strings that I’ll never need. Remember, I’m taking a mobile-first approach and assuming a mobile browser by default. So if I’m going to overturn that assumption, all I need is a list of desktop user-agent strings. That’s a much less ambitious undertaking. Such a library wouldn’t need to kept updated quite as often as a mobile device listing.

Anybody fancy putting it together?

A Brief Rant on the Future of Interaction Design

The next time you make a sandwich, pay attention to your hands. Seriously! Notice the myriad little tricks your fingers have for manipulating the ingredients and the utensils and all the other objects involved in this enterprise. Then compare your experience to sliding around Pictures Under Glass.

Tuesday, November 8th, 2011


The charming (and often hilarious) results of Hannah and Matt’s Music Hack Day activity.

The Myths of Mobile Context by Josh Clark

A PDF of the slides (with copious notes) from Josh’s brilliant presentation. I love this guy!

Sunday, November 6th, 2011

inter // states on Vimeo

A time-lapse video of Tokyo transportation.

“You Just Don’t Get It, Do You?” - A Montage of Cinema’s Worst Writing Cliche on Vimeo

This whole “supercut” thing …you still don’t get it, do you?

Friday, November 4th, 2011

The magic button — Make Everything OK

The most useful site on the web.

The Convergence

A fun platform game with a twist.

Wednesday, November 2nd, 2011

Retreats 4 Geeks presents Progressive Enhancement — 25–30 March 2012

Roll up, roll up! Get five nights food and lodging at a fantastic luxury horse ranch in the Rockies in March.

Oh, and myself and Aaron will be running workshops on progressive enhancement for you during that time too.

Official Google Webmaster Central Blog: GET, POST, and safely surfacing more of the web

This move by Google to start executing some POST requests makes me very uneasy: the web is agreement and part of that agreement is that POST requests are initiated by the user.

Goodbye time, datetime, and pubdate. Hello data and value. | HTML5 Doctor

A very even-handed look at the time and data debacle in HTML5.


When I first heard that Hixie had removed all traces of the time element from the ongoing HTML spec, my knee-jerk reaction was “This is a really bad idea!” But I decided not to jump in without first evaluating the arguments for and against the element’s removal. That’s what I’ve been doing over the past week and my considered response is:

This is a really bad idea!

The process by which the element was removed is quite disturbing:

  1. Hixie (as a contributer) opens a bug proposing that the time element be replaced with the more general data element.
  2. Lots of people respond, almost unanimously pointing out the problems with that proposal.
  3. Hixie (as the editor) goes ahead and does what exactly what he wanted anyway.

Technically that’s exactly how the WHATWG process works. The editor does whatever he wants:

This is not a consensus-based approach — there’s no guarantee that everyone will be happy! There is also no voting.

Most of the time, this works pretty well. It might not be fair but it seems to work more efficiently than the W3C’s consensus-based approach. But in this case the editor’s unilateral decision is fundamentally at odds with the most important HTML design principle, the priority of constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity. In other words costs or difficulties to the user should be given more weight than costs to authors; which in turn should be given more weight than costs to implementors; which should be given more weight than costs to authors of the spec itself, which should be given more weight than those proposing changes for theoretical reasons alone.

The specifier (Hixie) is riding roughshod over the concerns of authors.

I’m particularly concerned by the uncharacteristically muddy thinking behind Hixie’s decision. There are two separate issues here:

  1. Is the time element useful?
  2. Do we need a more general data element?

Hixie conflates these two questions.

He begins by bizarrely making the claim that time hasn’t had much uptake. This is demonstrably false. It’s already shipping in Drupal builds and Wordpress templates as well as having parser support in services and at least one browser. If anything, time is one of the more commonly used and understood elements in HTML5.

There’s a very good reason for that: it fulfils a need that authors have had for a long time—the ability to make a timestamp that is human and machine-readable at the same time. That’s the use case that the microformats community has been trying to solve with the abbr design pattern and the value-class pattern. Those solutions are okay, but not nearly as elegant and intuitive as having a dedicated time element.

Crucially the time element didn’t just specify the mechanism for encoding a machine-readable timestamp, it also defined the format, namely a subset of ISO 8601. That’s exactly the kind of unambiguous documentation that makes a specification useful.

Hixie correctly points out that there are cases for human and machine-readable data other than dates and times. He incorrectly jumps to the conclusion that the time is therefore a failure.

I think he’s right that there probably should be a dedicated element for marking up this kind of data. We already have the meta element but the fact that it’s a standalone element makes it tricky to explicitly associate the human-readable text. So the introduction of a new data may very well turn out to be a good idea. But it does not need to be introduced at the expense of the more specific time element.

I think there’s a comparison to be made with sectioning content. We’ve got the generic section element but then we also have the more specific nav, aside and article elements that can be thought of specialised forms of section. By Hixie’s logic, there’s no reason to have nav, aside and article when a section element has the same effect on the outlining algorithm. But we have those elements because they cover very common use cases.

Hixie’s reductio ad absurdum argument is that if there is a special element for timestamps, we should also have an element for every other possible piece of machine-readable data. If that’s the case we should also have an infinite amount of sectioning content elements: blogpost, comment, chapter, etc. Instead we have just the four elements—section, article, aside and nav—because they represent the most common use cases …perhaps 80%?

The use case that the time element satisfies (human and machine-readable timestamps) is very, very common. The actual mechanism may vary (the time element itself, the abbr pattern, etc.) but the cow path is very much in need of paving.

There’s also a disturbingly Boolean trait to Hixie’s logic. He lumps all machine-readable data into the same bucket. If he had paid attention to Tantek’s research on abstracting microformat vocabularies, he would have seen that it’s a bit more fine-grained than that. There’s a difference between straightforward name/value pairs (like fn or summary), URL values (like photo) and timestamps (like dtstart). The thing that distinguishes timestamps is that they have an existing predefined machine-readable format.

To strengthen his position Hixie introduced two strawmen into the discussion, claiming that the time element was intended to allow easier styling of dates and times with CSS and to also allow conversion of HTML documents into Atom. Those use cases are completely tangential to the fundamental reason for the existence of the time element. Hixie seems to have forgotten that he himself once had it enshrined in the spec that the purpose of the element was to allow users to add events to their calendars. I pointed out that this was an example usage of the more general pattern of machine-readable dates and times so the text of the spec was updated accordingly:

This element is intended as a way to encode modern dates and times in a machine-readable way so that, for example, user agents can offer to add birthday reminders or scheduled events to the user’s calendar.

No mention of styling. No mention of converting documents to Atom.

I’m not the only one who is perplexed by Hixie’s bullheaded behaviour. Steve Faulkner has entered a revert request on the W3C side of things (he’s a braver man than me: the byzantine W3C process scares me off). Ben summed up the situation nicely on Twitter. You can find plenty of other reactions on Twitter by searching for the hashtag #occupyhtml5. Bruce has written down his thoughts and the follow-on comments are worth reading. This reaction from Stephanie is both heartbreaking and completely understandable:

I have been pretty frustrated by this change. In fact, when I read the entire thread on the debacle, it nearly made me want to give up on teaching, and using HTML5. What’s the point when there’s really no discussion? A single person brings something up. Great arguments are made. And then he just does what he originally wanted to do anyway.

I’d like to think that a concerted campaign could sway Hixie but I don’t hold out much hope. Usually there’s only one way to get through to him and that’s by presenting data. Rightly so. In this case however, Hixie is ignoring the data completely. He’s also wilfully violating the fundamental design principles behind HTML5.

So what can we do? Well, just as with the incorrectly-defined semantics of the cite element we can make a stand and simply carry on using the time element in our web pages. If we do, then we’ll see more parsers and browsers implementing support for the time element. The fact that our documentation has been ripped away makes this trickier but it’s such a demonstrably useful addition to HTML that we cannot afford to throw it away based on the faulty logic of one person.

Hixie once said:

The reality is that the browser vendors have the ultimate veto on everything in the spec, since if they don’t implement it, the spec is nothing but a work of fiction. So they have a lot of influence—I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Keep using the time element.

Mobile web content adaptation techniques | mobiForge

This is article is mostly a decent round-up of development approaches to mobile but the summary lets it down by assuming that desktop users couldn’t possibly want the same functionality as mobile users — in my opinion, inferring people’s desires based purely on their device is extremely dangerous and downright patronising.

The New Patterns of Culture: Slow, Fast & Spiky

A thoughtful piece from Matt on the changes in cultural transmission that we should be embracing instead of bemoaning.

Animatable: One property, two values, endless possiblities

Lea documents a whole bunch of CSS animation possibilities.

BlackBerry Future Visions 2 - Leaked Video - YouTube

Possibly the least imaginative concept video ever made, this piece commissioned by Blackberry shows a dystopian near-future ruled by security departments run by people with very, very tired arms.

Tuesday, November 1st, 2011

Why No Time?

A single-serving website expressing the frustration and bewilderment at Hixie’s unilateral decision to drop the time element from HTML.

Elena Font Family | Process Type Foundry

A lovely new typeface from Nicole Dotin that’s available to purchase as a web font under the very reasonable terms of the Process license agreement.