The beardier parts of the web-o-sphere have been abuzz about HTML5, the next version of the language that powers our internet. Will it revolutionize web apps? Will it kill Flash video? Will it fix our gimpy iPads? Yes… and no.
The tech press has transformed HTML5 from a quiet inevitability to an unlikely savior: When YouTube and Vimeo started testing it, it’s was invoked as a Flash-killer, and the emancipator of web video. When Google used it to design a new Google Voice web app, among others, it was framed as the murderer the of the OS-specific application. When the iPad was announced with no Flash support, HTML5 was immediately pegged as a salve, not to mention a way to get around the “closed system” of Apple’s App Store.
It doesn’t take much imagination to draw these stories into an appealing narrative about how the app-less, plugin-free, totally web-based future is just a browser update away. The thinking goes, somewhere in this impenetrable 125,000-word published standard, you’ll find the answer to the internet‘s every ailment: its clunky, proprietary plugins, its stunted web apps, its fundamental shortcomings as a platform for rich media. At the heart of each of these theories lies a grain of truth, but none of them are totally—or even mostly—true.
Here’s what’s really going on. HTML 5 is already working its way into the underpinnings of web apps you use every day, making them faster and more stable than those relying on Java or other plugins. They’re more like real apps. It’s helping us inch closer to the dream of having real applications available at all times, on any platform.
HTML is also setting forth a vision of media—specifically video—that doesn’t rely on crashy, resource-intensive proprietary plugins. Look in your plugins folder, you will probably see four video plugins at a minimum. HTML is a standard with an optimistic view of the future: You launch your browser, and whatever site you visit, whatever media you choose to play, your browser just magically supports it, without the frustration, confusion and added instability of a plug-in.
But at heart HTML is just a framework, a glimpse, and an ideal: Its real effect on the internet continues to be defined by the companies and web developers who choose to adopt its many pieces—and it is further shaped by those who don’t.
The Basics
Before we get into what HTML5 means, we have to talk about what it is, and to talk about what it is, we need to talk about what it’s built upon.
Hypertext markup language, or HTML, is the language underneath every web page you’ve ever been to. The language, along with its various complementary technologies (see: CSS, Javascript), has become immensely complex over the years, but the concept is simple. HTML is what turns this:
<u><em><strong><a href=”http://gizmodo.com”>Hello!</a></strong></em></u>
Into this:
Hello!
It’s basically a set of instructions that a website hands to a browser, which the browser then reads and converts into a formatted page, full of text, images, links and whatever else.
Here, try this: Right-click anywhere on this webpage, and click “View Page Source,” or “View Source,” or something to that effect. Your eyes will be assaulted with a wall of inscrutable text. You’ll see evidence of syntax, but your brain won’t be able to parse it. Your eyes will glaze over, and you will close the window. This, my friends, is HTML. But you probably already knew that, because it’s 2010, basic web languages are basically in our drinking water. So what’s this “5” business?
Somewhere in the central command center basement of the internet, there’s a group of guys who maintain the standard, or the rules, of HTML. In the case of HTML5, the buck stops with the Web Hypertext Application Technology Working Group (WHATWG), and to a lesser extent, the World Wide Web Consortium (W3C). It is through these independent standards organizations that new features are codified and presented to the public, and later—in theory—supported by various browsers, no matter what company is behind them.
In the early nineties, the W3C and a few influential torchbearers would collect various new web features thought up by different browser makers, publishing these standards with the hope that we didn’t end up with different internets for different browsers. By the mid to late nineties, the standards had grown in both size and stature, then serving as the de facto guide for browser makers and developers alike. (If this sounds a bit rosy, the reality was far grimmer—just ask any seasoned web developer about Internet Explorer, version 6 or earlier.)
Despite an occasionally rocky road, HTML standards went beyond being just a record of changes in web technology; eventually they became the blueprint to push them forward. Still, standards are guides, not laws, and no browser maker has to adopt each and every revision.
The last major revision of the HTML standard, version 4.01, was published in 1999. HTML5 hasn’t yet been formally codified, but it was born in 2004 and has been undergoing steady work and maintenance since. In the ’90s, HTML discussion centered around topics like font coloration, or tables, or buttons, or . Today, a new HTML version means deep-down support for the modern web, namely web apps and video.
The New Features
The HTML5 spec is more than just new tags and tools, but for users and developers, they’re what matter most. Specifically, I’m talking about APIs, or application programming interfaces. It’s because of these APIs (usually manifested as tags like <VIDEO> or <IMG>) that we’ll soon be treated to a richer internet. And it’s because of these APIs that when work on HTML5 started, it was called “Web Applications 1.0.” Today, if you pick apart HTML5, these are the biggest pieces:
• Video. If you watch video on the internet, you’re watching it through a plugin—a piece of software that works within your browser, but which isn’t technically a part of it. A decade ago, this plugin may have been clunky RealPlayer software, semi-reliable Windows Media Player controls, or a QuickTime plugin that you were better off skipping altogether. Today, it’s probably Flash or Microsoft Silverlight, or a newer, subtler Quicktime or Windows Media plugin. Whether you’re playing a YouTube movie embedded on a web page, or just viewing a .mov file as you download it, your browser has to use the plugin.
HTML5 includes support for a simple tag that lets developers embed video in a page just like they’d embed a JPEG or other image, with a pointer to a file on a server. Packed along with the ability to read that video tag are a few rendering engines, which would decode the video without any kind of plugin. Embedding a video with HTML5 is as easy as embedding an image, provided the video codec is compatible with the browser’s rendering engine. In terms of code, it can be as simple as this:
<video src=”video.mp4″ width=”320″ height=”240″></video>
Boom. Video. Here’s what some of the current rudimentary players look like:
–SublimeVideo (Safari 4, Chrome)
–YouTube (Safari 4, Chrome)
–Vimeo (Safari 4, Chrome)
–DailyMotion (Firefox, Safari 4, Chrome, Opera)
In theory, eliminating the video plugins means no extra CPU overhead, fewer crashes, and wider compatibility—if HTML 5 video was standard now, we wouldn’t be stuck waiting for Adobe to port their plugin to our mobile phones, and Mac users wouldn’t bring their systems to a crawl every time they tried to watch a YouTube video in HD. As a general rule, playing a video file through an extra plugin like Flash is going to be slower, buggier, and more resource-intensive than playing it through a browser’s native decoder. That’s why people are excited about HTML5 video.
• Offline storage: Remember Google Gears? It was a set of plugins for various browsers that let web apps, like Gmail or Zoho Writer (an online text editor), store content locally on your computer, so they could behave more like native apps. Gmail, for example, could then work without an internet connection. It wouldn’t retrieve your new emails while offline, obviously, but it’d at least have a working interface and a database of your old emails, just like Outlook or Mail.app would. Well, Google abandoned Gears, because HTML5 basically supports the same thing, again, without a plugin.
-Here’s a basic demo (Firefox 3.6, Safari 4, Chrome, Opera)
-And a more complex one, including lots of other tricks (Firefox 3.6, Safari 4, Chrome, Opera)
-Or, try Gmail on your iPhone or Android phone
• Drag-and-Drop Elements, and Document Editing. You know how you can drag and drop emails in Gmail? And how you type into text boxes, to post or send everything from Tweets to emails to forums posts? As it stands, these systems are built on a delicate, complicated stack of ad-hoc code tricks, which have worked fine up until now, but which could stand to be simplified. Even if you’re not a developer, just know that this, in theory, translates to increased stability. And that’s exactly what HTML5 proposes: Super-simple implementations of editable documents boxes, drag-and-drop page elements, and drawing surfaces.
-A helpful, ugly demo(Firefox 3.6, Chrome, Safari, Opera)
-And an exceedingly pretty one(Firefox 3.6, Chrome, Safari
• Locations services. Now a web app can tell where you are, if you choose to let it. Here‘s how that works. (Firefox 3.6, Chrome, Safari 4, Opera, iPhone)
There’s a clear trend here. HTML5 is about video, and it’s about far more stable yet complex web apps. These are the sources of excitement right now, but they’re also the sources of confusion.
Hopes and Dreams
On the desktop, the transition to HTML5 will be largely seamless, though you’ll notice an uptick in the quality, speed and richness of some apps you use all the time—think webmail, document editors, and text entry applications for starters. On mobile, the results will definitely be more pronounced. Remember Google’s new Voice web app for the iPhone and Pre? Take away the browser controls, and it’s almost indistinguishable from a native app.
The hope—and it’s a realistic one—is that certain categories of web apps will supplant native apps. The advantages are obvious: If your document editor is online, it’ll work consistently whether you’re on an iPad or a Windows desktop; if your email client is a website, your messages are always available, and your read/unread status is always in sync. Web apps like Google Documents will get faster, more consistent, and more universally compatible. Still, you’re not going to see Photoshop or Final Cut in your browser window anytime soon. If this dream sounds familiar, it’s because it’s very old, and already realized in many ways: Ancient services like Hotmail mark its genesis, and the app-less Chrome OS is its eventual, if limited, endpoint.
The second dream, and the one you’ve probably been hearing the most about lately, is that HTML5 video could kill Flash. As in, render Adobe’s plugin, which most internet-connect computers already have installed, completely obsolete, simultaneously making Apple’s iPad and other mobile devices more capable of getting at all the media the web has to offer.
Vimeo, DailyMotion and YouTube (YouTube!) have all recently launched pilot programs for HTML5 video technology. On the surface this is very exciting. Their players are basic, but they work, and there are some rather spectacular demos of more advanced HTML5 video players doing the rounds right now. The latest builds of the WebKit rendering engine, which comprises the guts of both Mac OS and iPhone/iPad (mobile) Safari, Google’s Chrome OS, the Pre’s browser and the Android browser, among others, support full-screen HTML5 video. The iPad notoriously won’t ship with Flash, but Apple’s desktop (Mac OS) Safari is one of the first browsers to fully support the HTML5 video discussed here, the natively rendered video used by YouTube and Vimeo in their tests. So the stars are aligning for an HTML5 video takeover, right? No, they’re really not.
Managing Expectations
As I mentioned, the WHATWG and W3C can publish as many standards as they want, but in order for any to actually matter, browsers have to support them—and by browsers, I mean all major browsers, from nimble, rapidly-developed apps like Opera and Chrome to Internet Explorer, which, by the way, is still globally the most popular dashboard to the internet. Take the <VIDEO> tag as an example: Safari and Chrome do support it, both the HTML code and the native rendering of a couple of associated video formats. Firefox supports the tag, but doesn’t support decoding of the key video format currently used by YouTube and Vimeo. Internet Explorer doesn’t support it at all without a plugin, and isn’t the whole point of HTML5 to get rid of plugins?
Just as different browsers update their rendering engines at different speeds, users of browsers update their software even less predictably, and some don’t update at all. Despite Microsoft’s aggressive IE8 evangelism, IE6 was only just bumped from being the Number One browser in the world. It was released in 2001, when HTML 4 was just learning to walk and HTML5 was but a glint in the W3C’s eye. IE6 will never work with HTML5 video. But it plays video just fine with Flash.
Even on the cutting edge, there are serious roadblocks to widespread adoption of HTML5 video, the most dangerous being video codecs. Because HTML5 supports video embedding natively, browsers will have to be able to decode embedded video files in lieu of the plugin that use to do it for them. The current working HTML5 standard doesn’t explicitly define a video format to be used with the tag—and as luck would have it, there are now two formats vying for the job.
• Ogg Theora is a free codec standard—free as in open source—which most browsers that support HTML5 video support right now. It’s an attractive option on paper, because browser companies don’t have to pay any licensing fees to include the ability to decode it in their software. The trouble is, it’s notoriously inefficient, and, perhaps because of this, it’s not too popular. Google’s standards guru Chris DiBona infamously said:
If [YouTube] were to switch to Theora and maintain even a semblance of the current quality, it would take up most available bandwidth across the internet.
True or not, as a codec standard Ogg Theora isn’t gonna cut it, even though from a business point of view, it’s ideal.
• h.264 video suffers from pretty much the opposite situation. Based on a codec standard that’s natively supported in many mobile phones, it’s what Vimeo and YouTube are running in their respective experiments. These video sites’ already store their mobile-quality libraries in h.264—what do you think streams to your iPhone YouTube app, since Flash isn’t supported? So enabling h.264 streaming is as simple as developing a player interface, which takes no time and even less resources. It’s also efficient—that’s why it’s popular in the first place. One problem though: It’s proprietary.
Yes, if you want to build a browser that plays back h.264-based video with HTML5, you need to be prepared to pay millions of dollars to the companies that own the format’s patents. Beyond the basic cost issue, some deem it risky to put the internet’s entire video ecosystem into the hands of some obscure rightsholders, whose whims could change down the road. (Who, exactly? These guys!)
Google and Apple have so far been okay with the royalties, but Mozilla, creator of Firefox, is taking a more conservative longview. As Mozilla’s Chris Blizzard insists, there’s a precedent for these worries:
Because it’s still early in H.264’s lifespan it’s extremely advantageous to lightly enforce the patents in the patent pool. MP3 and GIF both prove that if you allow liberal licensing early in a technology’s lifespan, network effects create much more value down the road when you can change licenses to capture value created by delivering images and data in those formats. Basically wait for everyone to start using it and then make everyone pay down the road.
So, while h.264 is a shoo-in for the job, it would probably be unbelievably perilous to sign it up.
If this seems like a lot to digest, don’t worry! Despite the thousands of urgent words spilled on this subject, it doesn’t really matter. Flash is here for a while, because nobody can get their act together.
First let’s talk about DRM, a sore subject, but something you can’t not talk about. Flash video supports it. HTML5 video doesn’t, as it stands. Could you imagine a Hulu on which every video is a right-click away from saving to your computer? A Netflix where you keep what you stream? I mean, sure, you can imagine this, but there’s not enough Tums in Los Angeles for Hollywood execs to stomach that discussion. No DRM, no movies or TV shows. Simple as that. And if the fight over a basic HTML5 video standard is fraught, just imagine how tough it’d be to get Mozilla, Apple, Google, Opera and Microsoft to agree on DRM.
Meanwhile, the test runs show, in reality, how little weight is being thrown behind HTML5 video at the moment. This is how YouTube describes their HTML5 initiative, which caused such a fuss last week:
In the last year our community has made it clear that they want YouTube to do more with HTML5. To meet this demand we recently rolled out HTML5 support in TestTube, a destination on YouTube where we routinely experiment with different products. Some of the products in TestTube are successful and rolled out to the wider community. Others, however don’t make it beyond TestTube. We’re still in the early stages, but our hope is to continue this active and ongoing discussion around emerging Web standards.
Can you feel the enthusiasm? YouTube’s HTML5 test is just that, a test. There’s no convincing evidence of idealistic shift in the works. YouTube’s future hinges on the ability to integrate ads into their videos, to sell access to DRM’d content, and to reach the largest audience possible. Until HTML5 video can pull this off, Google and YouTube are going to keep on doing what they’ve been doing—using Flash.
Lastly, Adobe has interests in this discussion too, and is working frantically to push Flash to virtually all mobile smartphone platforms that don’t already have it. Meanwhile HTML video tag support on smartphones is barely the discussion phases—it’s plagued with as many problems, if not more, than desktop HTML 5 video.
And we haven’t even talked about the other holes in the HTML5 Murders Flash! narrative. What about the spec’s glaring lack of ability to replace Flash’s other, non-video functions? Sure, increasing browser support for scaled vector graphics and HTML5’s Canvas tag go a short way to creating vivid, visual web applications without plugins, as does the wide array of Javascript tools already available to web developers.
But what about games? And more importantly for developers who like paychecks, what about animated, interactive ads (some which are overlaid on the aforementioned YouTube videos)? The internet’s not going to give up on those anytime soon, and the non-Flash web technologies we have now aren’t going to cut it for years.
What’s Really Going to Happen to Your Internet
As I said way back at the beginning, part of the job of an HTML spec is to codify what’s already being done by developers and browser makers. As such, there’s a very good chance that HTML5 is partially supported by your desktop browser. If you have a smartphone with a WebKit-based browser, you already use web apps that leverage the technology. This will simply become more common, in a mundane, linear way: Google, Apple, WebKit, Mozilla, Opera, and yes, even Microsoft will continue to include new features in their software, and developers will begin to leverage it as soon as they can. Web apps will get smarter, faster and more powerful, even if you don’t really notice it. You’ll worry less about having a constant internet connection, and you’ll probably install few native applications on your phone or laptop.
For the foreseeable future, video on the internet is going to remain almost exactly as-is. If anything, Flash will become more entrenched in the short term, as the YouTubes and Hulus of the world expand their catalogs with more DRM’d content, and continue building their desktop content platforms around the plugin. As for mobile devices like the iPhone and iPad, for whom Flash seems eternally out of reach, video delivery will move increasingly toward apps, which content companies can tightly control, and not toward HTML5 video, which—all other problems aside—they really can’t.
HTML5 has a place in online video, and I expect companies to continue testing it, playing with it, and expanding their uses for it. I expect browsers to continue increasing support for it—hey, maybe even mobile Safari!—but don’t stake your hopes, or a specific gadget purchase, on its immediate promise. An internet where native web languages have killed all plugins, including Flash, is just too far away to talk about coherently.
HTML5 is infiltrating the web, not tearing it down and building it back up. Like the standard itself, the HTML5 web will evolve slowly, with web technologies gradually supplanting tools you use now. You’ll notice it, but you’ll have to watch closely.
Hat tip to Lifehacker, for noticing—and explaining—the groundswell all the way back in December
Still something you wanna know? Does some other tech term have your fleshy processing unit in a tangle? Send questions, tips, addenda or complaints to tips@gizmodo.com, with “Giz Explains” in the subject line
thechromesource | 
ARMdevices.net | Email this | Comments
All in all, the experience is solid and fluid, mimicking an iPhone app as best as possible on a web interface. If we had any gripes, it would be that when you’re texting someone from your contacts list, it only grabs the phone number and doesn’t display the name after it. Also, that you can’t text multiple recipients. But calling from your contact list is fluid and takes only one more step than regular dialing from your iPhone.
