Erik Huggers and HTML5
This week, following on from his piece on BBC Online’s restructuring, Erik Huggers published another post on open standards in general HTML5 in particular.
As with his BBC Online post, this induced a certain amount of head-scratching. Reading Erik’s posts and subsequently spending several minutes attempting to determine what exactly it is that he’s driving at appears to be a theme of late.
While I posted some comments on the piece, I thought it worth performing my now-customary dance of interpretation whereupon I attempt to answer the above ponderance.
So, let us start with the contentious part: <video>. This was bound to come up. Indeed, the first link in Erik’s post (and I don’t know if it’s one he decided upon, or whether it was added in by somebody from the BBC Internet Blog team) was to one of my comments on the iPlayer on Android debacle.
It’s helpful at this point to give you some background. The BBC uses Flash — or more accurately, the RTMP protocol with SWF Verification enabled — precisely because it’s not officially open. Part of the SWF Verification handshake is the magic phrase “Genuine Adobe Flash Player 001”. This is identical in purpose to sites which alter their behaviour depending upon the User Agent (that is, the browser you’re using): it’s a trivial silly measure which offers no real protection against anything, not least irritated users who find they’re being artificially prevented from accessing something you’re ostensibly providing to them. In the BBC’s case, the content delivery servers that they use will refuse to stream iPlayer video to clients which don’t at least claim to be “Genuine Adobe Flash Player 001” — that is, by design, only Adobe’s implementation of Flash.
This is relevant because it’s often claimed that Flash is an open standard. This is true, and there are third-party implementations — in varying states of incompleteness — of the Flash specifications. It’s unlikely that they’ll ever reach complete parity, though, for two reasons: first, Flash isn’t something which was designed with openness in mind from the outset, and has all of the hallmarks of “develop first, open later” (in other words, there are lots of inconsistencies and kludges); second, not all of what we think of as “Flash” is actually open. SWF Verification isn’t, and neither is the encrypted version of the RTMP protocol — RTMPE — as used by 4oD, YouTube “premium” videos, and Hulu. Both have been reverse-engineered, but neither forms part of the specifications released by Adobe, and Adobe has in the past used legal threats to have implementations of both banished to the far corners of the Internet.
So that we’re all clear, I’ll summarise: Flash itself is an open standard, at least on paper. The BBC quite deliberately (in common with many broadcasters) uses it because parts of it that they use aren’t open, and would like it to stay that way.
In this context, when the inevitable debate about codecs for <video> arises, it’s important to bear in mind that the answer doesn’t matter, because an open standard which could be implemented in the WebKit and Gecko open source browser engines (be it requiring patent grants or otherwise) isn’t something the BBC (and most other broadcasters), driven by their licensors, want in the first place.
You see, those licensors — the people who hold rights on the programmes themselves — have a fear, and it’s one which echoes around meeting rooms at the broadcasters. It goes something like this:
- There’s talk of a feature to make embedding videos in web pages as easy as embedding images
- But wait, images get stolen all of the time when they’re embedded in web pages! You can just right-click and “Save image as…”
This is a very real concern. Never mind that no browser actually provides this option for videos. Never mind that to perform the equivalent action for videos, you need to view the page source, understand enough HTML in order to be able to locate the source URL, copy it, paste it into a curl command line and… oh, wait, I’ve lost you, haven’t I?
You see, for all of this trouble, the people who want to get a copy of the video that badly will just turn to BitTorrent. Or Usenet. Or IRC. Or — for a legal alternative — their own PVR (if they’d had a little foresight).
But this matters not, apparently. The concern, irrespective of merit, is real. And the BBC walks along a perpetual tightrope. On the one side are the things it must and must not do, according to its Charter and dictats from the Trust. On the other are the people telling it what it should do. Thus, at every turn, it attempts to comply with both as much as possible. The BBC isn’t prohibited from only providing streaming programmes by way of systems which offer the appearance of protection (again, irrespective of merit), and its licensors want it to: so it does.
So, let’s put <video> to one side.
This leaves all of the other things in HTML5. There are four basic groups of new things to HTML5 over XHTML 1 and HTML 4:
- Simplifications and clarifications of existing features and constraints without introducing new functionality
- New things which don’t require any special handling by user agents
- New features which do require special handling, but can be easily feature-detected or are designed to degrade gracefully.
For the avoidance of doubt, the first two can be employed — safely — today, irrespective of your target audience’s browsers’ level of HTML5 support.
The first relates to things like the simplified <!DOCTYPE> which has been carefully crafted to trigger standards-mode behaviour in every browser which matters, or <meta charset="..."> which takes advantage of the fact that browsers had traditionally been sneaky in their parsing and formalises the behaviour. The whole purpose of this group of things is that they don’t change how the browsers behave, but make life easier for authors. Win-win, as they say.
The second is even easier to get your head around: HTML5 introduces new elements which carry with them particular semantics, but allowing a browser to fall back to the default “unknown element” mechanisms does exactly the right thing. For example: <section>. This is because any special presentation or other handling of these elements is entirely optional in the first place. And so, with a light sprinkling of CSS to ensure that the things you’re expecting to be block-level elements really are displayed as such in older browsers, you can safely use these too. Your users won’t care yet, but it saves you a job later, and means your mark-up makes more sense, which your successor (or you, in a year’s time) will thank you for. Again, win-win.
So far, we’ve covered a significant chunk of HTML5 and there’s an awful lot of it which can be safely deployed to production right now.
The third group is trickier: these are things which will degrade gracefully, or — in the case of scripting APIs — can be feature-detected quite easily. With these, you have to make a call as to whether the degraded variant is good enough for those users running browsers not supporting the new functionality, or whether you can rely on JavaScript being able to simulate the missing features and provide a good enough experience for a high enough proportion of the user-base.
As it turns out, many of the new things in this group are features which people tended to craft in JavaScript anyway. Date pickers. Progress bars. That sort of thing. And so, with a few tweaks to your existing code, you can make it so that it works in concert with graceful degradation to provide your implementation where a native one isn’t available.
This isn’t quite as straightforward as the first two groups of features, as it requires a little effort and planning, and features need to be evaluated on a case-by-case basis, but broadly, it’s fine.
And, really, that’s it. In other words: there is no good reason to be arguing against HTML5 today, save for the effort required to actually write it.
And this brings us full circle, to Erik’s post, and the continual ponderance. Having gone through aspects of HTML5, discounting <video>, the question persists: what the hell is he on about?
The conclusion that I’ve reached — and it’s the most charitable of the available conclusions — is that this is a predominantly a PR piece, albeit one which includes more-or-less the right terms in the right places to make sure that it appears to be serious commentary. It’s fire-fighting. I have a hunch that the first link in the post leading to where it does is telling (and I do mean the issue in general, not my comment in particular, for the avoidance of doubt: I don’t think the Director of FM&T is writing posts for the BBC Internet blog simply for my benefit!).
I could be wrong, of course. Who knows? Either way, you’ve had a free HTML5 primer out of me. Go crazy.
