Episode 97 of The SitePoint Podcast is now available! This week Kevin Yank (@sentience) chats with Louis Simoneau (@rssaddict), SitePoint’s head Technical Editor, about why he thinks Google’s move to drop H.264 is a good thing, whether the W3C’s new logo for HTML5 is any good at all, and why the WHAT-WG has decided to drop the ‘5’ from HTML5.
Listen in your Browser
Play this episode directly in your browser! Just click the orange “play” button below:
Download this Episode
You can also download this episode as a standalone MP3 file. Here’s the link:
- SitePoint Podcast #97: The Occasional Dick Move with Louis Simoneau (MP3, 54:46, 50.2MB)
Interview Transcript
Kevin: January 28th, 2011. SitePoint’s head Technical Editor talks WebM, HTML5 and the future of web standards. I’m Kevin Yank and this is the SitePoint Podcast #97: The Occasional Dick Move with Louis Simoneau.
And joining us on the SitePoint Podcast today I have the distinct pleasure of having my interviewee in the same room with me. We’re joined by Louis Simoneau. Hi Louis.
Louis: Hello.
Kevin: Louis is the Lead Technical Editor here at SitePoint. What does that mean, what do you do here?
Louis: So, all of our books and online publications go through sort of a two-stage editing process, first up there’s a technical edit in which I kind of take the manuscripts from the author and make sure the code works, is up to snuff, is the best practice, make sure all the explanations of the code are clear and comprehensible to a beginner in that field, and then it would go through to a language editor who does the grammar and spelling and punctuation and style. So, yeah, I take care of all of the technical aspects of all of our books and online publications.
Kevin: Head of technical pedantry I guess you’d say (laughter). Yeah, I used to do a lot of that stuff back when SitePoint was a smaller operation and, yeah, you’re kind of the last line of defense for technical quality on everything we publish here.
Louis: That’s a fair assessment, yeah.
Kevin: Okay. Well, the reason I wanted to get you on is because when you’re not editing books you’re also occasionally writing for the SitePoint Blogs, and one of the topics we covered in last week’s podcast was Google’s decision to remove H.264 video from Google Chrome. And I know you’re a bit of a Google fan.
Louis: Yes indeed. I wouldn’t say I’m a Google fan, I don’t think that’s an accurate representation; in this case I’m actually— My opinions on this are sort of formed of Mozilla fan, I think.
Kevin: A Mozilla fan.
Louis: I think this sort of plays to Mozilla’s advantage, I’m a fan of Firefox, been using it forever, I haven’t jumped on the Chrome bandwagon.
Kevin: Okay, so you’re not on the Chrome. You are on the Android though I notice.
Louis: I am on the Android phone, yeah.
Kevin: Yes. We don’t actually have anyone using an Android phone on our regular panel, so this is one of the reasons I wanted to get you on, and the other is this post that you wrote; I think the day the news broke there must’ve been dozens if not hundreds of posts across the Web sort of crying foul and saying “Google’s gone off the deep end, they’re crazy, they’re removing support for the most popular video format from their browser, what’s going on?” And yours was one of the few positive ones I saw come out of a I guess I would say a browser vendor neutral publication, so you know we saw the predictable posts from Opera and Firefox developers supporting the move, and Chrome developers as well, but as an independent outlet your post sort of took the stance that this was a good move. So let’s start there, why were you happy to see this happen?
Louis: So, I’ve been sort of covering this issue for a little while on the SitePoint Blog, so there’s been a couple of posts in the past, once just sort of introducing the idea of the different codecs way back when it wasn’t that contentious an issue, and then I wrote another one when Google announced an open sourced WebM so including the VP8 codec. So, my view on this is that you’re not gonna have a standard unless you have a standard that everyone can implement. Right now Mozilla and Opera there can be discussion about that, but they don’t seem to think that they’re able of implementing H.264 in the browsers.
Kevin: When you say able you mean they can’t— it’s incompatible with their licensing? Is that what you’re saying, or it just costs too much money?
Louis: I think it’s probably a combination of the two things. Mozilla has come out very strongly and said that they’re not gonna do it and it’s not gonna happen; I’m not too up on what Opera is doing. And there’s definite issues, for example, Mozilla is the default browser in a lot of Linux distributions and that would be incompatible with the licensing if they included the decoder in the browser. I’m not sure whether that would necessarily be the case for just a Mozilla distribution that you download onto your Windows machine or whatnot. Yeah, so I remain of the opinion that we need a video codec that is free for any browser maker to just throw in there and distribute.
Kevin: So I guess why is that? Like if we’re talking about licensing for inclusion and open source operating system distributions there’s a very clear argument there. If we take that as a given, that that’s a good thing that we want operating systems that licensed under open source to be able to include this out of the box, let’s say that is something we definitely want to achieve, then you definitely need a video codec that at the very least has a legal piece of decoder software that is open source code.
Louis: Yep.
Kevin: Yeah, that is compatible with the open source licenses, basically you don’t have to pay anyone to use that code, you can pull it out, drop it into your browser in this case, and as long as you give proper credit you’re in the ballpark, and of course there’s a whole lot of subtleties depending on which license we’re talking about, but that’s really what it comes down to is that H.264 as a format if you want to make your browser play it back there’s no open source code out there to do that, certainly none that is legally distributed; if you want to play that back you need to go to the licensing body and sign up for a license, whether that’s a free license or not depends on how you’re gonna use it and these subtleties, these licensing restrictions all interfere with your ability to include it in an operating system like Ubuntu. So you’ve used desktop Linux for a while?
Louis: Yeah, I’ve been on Ubuntu probably for three or four years now, it’s my main desktop OS. I still use Mac at work but my preference is for Ubuntu and that’s what I use personally.
Kevin: So open source operating systems aside, what is the benefit? We’ve talked on the podcast about different definitions of open, and we’ve just covered the one where you can get free software to play it back and no matter who you are or what you want to do with it. There’s also the definitions of open that include all of the W3C technologies, HTML, CSS, these are all developed in a standards body with a bunch of interested parties signing on to collaborate and no one has exclusive control over this spec, anyone can introduce a change that then must be voted on, when it gets to the final step of the spec the public can weigh in and raise objections; it’s a slow process, it’s a deliberate process, some might say it’s what has made the Web what it is. Does it concern you at all that a format like WebM doesn’t come with those benefits of standardization, open standardization?
Louis: To be perfectly honest no it doesn’t. I think that we have a bunch of technologies on the Web that maybe sort of follow that process or don’t. In this case, in my mind the most important thing is to have something that’s royalty free and that can be easily incorporated into any browser or any kind of — not only for browsers but for websites as well from the encoding side if I’m doing sort of a YouTube-like venture and I want to be able to encode video if it’s for commercial purpose; right at the moment that does involve paying a license fee to MPEG-LA if I want to use H.264. So previously the debate had been between okay we’ve got Ogg Theora which was the pre-existing open source video codec—
Kevin: Yeah, that’s the one that Firefox and Opera decided to bet on initially before WebM was bought by Google and opened up.
Louis: Yep.
Kevin: And people say it sucks.
Louis: People said it sucked basically that was the thing.
Kevin: We tried experiments of encoding video for our courses in Ogg Theora and I can confirm: it sucks. (laugh)
Louis: Right, just did not have the throughput required to encode. You just wind up for the same quality with a much larger file than you would with something like H.264. WebM on the other hand using the VP8 codec is comparable, you know, there’s people nitpicking about the tiny details, but it is comparable in performance with H.264, and it’s something that everyone has really kind of embraced fairly quickly, so Chrome supported it initially of course, but Firefox and Opera within a few days of it being open sourced had added support to their nightlies or to their betas. Yeah, and I think it’s interesting when you read the blog posts that were decrying Google’s move to drop H.264 support from Chrome a lot of people seemed to be saying that this was somehow changing the landscape or that it was adding to fragmentation, and I just — I couldn’t see how that was the case given that a sizable portion of the existing browser market already had exactly the same level of support as what Chrome was moving to.
Kevin: Right. Google’s move may have been in the opposite direction to the way others are moving, but it didn’t make them any worse, they’re by far not the worst browser as far as video playback is concerned; they are no worse than Firefox, no worse than Opera and certainly no worse than Internet Explorer as a result of this move. And the move was not made as a blind “we’re removing this”; they are removing it to replace it with something that they would like to see other browser vendors replace it with.
Louis: Yeah, and as I’ve said those other browsers are already at that level of support, so you’ve got this segment of the browser market and since Mozilla and Opera have both stated “we’re not gonna move in any direction from here” either because it’s incompatible with our license or because we really can’t afford as an organization to pay the licensing fees, then what was gonna happen was either we move en masse to something that is royalty free or we start using H.264 for everything and then Opera and Firefox get Flash, which, you know, personally I don’t see as an adequate long term solution.
Kevin: Well, the long term vision I suppose was that Opera and Firefox would have their hands forced or they would be forced somehow to implement H.264 video even if it was as an add-on that you would have to download after the fact, add that “native” support for that format; H.264 would never be a ratified format by standards bodies like the W3C because of its licensing necessarily, but if it became a de facto standard they’d have to find a way to support it, I guess that was the hope.
Louis: Hope, yeah, or the fear, depending on which side of the aisle you stand on. Yeah, I realize that it’s sort of an ideal position to say we’re gonna try and hope that we’ll have a fully royalty free solution.
Kevin: Could this have ever happened without a big company like Google saying alright take our money? Someone has to pay for the Web to have an open format, it’s gonna be us, let’s write a big check and we can all move on. If Google hadn’t done that do you think someone else would have eventually or would we be stuck?
Louis: Well, I think in this particular case because of the quagmire that software patents entail I could’ve, you know, things like Ogg Theora where a bunch of open source hackers will come up with a format, one it’s unlikely to be that good if they’re trying to steer clear of patents, and two they might not do that good a job of steering clear of patents, whereas Google when they do something like this they’ve got a team of lawyers that they can go over the code with a fine-toothed comb and say “We are sure insofar as we can be—”
Kevin: Fingers crossed.
Louis: Fingers crossed. ”—that if Mpeg LA decides to come after us on a patent issue with this that we have a case at least.” So because software patents are such a tangled issue and so difficult to protect yourself against I think it took something like Google to come up with something that would eventually potentially be a solution for the Web.
Kevin: So much of this argument is hypotheticals and worst-case scenarios. I think back to the issues surrounding the GIF image format; I remember someday in must’ve been 1997 someone told me “Hey this company’s claiming ownership over compression technology in GIF and they’re gonna try and get everyone to pay money for ever GIF file they’ve used on the Web”, and there was mass hysteria for a day or two and people were saying, “Oh, we’re gonna have to replace all my GIFs with JPEGs, they’re gonna take up so much more space and be so cruddy looking because of the compression.” And there was, I’m trying to remember if anyone ever actually removed support from GIF, I don’t think they did; there was talk of them going after the browser vendors who would have been Microsoft and Netscape at the time, and I’m not even sure if that ever really made it to court. But the response from the developer community seemed to me to be particularly swift and efficient, whereas the moment it was identified that this format was definitely tainted and people were trying to extract money from it the developer community up and moved to PNG.
Louis: Yeah.
Kevin: And the browsers lagged behind by a couple of years until we saw a reasonable PNG support but it came pretty quickly, certainly quickly enough that no one ended up having to pay anyone any money for GIF licensing, and now here we are after that and no one even remembers that there are problems with GIF, I think at this point, I’m trying to remember the dates involved, but if it hasn’t already expired we’re very close to the licenses on GIF technology expiring and it’s gonna very quickly be a non-issue if it isn’t already. It seems to me the same would happen with a video format, be it H.264 if the standards body—or not the standard’s body—if the licensing company that owns it decided to suddenly go back on their word and start charging people for it, or if WebM suddenly someone claimed ownership over that technology in a way that hadn’t been anticipated, if either of those things happened it wouldn’t be the end of the Web, we would just move to something else, the developer community would rally I think and build something new or fall back to something safe.
Louis: Yep, I think that’s fair, but I think that this step of sort of entrenching WebM, which as far as we know is a royalty free video codec, is a sort of a step in terms of maybe protecting browsers from something like that happening because you’ve got this thing that’s out there and people will start hacking it, decoders and encoders coming up with different implementations in browsers, so there will be broad support for an alternative standard pre-existing if ever something goes south with H.264.
Kevin: It’s got this huge public profile, you know, we can’t get five years into every web site migrating to this video format and then some company coming along and go, ahem, excuse me, excuse me you all owe me money; it’s gonna seem at best disingenuous if that were to happen, they’d be like “Where were you five years ago when we were making this a standard?” Alright, so what are your thoughts on hardware decoding?
Louis: Um, yeah, alright. (laughter)
Kevin: Okay, look, we both have Smart Phones in our pockets; mine happens to have an Apple logo on it and therefore can only play H.264 video in hardware.
Louis: I believe I’m fairly certain mine can only play H.264 video in hardware, I don’t think WebM support was added until Android 2.3 and I haven’t upgraded yet.
Kevin: And even then it would be in software, so yeah, it would chew your battery if you were watching YouTube for very long. So I suppose what is the picture here of how we move forward when we have these i-devices that will be around for years with H.264; one assumes that even in a best case scenario for Google it’s gonna be a few years before you can convince Apple to build a WebM hardware decoder into one of their devices.
Louis: Absolutely, I think that’s probably true. As I’ve said I think that for Google and for developers like myself I think that we’re kind of playing all or nothing here, this is what we need and I think it’s worth fighting for, at least giving it a go, and Google’s given it a go, and I think with that combined force of having Google on board and Mozilla and Opera and even to a lesser extent Microsoft because they’ve added a plugin to IE9 already that adds WebM video support, it’s a fairly simple plugin installation, I think it’s sort of matter of time when you’ve got to wait and see, but I don’t think the playing field has changed that much from where we were a few weeks ago before this was announced. I think we’re still in the same place where, yes, if you want HTML5 video you kind of have to dual encode, and that’ll probably continue to be the case for a while now.
Kevin: What’s gonna prompt a developer, a lazy developer, to encode their first WebM video? Because I know I didn’t— I think most people encoded MPEG2 just because it was what they knew and it was convenient until these i-devices came along and forced them to move to H.264; either they stuck to what they knew or they stuck to what was automatically selected in their video production tool of choice. I’m just trying to get a picture for how quickly this is gonna change; are we gonna be sitting here in five, ten years’ time still saying “well you know everyone uses H.264 but everyone knows that WebM is where we should be moving”?
Louis: Who knows? I think it’s one of those kind of sit back and kind of wait and see things and we’ll see what happens, I mean obviously Google and YouTube have begun encoding in WebM so you’re seeing a pretty big amount of content out there already.
Kevin: Yeah, YouTube could be Google’s ace in the hole here because if they convert all of YouTube to WebM that’s a great first step, that’s a large chunk of web video that becomes available in WebM, maybe then they could afford to put out a handset, a tablet, a mobile device, something of that sort, that plays WebM natively and uses Flash or some software decoding for H.264. Putting YouTube over the line, maybe that’s enough so that they could—
Louis: I think it’s definitely possible, I mean you’ve already seen— So, the latest version of Android as I’ve said, 2.3, does include support in the browser for WebM video. There are a number of hardware manufacturers, I saw there’s one video on the WebM blog of a Chinese manufacturer demoing a tablet, an Android tablet that has hardware decoding built into the chip set.
Kevin: For WebM?
Louis: For WebM.
Kevin: Wow.
Louis: And that was demoed. So I think that for a lot of hardware manufacturers people seem to think that it’s not going to be that difficult and with the lifecycle of tech products for people to add this support to hardware, you might see a lot more hardware devices with this support sooner than you might expect.
Kevin: I suspect a lot of the people that are most vocally opposed to this are developers on a Mac who use Chrome as their browser of choice because, as you may or may not realize, listener, Flash on the Mac, playing video in a Flash movie on the Mac has traditionally been suboptimal, you know, having native video support you know a lot of people, especially Windows users used to their relatively fast and reliable Flash Player on Windows, they might go what’s the big deal, I don’t care if my video is played natively or through a Flash movie as long as it plays, whereas on the Mac at least until very recently video played through a Flash Player could pause, could slow down other things going on on your machine, could eat your battery, cause your CPU fan to spin up like crazy.
Louis: As bad as it is on Mac I can guarantee you it’s worse on Linux.
Kevin: (Laughs) Yeah! I didn’t even realize, yeah, of course it would be worse. So ordinary users may not care about this but developers who tend to be on these days slightly more fringe environments feel the difference between native video and Flash a lot more, and so, yeah.
Louis: I mean I think for the foreseeable future you’re still gonna see a lot of people who encode H.264, run that native and then wrap it in Flash as a fall back because that right now does actually run on everything more or less. So your iOS devices get the H.264, Safari gets the H.264, then you’ve got your Chrome, your Mozilla, and your Opera that’ll get the Flash fall back. And that’s sort of a reasonable— So you only encode once and then you provide suboptimal experience to some of your users.
Kevin: On the desktop it’s easy to say it’s a wash because there are so many CPU cycles to spare, and you can afford to, for a transitional period, decode video in software if you really need to. On the handsets on the phones it’s such a different landscape, and I’m sure that Google is going to have to be the first ones to put out a battery restricted device that can play WebM in hardware and can’t play H.264 in hardware. It seems like they’ve taken the leap on the desktop but it’s such a bigger leap to take on mobile devices. I’m looking forward to seeing it though.
Louis: Yeah, it’s going to be an interesting playing field for the next few years at least, and it’s also is going to depend, it depends on a few things, it depends on what Apple does, it depends on what Android device manufacturers do, and Android device manufacturers are pretty fragmented as is, there’s a lot of different players out there and they’re all doing different things for different reasons, so what they choose to do in terms of hardware support is gonna be interesting. And then what Apple does; Apple may look at this and say “Well if all of YouTube is available in WebM and most of our users primarily care about seeing YouTube videos then it’s not that big a step for us to add this support for the chip”, because the IP for the hardware decoder is out there, Google has open sourced that as well, so it’s available for the hardware manufacturers, so I think it’s one of those things where you do have to wait and see.
Kevin: We’ll get there.
Louis: But I for one am happy that Google kind of took a stand and they probably saved a big chunk of change while they were doing it.
Kevin: Do you think?
Louis: I think they were probably paying a few mil to MPEG-LA.
Kevin: I think they will be for a while yet, though.
Louis: Yeah, but not for the browser.
Kevin: Right, yeah.
Louis: It might be insignificant in the scope of Google’s budget, but you know.
Kevin: You just compare it to what they must be paying for that license for YouTube.
Louis: Yeah, right, obviously it’s not gonna be huge, but everything counts.
Kevin: Where would we be without Google? I mean that sounds like such a fanboy statement but I kind of mean it, like you know for a while there everyone seemed very ready to capitulate on video, they were going to say look we need open, free standards for markup, for styles, for scripting, maybe even for audio, but when we get to video people kind of went you know what video is voodoo, we had our shot at it and that was Ogg Theora, we couldn’t do a good job in the open source arena, someone needs to get paid for video and so we’re willing to sacrifice, we’re willing to say okay you know what the best format for video on the Web is not a free, open source encodable/decodable format, it’s H.264. Where would we be without Google? If Google hadn’t been there to come along and sign that check I don’t feel like anyone else would have, I think like the Microsofts and the Apples of the world were ready to write those checks and the days of being able to implement the Web as a platform for free would be over.
Louis: Yeah, I think that’s a fair assessment, and when we talk about Apple and Microsoft writing those checks don’t forget about Apple and Microsoft cashing those checks because both of those are members of MPEG-LA, so they’re receiving the royalties as well, so it’s not just that flat an issue. It’s great that Google could come out and do this, I think it’s probably a good thing and it’ll take a long time to play out and it may not work, it’s still definitely up in the air and Apple has enough dominance especially in the mobile space that if they decide no we’re not doing it then it’s never gonna be a viable option, you’re still gonna have to dual encode if you want to provide video to iOS devices, and iOS devices is a big market.
Kevin: I wonder if video is the final frontier here or if there is some next medium, some next form of content that we’re gonna have this same issue over—
Louis: Oh, they’ll come up with something.
Kevin: —where it seems way too hard to do open source and free and we’re gonna be all too ready to take out our pocketbooks and start writing someone a check to add that feature to the Web, and will Google be there to write that big check for us when the day comes.
Louis: Who knows? I guess we’ll just have to ride it out. Stay on the Web, stay tuned.
Kevin: There were a couple of other stories that we didn’t really cover on the podcast this week, and since I have you here I’d love to get your thoughts on them. The first one is—
Louis: The logo.
Kevin: —the renewed furor around HTML5, which may or may not be called HTML5 depending on who you ask.
Louis: Depending on who you ask, that’s right.
Kevin: I think this all came back on the landscape with the introduction of the HTML5 logo.
Louis: The logo, the feared logo.
Kevin: Which if you haven’t seen it you should go to w3.org/html/logo.
Louis: It is supposedly a logo for HTML5. There was initially some confusion and there still is really as to what they mean by HTML5 when they put forth this logo. So as you scroll down the page at /logo in the W3C site you’ll see that it has these basically eight classes of things that are part of what this logo stands for.
Kevin: Right. So there’s HTML5 semantics, offline and storage, device access, connectivity, multimedia, 3D graphics and effects, performance and integration, and CSS3 styling.
Louis: CSS styling, that’s right.
Kevin: I like how they saved that one for last, kind of catches you by surprise.
Louis: (Laughs) It does. So each of those things is represented by a really, really cryptic pictogram which if anyone can perform a quiz where they can identify what each one is—
Kevin: Yeah, you need one of those—you shuffle them up and you have to draw lines between them. (laughs)
Louis: So, yeah, it’s a weird move coming from the W3C, or generally speaking somewhat of a more conservative body, and who you’d think would be the pedants who would be saying “No, wait, HTML5 it’s actually the HTML specification.”
Kevin: Yeah, if anyone!
Louis: If anyone it would be the W3C, and here they come out with this logo that’s sort of—
Kevin: Initially they had a statement on this page that said what does this logo stand for, and it said the HTML5 and the HTML5 logo represents HTML5 technology including CSS3, and basically the entire raft of modern web standards they grouped under HTML5, which is something we have ridiculed on this podcast before; we’ve called HTML5 the “kitchen sink” term, that it can mean anything, it can mean nothing, and it’s really been diluted over the course of the past year from a very specific technical meaning to a meaningless technology buzzword.
Louis: It’s funny, I’m actually gonna disagree on that. I’ve always had the opinion that this use of HTML5 as this catch-all marketing term isn’t as bad a thing as most people would seem to have you believe.
Kevin: You would think, though, if anyone would be upset by it—
Louis: It would be the W3C.
Kevin: Right. So why is it nothing to be too worried about?
Louis: Well, so I think that if you look at these things, no matter what you think about the little pictograms that represent them or how they all tie together into the spec, we all recognize them as something that have gained browser support in the past year or two, something largely driven by the rise of mobile devices like iOS and Android which have modern WebKit engines in them, so things like offline and storage, like so we’re talking about what they call device access includes geolocation, microphones, cameras, tilt, all that kind of mobile related stuff, they talk about connectivity which is mostly referring to web sockets, multimedia is of course audio and video which we’ve been talking about, graphics and effects they’re talking about SVG, they’re talking about Canvas, they’re talking about WebGL.
Kevin: They’re talking about CSS transforms as well.
Louis: They’re talking about CSS 3D transforms. Performance and integration they’re talking about web workers primarily and CSS3, so all of this stuff really in everyone’s mind has been tied together for quite some time, right, we’re all aware that if you’re building this modern web application that uses—
Kevin: Well, I don’t know about tied together, I would just say that’s a state of the Web in 2010.
Louis: That’s a fair assessment.
Kevin: So if this logo represents a website built in 2010 I’m with you.
Louis: I think it does (laughter), I do think that’s what it means.
Kevin: Alright.
Louis: I do have issues with the thing, I mean my issues are these were pictograms and the fact that who’s going to display this, I think they kind of meant it to be like those old little W3C valid HTML valid CSS things—
Kevin: Except that the frequently asked questions here, because I thought immediately okay so this is the anti-Flash logo, this was my initial reaction, we have used everything except Flash on this website that’s why you would use this logo, but the frequently asked questions says “Can I use this logo on websites that aren’t built with HTML5?” And the answer is, “Yes, for instance many people have used it on their blogs to show their support.” “Does this logo imply validity?” “No, this logo does not imply validity or conformance.” (laughs) It’s the mean-nothing logo about the mean-nothing buzzword.
Louis: Yeah, alright, I don’t think it’s a mean nothing buzzword, though, I think if you go out there and ask like I’m building an HTML5 web application and you wouldn’t have to tell someone that you’re using CSS3 box-shadow and text-shadow and @font-face or that you’re using perhaps geolocation, you know, a lot of these things are for better or worse kind of bundled into a lot of people’s minds as what falls under HTML5, and whether that’s actually true in terms of the spec or not I think it’s a clear way of representing this group of technologies.
Kevin: I’m wondering how relevant this is gonna be in a year’s time at the pace we’re currently moving.
Louis: The logo, absolutely nil. Zero. (laughs)
Kevin: Yeah, because I read an article earlier today about why Firefox 4—which is currently at beta 10, and once again a reminder to our listeners if you haven’t downloaded the Firefox 4 beta and tested your site in it now is your chance. But, this article about how Firefox 4 doesn’t pass the Acid3 test and probably never will, and at first glance I went “Oh this should be good, this will be rich,” and I went and read it and I actually completely agree with their reasoning because that last three percent it’s at 97% now and has been for several versions, and that last 3% is SVG fonts, which it’s testing the ability to load extra fonts into your SVG graphics, which it turns out is not a very well defined portion of the SVG spec, and also the interactions it would have between the SVG, the Scalable Vector Graphics that appear on your site and the HTML that appears on your site, are not well defined in the specs either. So there’s a lot of— If you implement this you have to make a lot of decisions as a browser vendor and there’s no spec to tell you what the right answer to those decisions are. The browsers that do pass the Acid3 test with 100% have basically made arbitrary decisions on those points and have really just implemented the bare minimum of these features to pass the test; really the support for those features is basically useless, all it is there to do is to pass the Acid3 test. And so we have this test now that when it was introduced some odd number of years ago it was the best tool to measure, for the next little while, browser support of modern web standards, but here we are now a few years later and it is this misleading thing.
The HTML5 logo with its eight sub-logos, and they have this tool on the site that lets you tick the boxes that your site or your browser supports and it generates this HTML5 logo with the sub-logos embedded in it to show just what your site or your browser supports. It seems to me if all of the browsers were to come to this page now and go alright we want to display the version of the logo on our site to advertise the modern standards support of our browser they’d go, yep, tick that box, tick that box, tick that box and they would all have the version of the logo with all eight of the sub-logos in it because they all have some level of support for these things. And even now in 2011 you get this sort of everyone claiming 100% and it seems pretty useless and let alone where it’s gonna be in five years when we are arguing over features of HTML that were not even imagined when this was put together.
Louis: Yep, I agree. You’ve got to give it to them from a branding perspective.
Kevin: Right, aesthetically what do you think?
Louis: When I first saw the logo out of context I didn’t like it, I thought it was kind of goofy and cartoony and whatnot, but then when I saw the full branding site that they’ve put together it kind of makes the logo make sense because it fits into this aesthetic that they’ve put together, and it is an impressive piece of work, I think it’s a really good looking site. And if there are people out there who weren’t excited by this stuff or who might’ve though HTML5 is just article elements and section elements and then some rounded corners in CSS3, and if this can open people’s eyes to “Oh wait there’s all this stuff about geolocation, about web workers that’s becoming standardized and that is well supported across a lot of browsers and that you can start using and that really does amplify the power, potential power of a website pretty significantly”, then that can only be a good thing. The only potential risk is that it might lead some people to misunderstand what HTML5 is, I’m not even really sure that is a risk, or that it might lead people to sort of think that this is where we’re at and then anything beyond this is no longer HTML5 or if browsers start implementing some new feature, as you were saying, that it doesn’t count as part of HTML5 or doesn’t register as something cool that you should be using. But I’m not sure I see a risk of it.
Kevin: I kind of like the look of it, I agree it’s a beautiful piece of branding work, I think the 5 is the biggest problem in it.
Louis: It has surfaced, that all the sub-logos—
Kevin: We’ll come back to the 5; we’ll come back to the 5. I want to just touch on something here that I want to figure out how to say this without burning any bridges because I know people who work at the W3C, and I respect them, in some cases I am amazed by their intelligence and how much they know and how much of their time they give to the open standards movement. So, with that said, I’m always hearing out of the W3C that the reason things go so slowly is because so much of the real work that is being done is being done in volunteer, in spare time by people who could be getting paid a lot more to be doing other things, and attracting that kind of effort is really difficult and they have trouble getting people to shoulder the burden of things like editing specs and extracting consensus out of a mailing list of 100 angry people, and that’s hard work. And this to me looks like someone went home on the weekend and went screw this, I don’t want to actually work on any specs this weekend, I’m gonna design a logo. And it was meant to be a weekend and two weeks later they’ve got this beautiful branding site and they showed it to somebody at the W3C and they couldn’t help but go “Good work, Bobby!” And this within a week was thrown up on the W3C’s site without a whole lot of consideration. You know, I hesitate to cast aspersions here but this feels like the W3C doing stuff that their time is better spent elsewhere.
Louis: I have to agree with you there, I don’t think it’s necessarily — it’s definitely not part of their core mission by any understanding, there’s a lot of other things that are issues at the moment and as we’ll talk about very soon the sort of tensions with the WHAT Working Group are some of those things, and yeah I think there’s probably a lot of room for these people maybe knuckling down and focusing on trying to get the specs as good as they can be and getting that buy-in from browser makers. But you never know, I mean if this— I can’t claim to know what they were thinking, what the process was behind it, they haven’t really explained it a lot. One thing that they did do is come out and change the FAQ—
Kevin: Yeah, they’ve been responsive to criticism.
Louis: —after there was criticism of bundling all these technologies together they changed the FAQ to say we don’t mean to say that all of these technologies are part of HTML5 we just mean this is a logo that can be used to represent HTML5 and that could be supplemented by all these additional technologies.
Kevin: I mean they’re selling t-shirts and stickers, maybe it’s a fundraising effort, and if that’s the case then forget everything I said; if they need to raise money and this is the way they’ve figured out to do it, great. I applaud it if that’s the case.
But let’s come back to this 5 because in the past week we’ve had related news from the WHAT Working Group, the Web Hypertext Application Technology Working Group I think it is, it’s been a while since I’ve spelled it out, but the people originally behind the HTML5 specification before it was accepted and adopted and endorsed by the W3C, they have made the move in this past week to remove the 5. It’s no longer called HTML5; we’re over this whole version number thing. What’s your initial take on this?
Louis: So this is really interesting, so before this happened I don’t know if you caught it but there was sort of a discussion where I first became aware of it, and it was before it was officially announced was on Jeremy Keith’s blog, where he sort of said I had this argument with Ian Hixon way back in the day about whether or not there should be a version number, and at the time Ian Hixon was saying there shouldn’t be and Keith was saying there should be.
Kevin: We can see an expression of this logic because the <!doctype> tag in the HTML5 no longer has a number in it.
Louis: That’s right. And I think that from a logical standpoint if you look at what they’re trying to do with the HTML5 or HTML specification which is trying to do something which is backwards compatible which works to the implementation, so it’s doing basically trying to standardize what browsers are doing rather than specify what browsers should do, it does make sense, right, because it is whether or not they call it a “living standard”, which is the terminology they’ve adopted to describe the new un-versioned spec, they call it a living standard, whether or not you call it a living standard it kind of is because there will always be features added to it.
Kevin: HTML5 as it currently exists as a draft spec is already a way better spec technically than any HTML standard that has preceded it, that if you were a browser vendor having to look up the rules for how your browser should behave to be standards compliant you might be tempted to go and look at a completed spec like HTML 4.01 or XHTML 1.0, but in fact the HTML5 draft currently today provides way better, more solid advice even though it won’t be finalized anytime real soon. And so removing the version number sort of goes “This is HTML for all time, this is the definitive HTML, you don’t have to wait for us to put a version number on it to use it.”
Louis: I don’t think it’s necessarily saying that this is a definitive version; it’s just saying that this is the best we’ve got. It’s not really a draft because a lot of this stuff is already implemented and we do have good consensus on it, so calling it a draft is kind of wrong, is his sort of justification, but what we can call it is a living standard that we’ll add things to but we’ll only add them to it when we’ve got buy-in from the browser vendors anyway, so you shouldn’t really have to worry about what the version is. Because if something’s in there it’s because the browser vendors have sort of agreed on it and we know that this is what we want to do and this is where we’re going. And because the new mantra at WHAT-WG is backwards compatibility and working to make sure that we don’t break compatibility with older websites then it seems like this is sort of a logical step. That being said, whether or not it’s ever gonna get any traction is a wholly ’nother story, right, because the W3C is still the one who’s putting forth the actual specification that’s recognized as a standard, the W3C’s draft sort of goes to them and then they’ll approve it.
Kevin: Yeah. Well, it’s a whole weird incestuous thing that initially the HTML5 standard was created in protest of the slow movement of the W3C, and then the W3C kind of went, yeah, you’re right, what you’ve written is way better, we’re gonna adopt it, and the WHAT Working Group initially shook hands and then went “You know what? We’re gonna maintain our own version of that spec anyway just in case there’s any things we disagree on we can put it in ours, you don’t have to have it in yours.”, which immediately kind of took a lot of wind out of the sails of people who are going, “Yay, we’ve reunited HTML!” Uh, not so much.
Louis: What bugs me about this isn’t that I— I do think it’s a good idea, I do think it’s an accurate representation of the work that the WHAT Working Group is doing, and I think it probably might help to clarify the understanding of what that shift has been, so they have gone from doing something which is very tightly versioned to doing something which was trying to be backwards compatible and a living standard, so they were already doing that but a lot of web developers might not have understood that because they see a version number on it, right. So I think all of that makes sense and it’s a good idea, but then you look at the fact that they did it three days after.
Kevin: This is where it becomes a dick move.
Louis: (Laughs) See, it is, you know, whether or not it was agreed, you know, I can agree with it.
Kevin: And Ian Hixon states publicly that they considered doing this awhile back and then today they decide to actually do it.
Louis: Yeah, right. So he says, he basically said that this change had been planned for over a year but there were people within WHAT who agreed with it, other people who disagreed with it, but then basically after the W3C put out their HTML5 logo he sort of said, well, now is as good a time as any, apparently, and walked around and asked people and he says that there was more agreement for the idea of removing HTML5—
Kevin: According to some people it was the very next day.
Louis: Yeah, that’s entirely possible. I just remember it following very hot on the heels. And it just seems like it’s something that’s only gonna add to the political infighting between the two groups. It wasn’t necessary to do it that quickly; we could’ve had the discussion out there with various people who were concerned.
Kevin: They were taking feedback on the logo, why wouldn’t they suggest you know what, um, if this logo is meant to represent the emerging stable features of the ongoing standardization development process why don’t we make a generic web standards logo, take that orange shield and instead of putting a big white 5 on it put ‘web’ on it or something of that sort.
Louis: Something like that, yeah. There was a bunch of ways that this I think could’ve been handled that wouldn’t have had as much strife and potential infighting come out of it.
Kevin: Yeah, but it’s par for the course from what we’ve seen out of these two groups, that although they are in an uneasy alliance it feels sometimes like the WHAT Working Group never misses an opportunity to, I don’t know, to stab them in the back sometimes.
Louis: To try and show off, yeah.
Kevin: Yeah. Well, look, my initial reaction, though, politics aside, was positive of the removal of that version number; I think it’s the right move. Until I read this post by friend of SitePoint Roger Johansson at 456 Berea Street.
Louis: I have not read that post.
Kevin: He’s kind of playing devil’s advocate here, he’s saying yeah he sees the reasons for removing that version number, but he is happy that the W3C at least for the time being is sticking to its guns and will continue to put out versioned, numbered versions of this living spec. He sees that as a particularly good way of working because it really depends, the context that standards are being discussed, in whether those version numbers are useful or not. He says, for example, “I think we web professionals need a stable specification to refer to, especially when working in teams composed of people in different locations and even different companies. Being able to say this project uses HTML 4.01 strict is very useful since it gives everyone a stable reference that doesn’t change on a daily basis. Then there’s the maintenance, I can predict hearing ‘Last week this document was valid but now it isn’t and I haven’t changed anything. Why is that?’, from some clients. For projects where using valid HTML is a requirement of versionless HTML specification complicates things.” So I kind of agree with him there that maybe these two bodies are settling into the roles that are best suited for their individual strengths, that the WHAT Working Group should be forging forward with a living document and the W3C maybe should be trailing behind going “Oh okay that’s a stable version of that tag, we’re gonna mark it for HTML6, that’s gonna be the version we publish even if browser vendors have moved on and added features to it in future.”, maybe.
Louis: Yeah, I see that as kind of valid. It’s again gonna be one of those things that again we’ll have to see how it plays out and what the W3C does, right now they haven’t really responded in any public manner, they’re kind of acting as if this hasn’t happened; if you look at their blog they’re still talking about the logo and feedback on the logo, they really haven’t gone back and said “Oh what does the version thing mean?” So, yeah, it’s interesting, I do agree with Roger on the one point of being able to talk about what we’re doing, because if I say I’ve built my website using HTML that could easily mean HTML2, and that’s a problem. And a lot of people in the SitePoint comment thread, Craig Buckler wrote a post about the dropping of the version number, and that was sort of their complaint as working developers that it’s hard to use just HTML as a descriptor for anything because it basically is a descriptor for everything; if HTML5 is the kitchen sink, HTML is the entire kitchen.
Kevin: Well, these are where those sub-icons can start to play a role I think, that you can say we’re using HTML with geolocation, we’re using HTML with 3D geolocation maybe next version.
Louis: (Laughs) 3D geolocation, that’s good.
Kevin: Yeah, I think if we can start labeling these sub-elements of the standard.
Louis: So you can check in in the Foursquare at the center of the earth— the Starbucks at the center of the earth on Foursquare is what I meant to say.
Kevin: (Laughs) Well, I think once upon a time you could’ve made the case that we don’t need three separate specs with three separate version numbers for HTML, CSS, and JavaScript, today that goes without saying. Maybe HTML has gotten to the point where putting a version number on the whole thing is gonna be useless and we need to start versioning the little bits and pieces.
Louis: Yeah, that probably also makes sense. And, again, I do think the WHAT Working Group has a role to play here, as you said, what they’re doing is sort of versionless, not exactly a “draft”, but a living standard that represents what the current best agreed upon solution is and what the browser should be working to, then that makes sense for that to be somewhere in a sort of a stable form rather then just these internal drafts that no one knows if they’re sort of still working documents. So Ian Hixon in respect to this, just got a quote here, says “In practice implementations all followed the latest specs draft anyway, not the latest snapshots. The problem with following the snapshot is that you end up following something that is known to be wrong, so that’s not the way to get interoperability.” So to have something out there that does represent the latest consensus is probably a good thing even if it means that the W3C is gonna have to pick and choose for what it wants to include in a snapshot just for purposes of having a spec that’s sort of frozen in time and that we can refer to. But then again you could also consider we could refer to it by date, you know, “this project is the HTML5”— or sorry, —“the HTML specification as of January 24, 2011,” and that will be the document I’ve got a copy of; it’s in the project repository so if you want to know how to do something you look in there.
Kevin: HTML 2011, that would look pretty good on that orange shield.
Louis: (laughs)
Kevin: Well, thank you Louis for sitting in on the podcast here today.
Louis: It’s been a pleasure, always good to talk about these things. It’s been a very exciting week, and it’s a lot of things that sort of testify to where we’re at in the Web, that things are moving again after a long period of stagnation to have stuff to talk about with regards to specs and video and all these things is testament to the fact that we’re getting somewhere.
Kevin: It’s worth the occasional dick move.
Louis: I think that should be the title of the episode: It’s worth the occasional dick move. (laughter)
Kevin: Alright, well thank you Louis.
Louis: Alright, thank you Kevin.
Kevin: You can find Louis on Twitter @rssaddict.
Louis: That is correct.
Kevin: And thanks for listening to the SitePoint Podcast. If you have any thoughts or questions about today’s interview, please do get in touch. You can find SitePoint on Twitter @sitepointdotcom, and you can find me on Twitter @sentience. Visit sitepoint.com/podcast to leave a comment on this show and to subscribe to get every show automatically.
This episode of the SitePoint Podcast is produced by Karn Broad and I’m Kevin Yank. Bye for now!
Theme music by Mike Mella.
Thanks for listening! Feel free to let us know how we’re doing, or to continue the discussion, using the comments field below.
Kevin YankKevin Yank is an accomplished web developer, speaker, trainer and author of Build Your Own Database Driven Website Using PHP & MySQL and Co-Author of Simply JavaScript and Everything You Know About CSS is Wrong! Kevin loves to share his wealth of knowledge and it didn't stop at books, he's also the course instructor to 3 online courses in web development. Currently Kevin is the Director of Front End Engineering at Culture Amp.
