My buddies and I express our support for HTML5 ...with caveats ...and unicorns.
Monday, August 31st, 2009
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 HTML5 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.
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 .
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
…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.
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
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.
articleelement, unlike the
sectionelement can take an optional
pubdateattribute to encode the publication date. I’m all in favour of having this information be machine-readable but the
pubdateattribute 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
pubdateattribute on a
timeelement within an
footershould do the trick.
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
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! 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
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:
The way that the element named
footer is defined in HTML5—to be used multiple times in a single document in
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
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:
- The content model of
footeris updated to match that of
header, which is much more liberal in what it accepts, or:
- The name of the element currently called
footershould 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:
- that’s beyond my area of expertise,
- smarter people than me are working on it, and
- I think that
canvaswould 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.
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.
There is something utterly hypnotic and disturbing about these three-frame looping animations.
A forthcoming typeface designed specifically to help people with dyslexia read and write more effectively.
Saturday, August 29th, 2009
Collective nouns, collected.
Asteroids implemented using HTML5's canvas.
Simon St. Laurent explains why mobile support for HTML5 mitigates Microsoft's dominance of desktop web browsing.
Friday, August 28th, 2009
Some very handy Textmate tips from Emil ....especially the bit about doing calculations for vertical rhythm.
Thursday, August 27th, 2009
A tool from Google to help you see how your microformated content is showing up.
A great article about the rising prevalence of "rough consensus and running code" in the real world.
Wednesday, August 26th, 2009
The iPhone App of Magnetic North's wonderful serendipitous Flickr photo viewer is now available for free. It's lovely.
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 (firstname.lastname@example.org 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 expounding on the beauty – and the difficulty – of designing numbers.
Wendy gives some commentary from her ringside seat at the theatre of HTML5.
Tuesday, August 25th, 2009
James Surowiecki explains how loss aversion is affecting the health care "debate" in the USA.
A microformats article by yours truly, reworking a blog post from a while back about the value class pattern.
Two little tips courtesy of Dan.
A very handy tool to help you check the outline algorithm in HTML5.
Monday, August 24th, 2009
Like Wikipedia for typefaces. Beautiful work from Jason, Dan, and others.
Sunday, August 23rd, 2009
A blog devoted to data visualisation.
"A tribute to two former bookkeepers who impacted American design & typography for all time."
Friday, August 21st, 2009
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
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
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.
Gorgeous visual design for an interestingly eclectic site.
Monday, August 17th, 2009
Fiendishly clever and joyful platform game ...and it only has only level.
Re-finding five numbers
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 https://huffduffer.com/adactio/tags/five+numbers/rss.
Or you can listen to each episode at these permanent URLs:
Another Five Numbers
A Further Five Numbers
Saturday, August 15th, 2009
A cute and poignant resignation letter ...in video game form.
Thursday, August 13th, 2009
Turning Japanese, I think I'm turning Japanese, I really think so.
Wednesday, August 12th, 2009
Enjoyable schadenfreude with journalistic boo-boos.
Tuesday, August 11th, 2009
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:
…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.
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
Elliot gives a rundown of the font delivery services for the web that are on the way.
Dave has been experimenting with processing and documenting the results here.
Thursday, August 6th, 2009
Another interesting take on assigning a visual clue to password fields.
Wednesday, August 5th, 2009
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!
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
Archive.org 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.
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
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.
Nice Huffduffer-style contact form.
Sunday, August 2nd, 2009
The HTML5 Equilibrium
HTML5 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.
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 XHTML2.
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.
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 checks and balances. The editors on the WHATWG side—Ian Hickson and Dave Hyatt—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.
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:
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:
- Sign up for an account with the W3C.
- Fill in the invited expert application—you’ll need your W3C credentials to do this.
- 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.
- Anyone can join the WHATWG mailing list.
- Anyone can join in the discussions on IRC.
- Anyone can edit the wiki.
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
video. Discussions of the semantics of new structural elements like
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.
extending the platform vs. extending the language.
The first type of feature is something that requires significant effort from browser makers;
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;
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
Utterly addictive platform game.