Archive: January, 2011

At Clearleft towers, we’ve been having semi-regular movie nights, based around a connecting theme. Previous themes include car chases (The French Connection, Bullitt and Ronin) and films set at Christmas that aren’t about Christmas (Gremlins and Die Hard).

Last week’s movie night’s theme was near-future science fiction. We didn’t get around to watching Minority Report but we did watch Children of Men and Sunshine.

Danny Boyle’s Sunshine is one of those films that gets better with each viewing. Little by little, it’s edging up my list of all-time favourites. It has a sense of awe, wonder and humility in the face of science that’s genuinely Clarkeian.

It also has plenty of loving references to those other films featuring the trifecta of sci-fi elements: a ship, a crew, a signal. The nods to 2001 and Alien are clear, but something I didn’t catch until just the other day was that the character of Pinbacker was named for Sergeant Pinback from John Carpenter’s Dark Star.

I know this because, instead of our usual Thursday evening pub gathering and book swapping, the Brighton Speculative Fiction Group this week hosted a puppet show. Paul and Richard recreated all of Dark Star using cardboard, some string, a few dolls and some strategic lighting.

It was one of the best things I’ve ever seen. Here’s the highlight reel.

Craig Grannell from .Net magazine got in touch to ask me a few short questions about last week’s events around HTML5. I thought I’d share my answers here rather than wait for the tortuously long print release cycle.

What are your thoughts on the logo?

The logo is nice. Looks pretty sharp to me.

Why were you unhappy with W3C’s original stance (“general purpose visual identity”)? What do you think now they’ve changed this?

I was unhappy with the W3C’s original definition of HTML5 in the logo’s accompanying FAQ, where they lumped CSS, SVG and WOFF under the “HTML5” banner. I’m happy they changed that.

What’s your thinking on the current state of the HTML5 situation, given that WHATWG is dropping the 5 and just going with HTML?

I think the current situation makes things much clearer. The WHATWG are working on a continuous, iterative document called simply HTML. The W3C use that as a starting pointing for nailing down an official specification which will be the fifth official iteration of the HTML language called, sensibly enough, HTML5.

The WHATWG spec is the place to look for what’s new and evolving. The W3C spec, once it goes into Last Call, is the place to look for the official milestone that is HTML5. In practice, the two specs will be pretty much identical for quite a while yet.

But the truth is that authors shouldn’t be looking at specs to decide what to use—look at what browsers support in order to decide if you should use a particular feature—look at the spec to understand how to use features of HTML5.

For authors, it probably makes more sense to talk about HTML rather than HTML5. Remember that most of HTML5 is the same as HTML 4.01, HTML 3.2, etc. Answering yourself a question like “When can I use HTML5?” is a lot easier to answer if you rephrase it as “When can I use HTML?”

Most of the time, it makes a lot more sense to talk about specific features rather than referring to an entire specification. For example, asking “Does this browser support HTML5?” is fairly pointless, but asking “Does this browser support canvas?” is much more sensible.

After seeing (and hearing) what Brian was doing at History Hack Day, I decided I’d have to have a play with Tropo. Like Twilio, it’s a service that allows you to build voice-activated apps that you call up and talk to.

The API is pretty straightforward and it seems like there’s quite a lot that you can do as a developer before upgrading to a paid account. They’ll also host your code for you, and you have a choice of scripting languages.

At the most basic level, you can send text-to-voice messages:

say("Hello world")

But you can also give it audio files to play:

say(http://example.com/helloworld.mp3)

Huffduffer has the locations of thousands of audio files, so I thought a voice interface onto Huffduffer’s collection would be fun.

Call +1 202 600 8751 in the US, +44 2035 142722 in the UK, or use Skype. When the nice digital man on the other end picks up the phone and asks you want you want to hear, you can respond with “what’s new”, “what’s popular”, or say a tag like music, science, history, politics, technology, etc.

The script then fetches the latest files with that tag and will go through them with you one by one, asking “Would you like to hear… ?” followed by the title. If you don’t like the sound of it, just say no. When you find something you do want to hear, say yes. It will then start playing and you will be listening to a podcast down a telephone line.

I call it the Huffduffer Hotline. The code is on Github. If you fancy playing around with the Tropo API and want to use Huffduffer’s links to audio files, go ahead. You should find everything you need through the Huffduffer API.

If people find the Huffduffer Hotline useful or just plain fun, I’ll upgrade from the developer account to get better performance. Let me know your thoughts on Get Satisfaction.

I spent the weekend at The Guardian offices in London at History Hack Day. It was rather excellent. You’d think I’d get used to the wonderful nature of these kinds of events, but I once again I experienced the same level of amazement that I experienced the first time I went to hack day.

The weekend kicked off in the traditional way with some quickfire talks. Some lovely people from The British Museum, The British Library and The National Archives talked about their datasets, evangelists from Yahoo and Google talked about YQL and Fusion Tables, and Max Gadney and Matthew Sheret got us thinking in the right directions.

Matthew Sheret was particularly inspiring, equating hackers with time travellers, and encouraging us to find and explore the stories within the data of history. The assembled geeks certainly took that message to heart.

Ben Griffiths told the story of his great-uncle, who died returning from a bomber raid on Bremen in 1941. Using data to put the death in context, Ben approached the story of the lost bomber with sensitivity.

Simon created geStation, a timeline of when railway stations opened in the UK. On the face of it, it sounds like just another mashup of datetimes and lat-long coordinates. But when you run it, you can see the story of the industrial revolution emerge on the map.

Similarly, Gareth Lloyd and Tom Martin used Wikipedia data to show the emerging shape of the world over time in their video A History of the World in 100 Seconds, a reference to the BBC’s History of the World in 100 Objects for which Cristiano built a thoroughly excellent mobile app to help you explore the collection at British Museum.

Brian used the Tropo API to make a telephone service that will find a passenger on the Titanic who was the same age and sex as you, and then tell you if they made it onto a lifeboat or not. Hearing this over the phone makes the story more personal somehow. Call +1 (804) 316-9215 in the US, +44 2035 142721 in the UK, or +990009369991481398 on Skype to try it for yourself.

I was so impressed with the Tropo API that I spent most of History Hack Day working on a little something for Huffduffer …more on that later.

My contribution to the hack day was very modest, but it was one of the few to involve something non-digital. It’s called London On A Stick.

A pile of USB sticks had been donated to History Hack Day, but nobody was making much use of them so I thought they could be used as fodder for Dead Drops. I took five USB sticks and placed a picture from The National Archives on Flickr Commons on each one. Each picture was taken somewhere in London and has been geotagged.

I slapped sticky notes on the USB sticks with the location of the picture. Then I asked for volunteers to go out and place the sticks at the locations of the pictures: Paddington, Trafalgar Square, Upper Lambeth, St. Paul’s and Tower Bridge. Not being a Londoner myself, I’m relying on the natives to take up the challenge. You can find the locations at icanhaz.com/londononastick. I ducked out of History Hack Day a bit early to get back to Brighton so I have no idea if the five sticks were claimed.

Although my contribution to History Hack Day was very modest, I had a really good time. Matt did a great job putting on an excellent event.

It was an eye-opening weekend. This hack day put the “story” back into history.

Two good things have happened.

WHATWG

Firstly, as I hoped, the WHATWG have updated the name of their work to simply be HTML. This is something they tried to do a year ago, and I kicked up a stink. I was wrong. Having a version number attached to an always-evolving standard just doesn’t make sense. As Hixie put it:

…the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

This change means that the whole confusing 2022 business that was misunderstood by so many people is now history:

Now that we’ve moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

The spec is currently labeled as a “Living Standard”. Personally, I find the “Living Standard” strapline a bit cheesy. I’d much rather the document title was simply “HTML” followed by the date of the last update.

Note that this change only applies to the WHATWG. The W3C will continue to pursue the “snapshot” model of development so the spec there definitely retains the number 5 and will follow the usual path of Working Draft, Last Call, Proposed Recommendation, and so on.

I think this difference makes it clearer what each group is doing. It was a pretty confusing situation to have two groups working on two specs, both called HTML5. Now it’s clear that the WHATWG is working more like how browsers do: constantly evolving and implementing features rather than entire specifications. Meanwhile the W3C are working on having a development milestone of those features set in stone and labelled as the fifth revision to the HTML language …and I think that is also an important and worthy goal.

W3C

The second piece of good news is that the W3C have backtracked on their “embrace and extend” attitude towards buzzwordism. When they launched the new HTML5 logo a few days ago, the W3C Communications Team initially said that HTML5 included CSS, SVG and WOFF‽ As Tantek said:

Fire the W3C Communications person that led this new messaging around HTML5 because it is one of the worst messages (if not the worst) about a technology to ever come out of W3C.

Following the unsurprising outbreak of confusion and disappointment that this falsehood caused, the W3C have now backtracked. HTML5 means HTML5. The updated FAQ makes it very clear that CSS3 is not part of HTML5.

Hallelujah!

I really wasn’t looking forward to starting every HTML5 workshop, presentation or article with the words, “Despite what the W3C says, HTML5 is not a meaningless buzzword…” Now I can safely say that the term “HTML5” refers to a technical specification, published at the W3C, called HTML5. Also, I can use that nice logo with a clear conscience.

Over time though, I’ll probably follow the WHATWG’s lead and simply talk about “what’s new in HTML.” As Remy points out, there are pedagogical advantages to untethering version numbers:

I don’t have to answer “Is HTML ready to be used?” ‘cos that’s a really daft question!

• Webmonkey: HTML5 Gains Logo, Loses Meaning

  It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

• CNET News: W3C’s new logo promotes HTML5—and more

  Curiously, though, the standards group—the very people one might expect to have the narrowest interpretation of what exactly HTML5 means—instead say it stands for a swath of new Web technologies extending well beyond the next version of Hypertext Markup Language.

• GigaOM: The Truth Behind HTML5′s New Logo Fiasco

  It’s as if the government suddenly announced that from today, all vegetables will be called potatoes, just because some vegetables are potatoes.

• The Register: W3C tackles HTML5 confusion with, um, more confusion

  And much like Apple, Google, and Microsoft before it, the organization that oversees HTML5 has confused it with all sorts of other web standards.

• The Web Standards Project: HTML5 logo: be proud, but don’t muddy the waters!

  Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as “HTML5”. We can’t imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time)

• Roger Johansson: HTML5 now includes CSS3, SVG and WOFF?

  This move from the W3C will not help people differentiate between very different technologies.

• CSS Squirrel: HTML5 Super Friends Assemble!

  The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization?

One year ago, I objected strenuously when the WHAT WG temporarily changed the name of their spec from “HTML5” to plain ol’ “HTML”:

Accurate as that designation may be, I became very concerned about the potential confusion it would cause.

I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion.

Now that term the “HTML5” has become completely meaningless—even according to the WC3—I think it’s time to rip off the bandaid and flip that switch.

I was wrong. Hixie was right. The spec should be called HTML.

If you need an all-encompassing term for every front-end technology under the sun, go ahead and use the term “HTML5.” Although personally, I quite like “the Web.”

Update: The WHATWG have duly updated the name of the spec.

The W3C have unveiled a logo for HTML5. I’m not sure the world needs such a logo, but I think it looks pretty good. It reminds me of some of the promotional materials used by the Web Standards Project back in the day—simple bold lines that work well at small sizes, with a whiff of Russian constructivism.

But I take issue with the scope of what this logo is supposed to represent. From the Frequently Asked Questions:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

What. A. Crock.

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

Don’t get me wrong; I don’t mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn’t mind …but this is coming straight from the horse’s mouth (or, in this case, straight from the horse’s ass).

“But,” cry the cheerleaders of ambiguity, “we need some kind of term to refer to HTML5 plus CSS3!”

Citation needed.

We never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless? As I said before:

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

But I guess I’ve lost that battle. Now even the W3C are intent on blurring the distinction between different technologies to the extent that using a particular font file format qualifies as HTML5.

So now what do I do when I want to give a description of a workshop, or a talk, or a book that’s actually about HTML5? If I just say “It’s about HTML5,” that will soon be as meaningful as saying “It’s about Web 2.0,” or “It’s about leveraging the synergies of disruptive transmedia paradigms.” The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:

• “HTML5, no really”,
• “The parts of HTML5 that are documented in the specification labelled HTML5”,
• “Actual HTML5”

But I think the term that’s going to be most accurate is:

• “HTML”

Update: The W3C have changed their mind. Yay!

One of the many form enhancements provided by HTML5 is the datalist element. It allows you to turn a regular input field into a combo-box.

Using the list attribute on an input, you can connect it to a datalist with the corresponding ID. The datalist itself contains a series of option elements.

<input list="suggestions">
<datalist id="suggestions">
    <option value="foo"></option>
    <option value="bar"></option>
    <option value="baz"></option>
</datalist>

I can imagine a number of use cases for this:

• “Share this” forms, like the one on Last.fm, that allow you to either select from your contacts on the site, or enter email addresses, separated by commas. Using input type="email" with a multiple attribute, in combination with a datalist would work nicely.
• Entering the details for an event, where you can either select from a list of venues or, if the venue is not listed, create a new one.
• Just about any form that has a selection of choices, of which the last choice is “other”, followed by “If other, please specify…”

You can take something like this:

<label for="source">How did you hear about us?</label>
<select name="source">
    <option>please choose...</option>
    <option value="television">Television</option>
    <option value="radio">Radio</option>
    <option value="newspaper">Newspaper</option>
    <option>Other</option>
</select>
If other, please specify:
<input id="source" name="source">

And replace it with this:

<label for="source">How did you hear about us?</label>
<datalist id="sources">
    <option value="television"></option>
    <option value="radio"></option>
    <option value="newspaper"></option>
</datalist>
<input id="source" name="source" list="sources">

The datalist element has been designed according to one of the design principles driving HTML5—Degrade Gracefully:

On the World Wide Web, authors are often reluctant to use new language features that cause problems in older user agents, or that do not provide some sort of graceful fallback. HTML 5 document conformance requirements should be designed so that Web content can degrade gracefully in older or less capable user agents, even when making use of new elements, attributes, APIs and content models.

Because the datalist element contains a series of option elements with value attributes, it is effectively invisible to user-agents that don’t support the datalist element. That means you can use the datalist element without worrying it “breaking” in older browsers.

If you wanted, you could include a message for non-supporting browsers:

<datalist id="sources">
    Your browser doesn't support datalist!
    <option value="television"></option>
    <option value="radio"></option>
    <option value="newspaper"></option>
</datalist>

That message—“Your browser doesn’t support datalist!”—will be visible in older browsers, but browsers that support datalist know not to show anything that’s not an option. But displaying a message like this for older browsers is fairly pointless; I certainly wouldn’t consider it graceful degradation.

In my opinion, one of the best aspects of the design of the datalist element is that you can continue to do things the old-fashioned way—using a select and an input—and at the same time start using datalist. There’s no violation of the DRY principle either; you can use the same option elements for the select and the datalist:

<label for="source">How did you hear about us?</label>
<datalist id="sources">
    <select name="source">
        <option>please choose...</option>
        <option value="television">Television</option>
        <option value="radio">Radio</option>
        <option value="newspaper">Newspaper</option>
        <option>Other</option>
    </select>
    If other, please specify:
</datalist>
<input id="source" name="source" list="sources">

Browsers that support datalist will display the label “How did you hear about us?” followed by a combo-box text field that allows the user to select an option, or enter some free text.

Browsers that don’t support datalist will display the the label “How did you hear about us?” followed by a drop-down list of of options (the last of which is “other”), followed by the text “If other, please specifiy”, followed by a text field.

Take a look at this example in Opera to see datalist in operation. Take a look at it in any other browser to see the fallback. The source is on Github if you’d like to play around with it.

WebKit’s mistake

If you try that example in any browser, you’ll get something that works; either through datalist support or through the select fallback …unless the browser is using WebKit.

It took me a while to figure out why this would be the case. I didn’t think that Safari or Chrome supported datalist and a little digging around with object detection in JavaScript confirmed this. So why don’t those browsers follow the standard behaviour and simply ignore the element they don’t understand and render what’s inside it instead.

Here’s the problem: line 539 of WebKit’s default CSS:

datalist {
    display: none;
}

This is pretty much the worst possible behaviour for a browser to implement. An element should either be recognised—like p, h1 or img—and parsed accordingly, or an element is unrecognised—like foo or bar—and ignored. WebKit does not support the datalist element (even in the current nightly build), so the element should be ignored.

Fortunately the problem is easily rectified by adding something like this to your own stylesheet:

datalist {
    display: inline-block;
}

I’ve submitted a bug report on the WebKit Bugzilla.

Update: That Webkit bug has now been fixed so the extra CSS is no longer necessary.

David made a comment on Twitter about some markup he was working on:

Feels dirty setting id’s on main HTML5 page header and footer, but overriding inheritance they cause seems needlessly laborious.

I know the feeling. I don’t like using IDs at all, unless I want part of a document to be addressable through the fragment identifier portion of the URL. While I think it’s desirable to use the id attribute to create in-document permalinks, I don’t think it’s desirable to use the id attribute just as a styling hook. Its high specificity may seem a blessing but, in my experience, it quickly leads to duplicated CSS. IDs are often used as a substitute for understanding the cascade.

Nicole feels the same way about ID selectors, and she knows a thing or two about writing efficient CSS.

Back to David’s dilemma. Let’s say you’re targetting header and footer elements used throughout your document in sections, articles, etc. All you need to use is an element selector:

header {
// regular header styles
}

But what about the document-level header and footer? They’re probably styled very differently from the headings of sections and articles.

You could try using a child selector:

body > header

But there’s no guarantee that the document header will be a direct child of the body element. Hence the use of the id attribute—header id="ID":

header#ID {
// page header styles
}

There is another way. In HTML5 you can, for the first time, use ARIA roles and still have a valid document. ARIA landmark roles add an extra layer of semantics onto your document, distinguishing them as navigational landmarks for assistive technology.

Some of these landmark roles—like IDs—are to be used just once per document:

Within any document or application, the author SHOULD mark no more than one element with

• banner
• main
• contentinfo

That’s useful for two reasons. One, the existence of role="main" means it is not necessary for HTML5 to provide an element whose only semantic is to say “this is the main content of the document.”

A lot of people have asked for such an element in HTML5. “We’ve got header, footer and aside,” they say. “Why not maincontent too?”

But whereas header, footer and aside can and should be used multiple times per document, a maincontent element would, by necessity, only be used once per document. There are very few elements in HTML that are like that: the html element itself, the title element, head and body (contrary to popular opinion—likely spread by SEO witch-doctors—the h1 element can be used more than once per document).

Now the desired functionality of semantically expressing “this is the main content of the document” can be achieved, not with an element, but with an attribute value: role="main".

The rough skeleton of your document might look like this:

<header role="banner"></header>
<div role="main"></div>
<footer role="contentinfo"></footer>

Now you can see the second advantage of these one-off role values. You can use an attribute selector in your CSS to target those specific elements:

header[role="banner"] {
// page header styles
}

Voila! You can over-ride the default styling of headers and footers without resorting to the heavy-handed specificity of the ID selector.

And, of course, you get the accessibility benefits too. ARIA roles are supported in JAWS, NVDA and Voiceover

Speaking of URLs…

We were having a discussion in the Clearleft office recently about that perennially-tricky navigation pivot: tags. Specifically, we were discussing how to represent the interface for combinatorial tags i.e. displaying results of items that have been tagged with tag A and tag B.

I realised that this was functionality that I wasn’t even offering on Huffduffer, so I set to work on implementing it. I decided to dodge the interface question completely by only offering this functionality through the browser address bar. As a fairly niche, power-user feature, I’m not sure it warrants valuable interface real estate—though I may revisit that challenge later.

I can’t use the + symbol as a tag separator because Huffduffer allows spaces in tags (and spaces are converted to pluses in URLs), so I’ve settled on commas instead.

For example, there are plenty of items tagged with “music” (/tags/music) and plenty of items tagged with “science” (/tags/science) but there’s only a handful of items tagged with both “music” and “science” (/tags/music,science).

This being Huffduffer, where just about every page has corresponding JSON, RSS and Atom representations, you can also subscribe to the podcast of everything tagged with both “music” and “science” (/tags/music,science/rss).

There’s an OR operator as well; the vertical pipe symbol. You can view the 60 items tagged with “html5”, the 14 items tagged with “css3”, or the 66 items tagged with either “html5” or “css3” (/tags/html5|css3).

Wait a minute …66 items? But 60 plus 14 equals 74, not 66!

The discrepancy can be explained by the 8 items tagged with both “css3” and “html5” (/tags/html5,css3).

The AND and OR operators can be combined, so you can find items tagged with either “science” or “religion” that are also tagged with “politics” (/tags/science|religion,politics).

While it’s fun to do this in the browser’s address bar, I think the real power is in the way that the corresponding podcast allows you to subscribe to precisely-tailored content. Find just the right combination of tags, click on the RSS link, and you’re basically telling iTunes to automatically download audio whenever there’s something new that matches criteria like:

• everything that is tagged with either “science fiction” or “fantasy” or “horror” and is also tagged with “romance” (/tags/science+fiction|fantasy|horror,romance),
• everything that is tagged with “google” and is also tagged with either “apple” or “microsoft” or “yahoo” (/tags/google,apple|microsoft|yahoo).

I’m sure there are plenty of intriguing combinations out there. Now I can use Huffduffer’s URLs to go spelunking for audio gems at the most promising intersections of tags.

Here’s what’s on my desk at work: an iMac (with keyboard, mouse and USB cup warmer), some paper, pens, a few books and an A4-sized copy of Paul Downey’s The URI Is The Thing—an intricately-detailed Boschian map of all things RESTful. It’s released under a Creative Commons license, so feel free to download the PDF from archive.org, print it out and keep it on your own desk.

I love good URL design. I found myself nodding vigorously in agreement with just about every point in this great piece on URL design:

URLs are universal. They work in Firefox, Chrome, Safari, Internet Explorer, cURL, wget, your iPhone, Android and even written down on sticky notes. They are the one universal syntax of the web. Don’t take that for granted.

That’s why I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness, but it’s related to what Ben said in his comment to Nicholas’s article on how many users have JavaScript disabled:

The truth is that if site content doesn’t load through curl it’s broken.

Or, as Simon put it:

The Web for me is still URLs and HTML. I don’t want a Web which can only be understood by running a JavaScript interpreter against it.

If I copy and paste the URL of that tweet, I get http://twitter.com/#!/simonw/status/25696723761 …which requires a JavaScript interpreter to resolve.

Fortunately, those fragile Twitter URLs will be replaced with proper robust identifiers if this demo by Twitter engineer Ben Cherry is anything to go by. It’s an illustration of saner HTML5 history management using the history.pushState method.

You may have noticed that there’s a second edition of DOM Scripting out. I can’t take any credit for it; I had very little to do with it. But I’m happy to report that the additions meet with my approval.

I’ve written about it on the DOM Scripting blog if you want all the details on what’s new. In short, all the updates are good ones for a book that’s now five years old.

If you’ve already got the first edition, you probably don’t need this update, but if you’re looking for a good introduction to JavaScript with a good smattering of Ajax and HTML5, and an additional dollop of jQuery, the second edition of DOM Scripting will serve you well.

The cover of the second edition, alas, is considerably shittier than the first edition. So don’t judge the second edition of a book by its cover.

Like many others, I was the grateful recipient of a Kindle this Christmas. I’m enjoying having such a lightweight reading device and I’m really enjoying the near-ubiquitous free connectivity that comes with the 3G version.

I can’t quite bring myself to go on a spending spree for overpriced DRM’d books with shoddy layout and character encoding, so I’ve been getting into the swing of things with the freely-available works of Cory Doctorow. I thoroughly enjoyed For The Win—actually, I read that one on my iPod Touch—and I just finished Makers on the Kindle.

The plot rambles somewhat but it’s still an entertaining near-future scenario of hardware hackers creating and destroying entire business models through the ever-decreasing cost and ever-increasing power of street-level technology.

Cracking open the case of a particularly convincing handset, he offers advice on identifying a fake: a hologram stuck on the phone’s battery is usually a good indication that the product is genuine. Two minutes later, Chipchase approaches another stall. The shopkeeper, a middle-aged woman, leans forward and offers an enormous roll of hologram stickers.

Chipchase, mouth agape, takes out the Canon 5D camera that he uses to catalogue almost everything he sees. “What are these for?” he asks, firing off a dozen photographs in quick succession. “You stick them on batteries to make them look real,” she says, with a shrug. Chipchase smiles, revelling in the discovery. “I love this!” he yelps in delight, and thanks the shopkeeper before heading off to examine the next stall.

That isn’t a passage from Makers. That’s from a Wired magazine article by Bobbie: a profile of Jan Chipchase and his predilection for Shanzai; counterfeit electronic goods on the streets of Shanghai …not unlike the Bambook Kindle clone.