Archive: August, 2009


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

Monday, August 31st, 2009

HTML 5 Super Friends

My buddies and I express our support for HTML5 ...with caveats ...and unicorns.

The HTML5 Semantics Debate - Opinions - MIX Online

A thoughtful piece on the question of extensibility in HTML5.

Sunday, August 30th, 2009

HTML5 and me

I can never pinpoint the exact moment at which I “get into” a particular technology. CSS, DOM Scripting, microformats …there was never any Damascene conversion to any of them. Instead, I’d just notice one day, after gradually using the technology more and more, that I was immersed in it.

That’s how I feel about now.

There’s another feeling that accompanies this realisation. I remember feeling it about CSS in the late 90s and about DOM Scripting half a decade ago. At the same time as I look up from my immersion, I cast a glance around the web development landscape and ask Why aren’t more people paying attention to this?

In the case of HTML5, this puzzling state of affairs can, to a large extent, be explained by the toxic 2022 meme. Working web developers with an idle interest in HTML5 would google the term, find a blog post telling that it won’t be “ready” until 2022, and then happily return to their work, comforted by the knowledge that HTML5 was some distant dream on the horizon—one that doesn’t affect them in any way today.

Nothing could be further from the truth. The Last Call Working Draft status is (optimistically) planned for October; that’s one month away.

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

If you want to have a say in the formation of the most important web standard in existence, don’t put off getting involved. As Bruce says, If you don’t vote, you can’t bitch.

Still, I think the attitude of most web developers towards HTML5 right now is, at the very least, “interested, if a little sceptical”—that’s certainly how I felt when I started dabbling in it.

A little while back, I got together with some of my interested (if a a little sceptical) colleagues in New York, thanks to a generous invitation from Zeldman.

Dan Cederholm, Jeremy Keith, Eric Meyer, Ethan Marcotte, Tantek Çelik, Nicole Sullivan, Wendy Chisholm

After a fairly intense two days of poring over the spec, I think it’s fair to say that, on balance, the interest increased and the scepticism decreased. That’s not to say that everything looks rosy in the current incarnation of HTML5. When you’ve got some of the smartest front-end web developers I know of in the same room together and they all agree that some parts of the spec are confusing or downright wrong, that’s quite worrying.

On the plus side, most of the issues are pretty minor in the grand scheme of things. It’s fair to say that most of the stuff that interests web authors—the semantic side of things—only accounts for a small part of HTML5. Most of the HTML5 specification is about error handling, APIs and shiny new interactive content. There are plenty of programmers and browser makers forging those powerful new tools. But as qualified as they are to hammer out those complex constructs, they are not necessarily the most qualified to make decisions on creating new structural elements. For that, you need the input of authors. And authors have been decidedly slow to get involved with HTML5.

It’s time for authors to get involved. I believe our voices will be welcomed. According to the HTML design principles:

…consider users over authors over implementors over specifiers over theoretical purity.

I’ll get the ball rolling with my own little list of things that are troubling me…


I’m with Bruce and Remy. If the small element is being redefined for disclaimers, caveats, legal restrictions, or copyrights, it needs to be handling how that kind of content is published in the wild. That means it needs to be able to wrap paragraphs, lists and other flow content.

Alternatively, it should go the way of its evil twin, the big element, and simply be deprecated …sorry, I mean obsolete and non-conforming.


I’ll join in the chorus of people who think that the restrictions on the information that the new time element can contain are unnecessarily draconian. You can encode a date and time, you can encode a date, but you can’t encode just a month and a year. So you can’t make a piece of information like “April 1912” machine-readable. The spec says the time element:

…is intended as a way to encode modern dates and times in a machine-readable way

Which is great. But the sentence doesn’t finish there. It goes on:

so that user agents can offer to add them to the user’s calendar.

That’s one use case! I don’t think it’s wise to rain on the parade of anyone wanting to build, say, timeline mashups. Trying to mandate use cases ahead of time is not just counter-productive, it’s probably impossible. Can you imagine if Flickr had launched their API with strict instructions that it could only be used for one particular purpose?


I have nothing against the figure element itself, although it does seem uncomfortably close to aside, but the insistence on recycling the legend element to handle the caption is problematic.

Don’t get me wrong: I’m all for re-using existing elements rather then creating new ones, and I know that Hixie looked at all the options. But the way that browsers currently treat the legend element makes it unusable outside of a form.

I think that the label element could work instead.


Just like figure, the details element reuses legend. In this case, label won’t do the trick. details is an interactive element and it doesn’t look like the label element can be made keyboard accessible.

In this case, as undesirable as it is, a new element may be called for.


I’ve got two issues with the article element.

  1. Firstly, its definition sounds awfully similar to section. I’m not convinced that there needs to be two different elements. Having two elements that look like a duck, walk like a duck and quack like a duck is just going to lead to confusion amongst authors wondering which duck to use.

  2. The article element, unlike the section element can take an optional pubdate attribute to encode the publication date. I’m all in favour of having this information be machine-readable but the pubdate attribute smells like dark data, subject to metacrap rottage. In most cases, the publication date will be repeated in the content of the article anyway, so I’m in favour of adding a flag there rather than duplicating data. A Boolean pubdate attribute on a time element within an article header or footer should do the trick.

    Update: Belay that last gripe, ensign. As proof of just how fast this spec moves, less than 24 hours after I published this, Hixie has implemented what I was suggesting.

Speaking of footer, this one is the biggie…


There is a big disconnect between what the HTML5 spec calls a footer and what authors on the web call a footer.

According to the spec, you’re only supposed to put some kinds of content inside a footer:

Flow content, but with no heading content descendants, no sectioning content descendants, and no header or footer element descendants.

That means no nav or headings in footer. The way that the footer element is defined in the spec, it’s a slightly more expanded version of address.

Ah, address! One of the most problematic elements in HTML 4. It is often incorrectly used to mark up street addresses. But is it any wonder? When an element has a name address, it’s hardly surprising that authors are going to use it for marking up addresses. The same thing is going to happen with footer.

The term “footer” was not invented for HTML5. It’s been in use on the web for years and in print for even longer. But if you ask any author to define what they mean by the term “footer”, you’ll get a very different definition to the one in the HTML5 spec. They may even point to specific examples of footers on sites like Flickr or on blogs, where they contain headings and navigation.

To be fair, when the new structural elements were being forged back in 2005, there wasn’t as much prevalence of what Derek Powazek termed fat footers. So when Hixie ran his analytics on a shitload of web pages crawled by Google and found that “footer” was by far the most common class name, most footer content was pretty meagre. But usage changes (see also: time).

The way that the element named footer is defined in HTML5—to be used multiple times in a single document in sections and articles as well as at the document level—is very different from the convention named footer in common usage on the web today. Most of the instances of what authors call a footer are more like what the HTML5 spec defines as aside.

I don’t want to spend the next decade telling authors not to mark up their footers as footers. It was bad enough telling people not to mark up addresses as addresses. In any case, authors aren’t going to listen. If they see there’s an element called footer, they will assume it refers to the device known as a footer, and mark up their content accordingly. At that point, the HTML5 spec will have become a work of fiction instead of documenting what’s actually on the web.

One of two things needs to happen. Either:

  1. The content model of footer is updated to match that of header, which is much more liberal in what it accepts, or:
  2. The name of the element currently called footer should be changed to match the current, restrictive definition. I suggest using contentinfo, which is the name of an existing ARIA role for exactly this kind of content.

ARIA roles, by the way, are an excellent addition to HTML5. ARIA integration is a win for ARIA and a win for HTML5, in my opinion. Most of all, it’s a win for authors who now have a whole swathe of extra semantics they can sprinkle into their documents (and use as styling hooks with attribute selectors).

Thus endeth my list of things I want to see fixed in HTML5. I’m leaving out the massive issue of canvas accessibility because:

  1. that’s beyond my area of expertise,
  2. smarter people than me are working on it, and
  3. I think that canvas would probably benefit from being spun off into a separate spec.

There are other little things that bother me in HTML5—hgroup smells funny, cite shouldn’t be restricted to titles of works, and I miss the rev attribute on links—but those are all personal foibles; opinions unsupported by data. I’d rather concede than argue without data.

Because, make no mistake, data is what’s needed if you want to affect change in HTML5. Despite the attempts to paint Hixie as a stubborn, opinionated dictator, he is himself a slave to data. He shows an almost robot-like ability to remove his own ego from a debate and follow where the data leads.

If you are an author of HTML documents, I strongly encourage you to get involved in the HTML5 process.

  1. Read the spec.
  2. Join the mailing list.
  3. Hang out in the IRC channel.

Like I said, most of the spec and discussion is about APIs rather than semantics, but it’s precisely because the spec isn’t directly aimed at authors that authors need to get involved.

three frames

There is something utterly hypnotic and disturbing about these three-frame looping animations.

Read Regular / Introduction

A forthcoming typeface designed specifically to help people with dyslexia read and write more effectively.

Saturday, August 29th, 2009

All Sorts - a linguistic experiment

Collective nouns, collected.


Asteroids implemented using HTML5's canvas.

Why is HTML Suddenly Interesting? - O'Reilly Radar

Simon St. Laurent explains why mobile support for HTML5 mitigates Microsoft's dominance of desktop web browsing.

Friday, August 28th, 2009

Whatcha Readin' For? - Handy TextMate tips for working with HTML & CSS

Some very handy Textmate tips from Emil ....especially the bit about doing calculations for vertical rhythm.

Thursday, August 27th, 2009

Webmaster Tools - Rich Snippets Testing Tool

A tool from Google to help you see how your microformated content is showing up.

The Good Enough Revolution: When Cheap and Simple Is Just Fine

A great article about the rising prevalence of "rough consensus and running code" in the real world.

Wednesday, August 26th, 2009

Biscuit Tin - Random is good.

The iPhone App of Magnetic North's wonderful serendipitous Flickr photo viewer is now available for free. It's lovely.

ephemera assemblyman: Film Poster Paintings from Ghana

A wonderful set of folk-art movie posters from mobile cinemas in Ghana.

New co-chairs for HTML Working Group from Tim Berners-Lee on 2009-08-26 ( from August 2009)

Maciej Stachowiak is an inspired choice as co-chair of the HTMLWG. His evenhand peace-making has already made him an HTML5 hero.

Erik Spiekermann | design mind

Erik Spiekermann expounding on the beauty – and the difficulty – of designing numbers.

HTML 5–What I’m Watching at Wendy Chisholm

Wendy gives some commentary from her ringside seat at the theatre of HTML5.

Tuesday, August 25th, 2009

Health care and the public’s resistance to change : The New Yorker

James Surowiecki explains how loss aversion is affecting the health care "debate" in the USA.

The Value Class Pattern - Articles - MIX Online

A microformats article by yours truly, reworking a blog post from a while back about the value class pattern.

Make Photoshop Faster

Two little tips courtesy of Dan.

HTML 5 Outliner

A very handy tool to help you check the outline algorithm in HTML5.

Monday, August 24th, 2009

Typedia: A Shared Encyclopedia of Typefaces

Like Wikipedia for typefaces. Beautiful work from Jason, Dan, and others.

Sunday, August 23rd, 2009

Goudy Fonts

"A tribute to two former bookkeepers who impacted American design & typography for all time."

Friday, August 21st, 2009

Amazon® AWS HMAC signed request using PHP

Since Amazon decided to require signed requests for its API, I'm going to have to use this code to keep Huffduffer and The Session working. Grrrr... cool APIs don't change.

Wednesday, August 19th, 2009 - The JavaScript Conference

A two day JavaScript conference in Berlin in November. Looks like it could be very good (although it'll have to be very good indeed to top the Full Frontal conference, also in November).

By Popular Demand, We’re Keeping the Term Extraction Service (Yahoo! Developer Network Blog)

Good news, everyone. Yahoo aren't shutting down the term extractor API. Happy developer is happy. Now if only they save GeoCities...

Tuesday, August 18th, 2009

Dive Into HTML 5

Watch this space for Mark Pilgrim's dive excursions into HTML5.


Brendan Dawes pointed me to this wonderfully playful creation. It's Flash-free, believe it or not.

Radio - The New York Moon

Gorgeous visual design for an interestingly eclectic site.

Monday, August 17th, 2009

This Is The Only Level | Armor Games

Fiendishly clever and joyful platform game ...and it only has only level.

Re-finding five numbers

So, remember when I posted all those episodes of Simon Singh’s Five Numbers radio series on Pownce so that they’d have permanent URLs? Yeah, well, so much for that.

Fortunately Brian had saved all the MP3s. I’ve posted them on S3 and huffduffed them all. I can be fairly confident that Huffduffer won’t be going the way of Pownce, Magnolia, Geocities, and so many more.

Anyway, if you want to listen to the fifteen episodes of the three radio series’ on mathematics, you can subscribe to the podcast at

Or you can listen to each episode at these permanent URLs:

  1. Five Numbers

    1. A Countdown to Zero
    2. Simple as Pi
    3. The Golden Ratio
    4. The Imaginary Number
    5. Infinity
  2. Another Five Numbers

    1. The Number Four
    2. The Number Seven
    3. The Largest Prime Number
    4. Kepler’s Conjecture
    5. Game Theory
  3. A Further Five Numbers

    1. 1 — The Most Popular Number
    2. 2 — At The Double
    3. 6 Degrees of Separation
    4. 6.67 x 10^-11 – The Number That Defines the Universe
    5. 1729 — The First Taxicab Number

Saturday, August 15th, 2009


A cute and poignant resignation letter video game form.

Thursday, August 13th, 2009

“Misunderstanding Markup” 日本語訳

Turning Japanese, I think I'm turning Japanese, I really think so.

Wednesday, August 12th, 2009

Probably Bad News: News fails, because journalism isn't dying fast enough.

Enjoyable schadenfreude with journalistic boo-boos.

Tuesday, August 11th, 2009

yws-search-general : Message: Term Extraction and Contextual Web Search services to be discontinued

Crap. The very powerful term extractor API from Yahoo is being closed down. Sad developer is sad.

Saturday, August 8th, 2009


As is now traditional, there will be a BarCamp in Brighton straight after dConstruct. This year it’s happening at a new venue, the Old Music Library in the middle of town—right across from the Brighton Dome, venue for dConstruct. The first batch of tickets went on sale yesterday but there’ll be more to come (if you don’t fancy playing web booking roulette, a sure-fire way of getting a ticket is to contribute to sponsoring the event).

If you’re coming to Brighton for dConstruct, I highly recommend staying for the weekend and sleeping over at BarCamp.

If you’re not coming to Brighton for dConstruct, why not? Haven’t you seen the line-up? It’s going to be fantastic.

Here’s one way to get a ticket; add something to the dConstruct time capsule:

Take a look around you. What do you see that you would like to preserve for the future? Take a picture of it, upload that picture to Flickr and tag it with dconstructcapsule.

The ticket you could win is no ordinary ticket. It’s a VIP ticket that will get you into dConstruct itself, two nights in a luxury hotel in the centre of Brighton, and a place at the speakers’ dinner the evening before the conference.

Even without the competition aspect, I think this is a pretty nifty project. People have already posted some great items:

Minidisk Player
This used to be cool. I think it still is.

Red Ring of Death
The infamous red ring of death. A symbol of recreation in the naughties and a beacon of utter despair.

Howarth S2 oboe
…though my oboe is a product of centuries of instrument making techniques and technology rather than something new, it’s certainly something (along with the skills that made it) that I believe needs preserving for the future as an example of beautiful design and craft.

time capsule banana
Clever future-people! Please clone this fruit—it’s a design classic (iconic styling, great usability), it’s nutritious, and it’s tastier than the bland efficiency-gruel you slurp down the rest of the space-week.

Now it’s your turn. What would you add to the dConstruct time capsule.


These kids hate what is being done to them ...and one day they will get their revenge.

Friday, August 7th, 2009

The Font-as-Service | i love typography, the typography and fonts blog

Elliot gives a rundown of the font delivery services for the web that are on the way.

Ex Nihilo

Dave has been experimenting with processing and documenting the results here.

Thursday, August 6th, 2009

Chroma-Hash Demo

Another interesting take on assigning a visual clue to password fields.

Wednesday, August 5th, 2009

Building Rome in a Day

Unbelievable 3D visualisation created by extracting common points from millions of pictures on Flickr of Rome, Venice and Dubrovnik. As Matt Haughey would say, "Holy shitballs!"

Plug in and huffduff

Beer o’clock in Brighton begins shortly after work ends on a Friday evening. That’s when the geeks of Brighton unshackle themselves from their keyboards and monitors to congregate in a pub. If the weather is good, it’ll be a sunny pub. Last friday the Clearlefties descended on The Eagle where we were joined by Ribotians and others.

Glenn showed up and we proceeded to geek out on our usual favourite topics; microformats and data portability. He had spent the day hacking on a Firefox plug-in. If you haven’t tried his Identify extension, do yourself a favour and install it—it’s quite astounding.

I mentioned that I had tried to hack together my own Firefox extension for Huffduffer but was thwarted by my lack of skill in reverse-engineering and penetrating the documentation. I wanted to provide a fairly simple behaviour: right-click on a link to an audio file and select an option to huffduff it.

Two days later I got an email from Glenn with a file attached …a Firefox extension he built for huffduffing. Fantastic!

I hacked around with the JavaScript a little bit (adding a check to make sure the hyperlink being right-clicked was pointing to an audio file) and added Huffduffer icons from Paul’s icon set. Meanwhile Glenn added a little touch of genius; using Firefox’s built-in microformats parser to check for values on the page and pre-fill the Huffduffer form with them.

Anyway, grab the Huffduffer Firefox plug-in for yourself and give it a whirl.

Next time it’s beer o’clock in Brighton, I owe Glenn a beer.

Tuesday, August 4th, 2009

Will my site be archived? Yahoo! GeoCities Help is indexing Geocities sites (as it always has). Yahoo are going to fuck all about their users data/dreams/memories and Yahoo are going to do fuck all about the URLs.

HTML5 Canvas and Audio Experiment

A very pretty little Twitter canvas experiment accompanied by music delivered via the audio element. View this in a capable browser.

Monday, August 3rd, 2009

Huffduffer :: Add-ons for Firefox

Thanks to the brilliant Glenn Jones, there is now a Firefox plug-in for Huffduffer. Right-click on a link to an audio file and select "Huffduff it" and you will get the pre-filled Huffduffer form in a pop-up window.


Lovely representation of OpenStreetMap data using canvas.

Contact Us « Kellan Studios

Nice Huffduffer-style contact form.

Sunday, August 2nd, 2009

The HTML5 Equilibrium

is a strange character with what appears to be a split personality. Hardly surprising then that something so divided would appear to be so divisive.

First of all, there’s the spec itself.

The specification

HTML5 walks a fine line between maintaining backward compatibility with existing markup and forging the way as a modern, updated specification for the future. If it strays too far in paving the cowpaths and simply codifies what authors already publish, then the spec would mandate using tables for layout and font elements for presentation because that’s still what most of the web does. On the other hand, if it drifts too far in the other direction, the result will be something as theoretically pure but as practically useless as .

The result is that HTML5 appears to be a self-contradictory mess. But it’s hard to imagine a successful web technology that isn’t a mess. That’s because the web itself is a mess. Clay Shirky described exactly how messy it is back in 1996:

The server would use neither a persistent connection nor a store-and-forward model, thus giving it all the worst features of both telnet and e-mail.

The hypertext model would ignore all serious theoretical work on hypertext to date. In particular, all hypertext links would be one-directional, thus making it impossible to move or delete a piece of data without ensuring that some unknown number of pointers around the world would silently fail.

And yet the web succeeded because:

…of the various implementations of a worldwide hypertext protocol, we have the worst one possible.

Except, of course, for all the others.

…a reference to Churchill’s oft-cited maxim that:

…democracy is the worst form of government except all the others that have been tried.

Which brings us nicely to the subject of governance and process, another area where HTML5 appears to be split.

The process

Democracy—or at least, consensus—drives the process of most W3C specs. But HTML5 isn’t just being developed at the W3C. HTML5 is also being developed by the WHATWG. Sounds crazy, doesn’t it? The reasons for the split are historical—the W3C rejected HTML as the future of the web in 2004 so the WHATWG started their own work and then the WC3 had a change of heart in 2007. Hence the parallel development. It turns out to be a pretty good system of . The editors on the WHATWG side—Ian Hickson and —are balanced by the chairs on the W3C side—Chris Wilson and Sam Ruby.

The WHATWG process isn’t democratic. There’s no voting on issues. Instead, Hixie acts as a self-described benevolent dictator who decides what goes into and what comes out of the spec. That sounds, frankly, shocking. The idea of one person having so much power should make any right-thinking person recoil. But here’s the real kick in the teeth: it works.

In theory, a democratic process should be the best way to develop an open standard. In practice, it results in a tarpit (see XHTML2, CSS3, and pretty much any other spec in development at the W3C—not that the membership policy of the W3C is any great example of democracy in action).

In theory, an unelected autocrat having control of a specification is abhorrent. In practice, it works really, really well …if it’s the right person.

That’s always been the case with benevolent dictatorships. The populace transfers moral responsibility to the of the state, personified by an-powerful ruler like Shakespeare’s Henry V:

If his cause be wrong, our obedience to the King wipes the crime of it out of us.

That’s a lot of responsibility for one person to carry. Remarkably, Hixie carries the weight with exceptional disinterest and a machine-like even-handedness:

Let it be said that Ian Hickson is the Solomon of web standards; his summary of the situation is mind-bogglingly even-handed and fair-minded.

But it doesn’t always seem that way to those on the outside looking in at the HTML5 process. Debates around the summary attribute or RDFa might well give the impression that Hixie is ignoring voices in opposition. Nothing could be further from the truth. The real challenge is in finding good solutions to problems, and sometimes that doesn’t necessarily mean using an existing solution—despite the pave the cowpaths mantra.

If you have a potential solution to a problem in HTML5, the way to present it is with data. If you don’t have the data, then maybe it isn’t such a good solution. I’ve experienced this myself with the rev attribute, which has been removed from HTML5. I think it should remain. I think it’s a potentially powerful attribute. But I can’t argue with the data. My personal preference isn’t a good enough reason to keep it (‘though I may occasionally tip out some beer to honour its memory).

The irony is that HTML5 has the reputation of being a spec beyond the influence of the average web developer when in fact it has the most open process of any web standard. If you want to have a say in the development in CSS3… well, good luck with that. If you want to have a say in the development of HTML5, you can.

Unlike just about every other W3C activity, the HTML working group is open to the public. You can join in as a public invited expert—except you don’t actually get invited. Instead you’ll need to complete this three-step process:

  1. Sign up for an account with the W3C.
  2. Fill in the invited expert application—you’ll need your W3C credentials to do this.
  3. Fill in the form for joining the HTML working group.

But a lot of the activity on the W3C side of things is very much about the process of developing a spec; voting, consensus and meetings. To have your say in putting the content of the HTML5 spec together, join in the WHATWG activities.

Two words of warning…

Firstly, time is of the essence. HTML5 is due to enter Last Call Working Draft in October of this year. From then it’s going to be a race towards Candidate Recommendation in 2012. If you want to influence this spec, now is the time to get involved. Don’t wait. The FUD around the boogieman date of 2022 is proving to be a particularly virulent meme that web developers have latched on to as an excuse for not caring about HTML5.

Secondly, you might be surprised by the contents of the specification. This is yet another area where HTML5 displays a split personality.

The feature set

Traditionally, HTML has been a format for semantically marking up hypertext—the clue is in the name. That’s still true but HTML5 is also a format for creating web applications; the WHATWG work that became HTML5 started life as a spec for web apps. This means that a lot of the discussions on the mailing list are about APIs, DOM trees, and some fairly code-heavy stuff around canvas and video. Discussions of the semantics of new structural elements like header, footer and article aren’t nearly as prevalent—all the more reason for working web developers to get involved in the process.

The truth is that much of the HTML5 spec isn’t aimed at web developers at all; it’s aimed at browser makers. This has fostered some conspiracy theories about how browser makers are controlling the spec but the truth is that browser makers have always had the final say in what gets implemented. It doesn’t matter how perfect a web standard is if nobody can use it. Hixie, for all his apparent power, acknowledges this:

I don’t want to be writing fiction, I want to be writing a spec that documents the actual behaviour of browsers.

Fortunately we don’t have to wade through a spec aimed at browser makers. Michael Smith has taken all the author-specific parts of HTML5 and published them in a parallel document: HTML5: The Markup Language.

Sam Ruby tells of a useful distinction drawn up by TV Ramen of the kind of new features we’re seeing in HTML5:

extending the platform vs. extending the language.

The first type of feature is something that requires significant effort from browser makers; canvas, video, and all the new APIs. The second type of feature is something that requires very little effort from browser makers but is enormously significant for authors; header, footer, article, etc.

The diagnosis

HTML5 is the web equivalent of a circus tightrope act, performing equal feats of balancing and juggling

  • backward compatibility with shiny new features,
  • W3C consensus with WHATWG benevolent dictatorship,
  • and new browser features with new semantics.

It’s hardly surprising that such a schizophrenic spec can seem so confusing. If you spend some time immersing yourself in the world of HTML5, most of this confusion will evaporate. If symptoms persist, I recommend consulting the HTML5 doctor.

Saturday, August 1st, 2009

Let's make the web faster - Google Code

A whole heap of optimisation techniques from Google for faster CSS, JavaScript, markup and PHP.