The debate over HTML5 vs. Flash is great for comments and page views, but all that chatter obscures the bigger issue: Should developers and designers invest in HTML5?
HTML5’s feature set
Eric Meyer: It’s really the HTML we’re all used to plus more elements. But that’s the 80/20 answer. HTML5 adds new elements for things like sections of a document and articles, and figures and captions for figures. So it covers things that a lot of us do all the time, like create <div class=”figure”> and then <p class=”caption”> inside of that to go along with an image. Now there’s just an element called “figure” and you insert an image and you have an element after that called “caption.”
There’s been an attempt to look at what people are doing. What class names are people using over and over again? What structures are they setting up over and over again? Because HTML doesn’t have elements that directly address those.
The HTML5 spec also attempts to very precisely and exhaustively describe what browsers should do in pretty much any given circumstance. Older HTML specifications would simply say: “These are the elements. These are the attributes. Here are some basic parsing rules. Here is what you’re supposed to do if you encounter an error.” HTML5 has these really long algorithms that say: “Do this, then this, then this, then this. And if you hit a problem, here, do this other thing.” There’s a lot of debate as to whether that’s even a good idea. But if the vision that’s encoded in those algorithms is brought out — I’m not saying it will be, but if it is, then browsers will be a lot more interoperable.
But that’s the base level answer. As you push further into the more obscure corners, then the answer to “how is HTML5 different?” becomes much more complicated.
MS: Is HTML5 becoming a full-fledged development environment?
EM: I don’t see it stepping forward into full-fledged programming. But I do see it pushing HTML forward so that it’s a better foundation for web apps. That’s one of HTML5’s primary goals. There are sections of it that are devoted solely to how to deal with web application environments.
The thing that’s most directly applicable to making HTML more web-application friendly is the attempt to include what’s known as microdata. That’s semantic information and little snippets of data that can be embedded directly into what we think of as pages right now. But these can become the views a web application presents. It’s the kind of stuff that we put in cookies now.
What developers and designers need to know about HTML5
MS: What skills do developers need to take full advantage of HTML5?
MS: How about designers?
There are a lot of people who call themselves web designers who are really just designers who put their designs on the web. And there’s nothing wrong with being just a designer. But they’re not necessarily web designers. They’re visual designers. There’s a difference.
MS: Would you recommend starting with web development skills and then adding Flash and others later?
Yeah. Make that your grounding and then add things to it if you like. You’re making a very dangerous bet to not have web tools at your disposal. The developer should be able to do web work. And it’s not a bad idea to add Flash to the tool belt.
HTML5 vs. Flash: A rational comparison
MS: Without getting into the “Flash killer” stuff, how does HTML5 compare to Flash?
There are a number of people, myself included, who have been observing for a while now that the current web stack feels like Flash did in 1996. Look at the canvas demos, for example. The canvas demos we’re seeing now are totally reminiscent of the Flash demos we used to see in the ’96 era, where it was like: “Hey, look! I have three circles and you can grab one with a mouse and flick it. And then it bounces around the box and there’s physics and collision and animation and they’re blobby and woo hoo.”
MS: What’s your take on plugins? Are they inherently inelegant?
EM: That’s been my feeling for a long time. That any plug-in is kind of inelegant and the wrong way to be going about this. And I don’t reserve that just for Flash. I really mean any plug-in. The fact that we need plug-ins to play movies has never felt right.
MS: If, for a given application, HTML5 and Flash can provide the same result, why would a developer go with HTML5? What’s the motivation?
EM: HTML5 is native to the medium. It’s the feeling that if we’re going to do web stuff, let’s do web stuff. Let’s not do Flash stuff that happens to be represented in a web page. So I think that’s the philosophical drive.
The technical drive, to a large degree, is that companies don’t want to be beholden to somebody else. And doing everything in Flash means that they’re effectively beholden to Adobe. With web technologies, the only entity that can reasonably be said to hold the keys to the kingdom is the W3C. And even if the W3C for some reason turned into “evil goatee Spock” tomorrow and said “we want licensing fees,” everyone would go, “yeah, no.”
HTML5 and mobile applications
MS: Does HTML5 give mobile developers more latitude? Is there benefit in developing applications outside Apple’s approval process?
EM: Absolutely. No question. There are some people who have argued that the whole App Store phase is a fad. Granted, a very popular and lucrative and probably long-lived fad, but that it’s still a fad.
The argument is that 10 years from now we’re going to look back at rebuilding apps for every mobile device and go “What the hell were we thinking?” It’s the same way kids who graduate from decent web development programs today don’t understand why anyone ever tried to layout a page with tables. I’ve had conversations with people who literally just can’t understand. Even when you explain, “Well, there was no CSS.” They’re like, “But surely there was something better because that’s just awful.”
Betting against the web is the sure losing bet of technology. Over the long-term, that’s where I see things going.
Note: This interview was condensed and edited.