Line-by-line: HTML5, open standards, and the BBC
Let’s do this properly, shall we? This is an inline (as popularised by That E-mail) response to Erik Huggers’ piece on the BBC Internet blog.
Recent commentary on this blog has suggested that our use of Flash on BBC iPlayer and across BBC Online in general, betrays our commitment to open standards. Is this a reasonable assumption? I do not think so.
Okay, starting at the beginning. Erik links to a comment of mine there which reads:
In answering the “why Flash?” question, you state that it’s available on 95% of PCs. great. but also irrelevant.
The question wasn’t so much “why Flash?” in general (its reach on PCs hasn’t been under much doubt since the late 1990s), but “Why Flash for Android, when everybody knows you already have the infrastructure to churn out HTML5-based video on the UI side and MP4-based media files as the actual content - you do this right now for iPhone, iPod touch and iPad, albeit in MOV containers — the adjustments to make these work (by using compliant MP4 containers instead) are technically really trivial. I know this, half the commenters here know this, and a many of the technical staff involved in iPlayer know this.
A “platform-neutral basis” would strongly suggest a platform-neutral content format, and delivering H.264+AAC encapsulated in MP4 containers to both Android phones (including those which won’t ever get Android 2.2) and Apple Devices (and quite possibly others besides) achieves this on a simple and cost-effective basis. While I have nothing against the developers who went to the trouble of tweaking the iPlayer to work on this version of Flash, you can’t surely think that this was the most effective means of satisfying the conditions service licence, can you?
Now, having written that comment, I am slightly biased, but I can’t for the life of me see a “hey! stop using Flash!” in there. I will grant you, other people have suggested the BBC do that, but being a pragmatic sort, I don’t think that’s appropriate. The BBC should use Flash. For many desktop users this is the only sensible way to get video (and, to a lesser extent, audio) playing. What the BBC shouldn’t do is only use Flash.
This is actually the case, and indeed in the comment above I wanted to know why the BBC didn’t just serve up the same media to Android devices (which can, with a minor tweak, play it back) as it does to iOS devices, rather than limiting itself to that subset of Android devices in the UK which have Froyo and the Flash 10.1 player, noting that many devices will never get Froyo and Flash 10.1 (but can play back the media natively provided it’s in MP4 containers), and at the time of posting that, the number of people in the UK who actually had Froyo was fewer than the number of people who work for BBC FM&T.
The answer eventually came by way of a Freedom of Information response which says:
We confirm that the BBC does not currently provide streams to Android devices as standard MP4 containers by HTTP streams due to content protection considerations.
And so, the accusation (from me, at any rate) is not that the BBC is betraying its commitment to open standards per se, but that the BBC won’t be upfront and honest — except when pressed by way of a rather powerful legal instrument (and even then, I think they actually bent the rules a little in order to get that answer) — about why it is eschewing open standards in favour of a proprietary solution in the face of a it being an “easy win” in technical terms.
Erik continues:
Open standards have always been part of the BBC’s DNA. They are fundamental to driving market innovation and will always be important to the BBC’s mission to introduce the benefits of new technology to society. Open standards have the ability to transform our lives for the better.
Absolutely no arguments from me here.
Our use of Flash is not a case of BBC favouritism, rather it currently happens to be the most efficient way to deliver a high quality experience to the broadest possible audience. Let’s also not forget that we already support a very wide range of other formats and codecs to deliver BBC iPlayer and other services to variety of devices.
And we’re back in the room. “…happens to be the most efficient way to deliver…” — does that seem like strange wording to you? “efficient”? As Erik states in that very paragraph, the BBC does support a wide range of formats and codecs: H.264 and AAC wrapped up as FLV and delivered over RTMP is just one of them. In the context of the debate that was raging — chiefly devices capable of playing back the same content wrapped up as MP4 and delivered over HTTP, which the BBC comes within a gnat’s hair of doing already — efficiency is a matter of leveraging that for the benefit of those devices (which also includes several popular desktop browsers, of course). But, this isn’t a matter of efficiency, but a matter of obligations.
The BBC has obligations of some unspecified kind to its partners to offer some degree of content protection on the media it provides through iPlayer and friends, and for whatever reason, apparently, serving MP4 over HTTP to Android devices doesn’t meet the requirements. More on this later, though.
The fact is that there’s still a lot of work to be done on HTML5 before we can integrate it fully into our products. As things stand I have concerns about HTML5’s ability to deliver on the vision of a single open browser standard which goes beyond the whole debate around video playback.
It’s hard to make a call on this, but as I explained recently, there’s plenty that developers can and should (quite safely) do with HTML5 right now. So, let’s get into those concerns — I’ll snip the history lesson part of Erik’s post.
Not too long ago some browser vendors were showcasing proprietary HTML5 implementations; which in my view threaten to undermine the fundamental promise.
Now, this isn’t really true at all.
A straightforward reading of this statement doesn’t actually make any sense: Opera is a proprietary HTML5 implementation. The forthcoming Internet Explorer 9 will be. The whole point of open standards is that implementations can be proprietary, but they can also be open source. A good standard supports both without issue, and all versions of HTML have achieved this without incident.
What I believe Erik is referring to is Apple’s HTML5 showcase whose biggest failing was being poorly-named. It did what many sites have in the past (and some continue to do), which is to target one specific browser, specifically Safari. This is the anthesis of what HTML5 is all about, and risked undermining both a lot of goodwill that Apple had gained as a result of its work on WebKit, and perception of HTML5 as a whole (as illustrated by Erik’s post).
To add insult to injury, Apple’s showcase wasn’t a whole lot of HTML5 in the first place. It was mostly to-be-standardised CSS3.
But, as much as the web — like much of the rest of the Internet — is built on be conservative in what you do, be liberal in what you accept, this cuts both ways, and gives moronic developers enough rope to hang themselves with poor decisions revolving around artificial ties to particular browsers. (If I were to be less than charitable, I’d note the irony in that this is little different conceptually from tying oneself to a particular proprietary plug-in). Using this as a criticism of HTML5, or indeed of the browsers, is disingenuous at worst and foolish at best.
Recent activity in the HTML5 Working Group and the apparent split between W3C and WhatWG suggests HTML5 might not be on the path we expect, or deliver what I believe our industry requires.
I honestly don’t know how much attention Erik Huggers pays to the finer points of the HTML5 WG and WHATWG processes. The example linked above made the news as part of the ongoing Apple-and-HTML5 versus Adobe-and-Flash battle, which has thankfully settled down, and had little bearing (barring a few frayed tempers) on the process itself. In terms of the “split” between the W3C and WHATWG, it’s worth looking at WHATWG’s Specifications page:
This draft is a superset of the HTML5 work that is being published at the W3C: everything that is in HTML5 is also in the WHATWG HTML spec. Some new experimental features are being added to the WHATWG HTML draft, to continue developing extensions to the language while the W3C work through their milestones for HTML5. In other words, the WHATWG HTML specification is the next generation of the language, while HTML5 is a more limited subset with a narrower scope.
Indeed, the actual split was what brought about WHATWG and HTML5 in the first place, and the fact that there’s a HTML5 WG at W3C at all is an indicator of just how much positions have been reconciled over the course of the specification’s development.
Erik continues:
Despite grand overtures from Microsoft toward HTML5 support, their new browser is yet to ship and so the jury is out.
I’m not usually hugely charitable to Microsoft, but in this instance they deserve defending: the Internet Explorer team has been very transparent about their plans for IE9. Yes, it’s not out yet, but playing catch-up after all these years isn’t easy. And, as explained earlier, there are many things which work just fine in IE8. And, for that matter, IE7 and IE6. First and foremost bbc.co.uk is a website, and first and foremost HTML5 is about better ways to build websites: the “web applications” features aren’t especially applicable to a large proportion of the site. Just because something’s in a specification doesn’t mean it has to be used!
The tension between individual motivation and collective consensus has brought an end to many noble causes in the past, and here, the pace of progress appears to be slowing on bringing HTML5 to a ratified state.
As a fan of standards, Erik should be well aware that rate-of-change decreasing as a specification nears completion is fairly normal.
History suggests that multiple competing proprietary standards lead to a winner-takes-all scenario, with one proprietary standard at the top of the stack, which is not where most of us want to be…
Again, this is true, but not especially relevant. There’s no evidence presented here that this picture comes close to representing the reality of HTML5’s development.
So my request to the W3C, HTML5 Working Group, and major browser vendors, is to continue fervently on the path you began. Understand you are representing the future of the web, as well as businesses like ours with your efforts. HTML5 is more important than any one motivation. Speed is of the essence. Professional integrity is of the essence. We are counting on you to bring one HTML5 to the web and the W3C to help make this happen.
I approve. Fortunately, Erik’s wishes seem to have come true: browser vendors are showing no signs of slowing down in implementing HTML5 features, and developers are showing no signs of slowing down in using them. I call that a win.
Returning to the topic of video, the bottom line is that I — and people who have been both equally vocal and thoughtful on this issue — love what the BBC does. We think the BBC should be on as many devices as possible, and its Royal Charter agrees. Where we diverge is that when the BBC decides a platform is not feasible to support, and it’s a matter of delivery over the Internet, the rest of us are powerless (and indeed, actively prevented) from fixing that problem.
But even before we can tackle that, the BBC has to actually speak up about why it’s not feasible. We’re technical people. Give us a set of constraints and we’ll do our best to figure out a solution that satisfies everybody’s interests.
So, I have some questions for Erik:
- What does the BBC want to get out of HTML5 which isn’t already part of the specification? Has it attempted to contribute to the process and been frustrated in some way?
- Will the BBC be upfront in blog posts like this about why it eschews HTML5 video (on devices where it is the preferred — or even the only — option) in favour of Flash-based delivery, rather than making irrelevant claims about Flash penetration in a desktop browser setting? If you won’t tell us why you won’t use HTML5 video for a particular device, we can’t help you fix that.
- Will the BBC ever tell those of us who want to help it get its programmes on as many people’s devices as possible what restrictions it’s bound by? Personally, I don’t actually care who is imposing the restrictions, just what they are? Is it a case of “you must use Flash”, or is it more ephemeral, along the lines of “steps must be taken to ensure that unauthorised copying and retention are prevented” — and if the latter, who evaluates what is and isn’t sufficient? What can we do to help?
- And, on that subject, does Erik envisage a scenario in the future where HTML5 video is the most efficient way to deliver content to everyone? If not, what are the show-stoppers? As these are open standards, and the BBC is an important consumer of those standards for the benefit of the licence-fee-paying public, its voice carries a certain amount of weight.
