I had a great time at this year’s SXSW Conference. Tried to make it out to as many panels as possible. I missed a few due to the distance between campuses and confusion over shuttle buses — see #2 and #7 on Jim’s post. That said, I did make it a point to check out “The Politics Behind HTML5″ panel. Moderated by Charles McCathieNevile (Chief Standards Officer @ Opera), the panel also included:
– John Foliot (Manager Stanford Online Accessibility Program @ Stanford University)
– Paul Cotton (Partner Group Manager @ Microsoft Canada)
All three were World Wide Web Consortium (W3C) representatives.
I wasn’t really interested in learning more about HTML5′s awesomeness, I really wanted to learn why certain things make it into the spec and why some things don’t — and this panel did not disappoint. People attending the panel may not have liked some of the answers presented, but answers we did get.
So, why does the World Wide Web Consortium (W3C) care about HTML all of sudden?
Paul Cotton (Microsoft) was very blunt about this and stated that the W3C made a mistake by focusing solely on XML/XHTML. The W3C managed the HTML spec until HTML4, when it decided to cease support and, instead, started building off of the XHTML spec, which was ultimately abandoned in 2009. While all of this was happening, Opera and Mozilla (and later Apple) got together and started a new group called the Web Hypertext Application Technology Working Group (WHATWG) that was focused on enhancing the then abandoned HTML spec. So, now there are actually two organizations involved in developing HTML5: the W3C and the WHATWG. The W3C sees their involvement with HTML5 as an attempt to “bring the prodigal son back into the family.”
How do things get included in the HTML5 spec?
I have a feeling that people assume that specs are written by a closed group of individuals who are somehow detached from the real world. Further, they are written to scratch some obscure itch and, therefore, don’t reflect anything that anyone actually cares about. Or is that just me? To that end, John Foliot (Stanford) kept making the point that if you want to know what will end up in the HTML5 spec, read the front page of the Wall Street Journal.
If TV networks want their content online, that means leveraging the latest and greatest browser technologies, which means that HTML5 will probably end up supporting that. Why? Because NBC/ABC/CBS/CNN/etc have very deep pockets — obviously. You go where the money is. Foliot made the point that when things like this happen, then very basic user-centric principles, like accessibility, are thrown out the door. To Foliot’s point, things like accessibility can’t be an after-thought or a “feature” — it has to be part of the spec. Otherwise it may never be included, because it’ll be easier to just keep pushing it down the “we’ll get to that later” list. Jeremy Keith (pic below), author of “HTML5 for Web Designers,” also chimed in from the audience and brought up that basic design principles (ie, “put the user first”, etc) may also fall prey to bottom-line thinking.
How do you balance the need to get a workable spec out the door in a timely fashion while ensuring that things like accessibility support are included? Tough question. I don’t know. Those W3C guys get paid a ton of money to figure stuff like that out (maybe not).
Source: Jeffrey Zeldman
On the topic of TV networks making their content available online (and this goes for movies and music, as well) via HTML5-capable browsers, a question came up regarding Digital Rights Management (DRM). Where/how/when does this get integrated into HTML5? Does it happen within HTML5 via extension points or will there be a single DRM format? As Cotton said, the use of extension points is a double-edged sword. On the one hand, it absolves the W3C from having to develop DRM support within the spec, which, from an organizational perspective might be a good thing, since it’s one less thing for them to worry about. But if they let 3rd party developers come up with their own formats, we lose the ability to standardize DRM and browsers will then need to support multiple codecs.
There were no clear answers to these questions and scenarios, but we did get an idea of some of the questions that the W3C has to struggle with when deciding what gets included in the spec. Overall, great panel.