After Hours

10 things you should know about HTML5

HTML5 may not be a fully finalized standard yet, but it isn't changing much -- and adoption is on the rise. Justin James highlights the key aspects of the new specification.

A year or two ago, HTML5 seemed like a vague idea that only a few Internet wonks cared about. Now, it feels like HTML5 is everywhere. Thanks to rapid releases from Mozilla and Chrome, and the deployment of IE9 from Microsoft (and IE10 already in "tech preview" status), browser support for HTML5 is available to nearly everyone in a limited (or better than limited) amount. Developers are starting to take advantage of the widely implemented features. With full HTML5 support probably less than a year away, and the specification quickly reaching an unchanging state, this is a great time to look at some things you should know about HTML5.

1: XHTML is no more; long live HTML5 with XML syntax

XHTML was the choice of people who favored precision, particularly for parsing. HTML has always looked a lot like XML, but it never was quite exactly like XML, and as a result, trying to parse it like XML would fail. So a while ago, the XHTML spec was made, to take the HTML language and put it into the XML lingo. When HTML5 first got started, there was work on XHTML 2 as well, but that was eventually mothballed. Instead, the HTML5 spec is written so that you can write HTML5 with strict XML syntax and it will work. And if you send it with an XML MIME type, user agents will parse it as an XML document too. This gives developers the best of both worlds.

2: The 2022 myth, the 2011 reality

One of the persistent misconceptions around HTML5 is that "it won't be done until 2022." The typical supporting evidence for this is an interview I conducted with Ian Hickson, the HTML5 specification editor, a few years ago. Ironically enough, even in that interview, he was clear about the 2022 date. But a few people got really worked up about it, and their angry articles got a lot more attention than the actual facts.

The truth is that 2022 is when Hickson expects the HTML5 spec to become a full W3C recommendation, which means that there are two 100% complete, verifiable implementations. To get an idea of why that is both fairly meaningless and a huge leap at the same time, consider that no other version of the HTML spec has ever achieved that status, mainly because they were too vague for any implementation to be provably correct. The HTML5 specification is getting close to being solidified and unchanging, right now in 2011.

3: It is a Flash and Silverlight killer for many developers

While HTML5 does make numerous improvements in how it is used for marking up documents, the big focus is in applications. The number of features that HTML5 introduces to support application development is staggering. This isn't to say that Flash and Silverlight are going away anytime soon. But Microsoft has already announced that it's refocusing Silverlight on the out-of-browser experience. Flash and Silverlight still have capabilities that HTML5 does not have, but the gap is nonexistent for many common purposes now, thanks to HTML5's new capabilities. It probably isn't worth rewriting existing applications, but you should see whether HTML5 makes sense for new applications.

4: It is the basis of many new tools

With HTML5 becoming a full-blown application framework, toolmakers are now using it as the foundation technology for their products, particularly those designed to overcome cross-platform development issues. If you are looking to write an application that runs cross platform, and it is within the capabilities of an HTML5 application, you should consider one of these tools. This is especially important in the mobile space, where the alternative is to learn an entirely different language, API, and framework for each phone platform you want to target.

5: The <video> tag is important but controversial

My personal pick for "best new HTML5 feature" is the <video> tag. Before <video> (there is also an <audio> tag), you would find yourself having to turn to Flash or Silverlight to provide a media player on your site. With these new tags, those days are, in theory, over. Why only "in theory"? Sadly, the different browser makers can't quite decide on which formats to support yet, due to patent concerns. When the dust settles on that, Flash and Silverlight both lose their #1 use case.

6: Google led the way

If it seems like the Chrome browser has a huge head start with HTML5, there is a good reason for that. The HTML5 specification process put a heavy premium and emphasis on written, deployed code. I'm not saying that they "rubber stamped" whatever browser vendors did. But it was hard to convince those involved to write specifications for unimplemented features, and implemented features were likely to become the basis of new items in the specification. Because Chrome seems to have a new version every few weeks, features that Google put into it had an excellent chance of making it into the HTML5 spec.

7: "Standards compliant" is finally provable

Whenever someone claims that a browser is or is not "standards compliant," I have got to laugh. Before HTML5, it is literally impossible to be provably standards compliant. In many cases, the current specs are too vague or simply silent on important issues (like handling parsing errors) and the result is that different browsers can do wildly different things and still be either standards compliant or fall into the category of "not provably out of compliance." Even the famous ACID test does not prove too much, since it tests only a subset of the HTML specification. With HTML5, the bar has been raised quite a bit, and it will finally be possible to prove that a user agent is standards compliant. Indeed, one of the reasons behind the 2022 date for "recommendation" status is the need to write full test suites.

8: "Standards compliant" still does not guarantee how it will look

Standards compliance in Web browsers does not do what people often think it does, and HTML5 does not change that fact. A big confusion with HTML is that many Web designers and developers believe that the HTML specification controls the look of items on the screen; it does not. For example, a Web browser can make the <strong> tag use a bigger or different colored font instead of a heavier font, if it likes and still be compliant. Many times, when designers say a browser is not standards compliant, what they are really encountering is the flexibility given to user agents in how to render tags. HTML5 does not change this fact. If you absolutely need a tag to be rendered in a precise way, do not count on the browser's default behavior; specify your needs in CSS.

9: Parsing is more precise

The HTML5 specification finally introduces precise parsing rules and defines things like what the user agent should do when it encounters a parsing error. As a result, you can expect that some things that used to pass as acceptable or even "valid" HTML in the past will no longer cut the mustard. You will want to get familiar with HTML5's parsing rules and make sure that your code adheres to them.

10: HTML5 goes far beyond the browser

In previous versions of HTML, there was an inherent assumption that a traditional Web browser was the user agent of choice. While other user agents and content types were supported, there was an implication that they were not as important. HTML5, on the other hand, has a good number of changes to put non-browser, non-desktop-size-screen user agents on more equal footing with traditional Web browsers. There have been a lot of advances with things like how well it works with screen readers and mobile phones. As a result, well-written HTML5 can be a "write-once, view anywhere" framework for developers who need it, and it can reach users (particularly those with a variety of disabilities) who otherwise would struggle with the Web.

Additional HTML5 reading

About

Justin James is the Lead Architect for Conigent.

33 comments
ed
ed

Regulatory requirements at a time when Banks have already outsourced all intelligent roles within their organizations. None of the outsourced consultants or partners need to focus because they have little or no liability. This is a ticking time bomb. Banks are laying off the few assets they hadwho had time to focus on it and are now flying blind.

blarman
blarman

For the author: There is a typo in the following sentence: "To get an idea of why that is both fairly meaningless and a huge leap at the same time, consider that no other version of the HTML spec has __every__ achieved that status, mainly because they were too vague for any implementation to be provably correct." "every" should be "ever". Good article, though.

pgit
pgit

Some good to know info to stash in the back of the head. It might come in handy knowing the parsing is more strict and might produce more errors, which we'll begin to see with wider deployment. One of those "why the heck is this happening?!" moments some day in the future and I'll remember this... On thing that seems to be indicated by the article is that CSS on the user end is going to be more important. Let's hope someone makes a user-friendly add-on for this. The style sheet tools I see are not the kind of thing I'd want to show a typical end user, whom the last thing on earth they'd want to do is edit html code.

TechRepublic
TechRepublic

J. Ja - jump in here... I have heard a lot of talk about HTML5 and its implications in and out of the browser, but MS has been exceptionally tight-lipped about a roadmap to implementation of the standard in and out of the browser. There have been a lot of us waiting for SilverLight to mature into a reasonable stable product before giving it a serious look as a presentation platform that we want to spend the time learning. Combine this with the learning curve involved with WPF (and its current uncertainty as an ongoing focus of MS's offerings) and there are a lot of Windows developers waiting on a real believable development roadmap for VS users and the Windows platform in general. There has been little dribs and drabs coming out about Win8 and out-of-browser HTML5, but nothing that sounds like a vision. I don't know about everyone else here, but I just don't have the time or the patience to learn a platform that MS is not going to support for the long term. If that means my apps look bland because I am the last guy using WinForms for my internal business apps, so be it. MS needs to get its [stuff] together in this regard. When Jobs gets on stage and tells you 'one more thing', you know that is really the direction the company is going and you need to get on board. When Ballmer gets on stage and waves around a new piece of tech (HP Tablet, Azure, Kin, Origami, Vista, Groove, WinME, Bob....) you have no idea whether or not this the new 'all in' thrust of the company, or just what was on his mind over breakfast this morning. MS - pick a technology, create a roadmap, design your products to exploit it, and get on with it already...

Vitality01
Vitality01

Did some one say Flash will become reduntant? ...did Apple see this coming? Maybe that fight is near over...

JulesLt3
JulesLt3

Some good myth-busting there. Only thing I'd disagree on is Google leading the way, as it ignores the years of work done by Mozilla, Opera and Apple with the WHATWG, which defined and implemented about 75% of what became HTML5, but most importantly proved that rival browsers could produce compatible standard implementations, while competing on speed and features instead. Which isn't to dismiss Google's contribution - they've done more than all the others to get the idea of HTML5 out there with the public. As for the bank insisting on IE6, that's a declining case. Even my wife's employer - a lagard government department whose internal applications have never been migrated off IE6, has installed Firefox so that staff can access the outside world - which seems an amazingly sensible policy towards dealing with the IE6 legacy. So sensible, I'm surprised it was allowed. What is driving that is the increasing number of sites out there that are ditching IE6 support - we don't do it any more, as it's reached the same 'too small to care' list as Mac users . . .

me
me

"With full HTML5 support probably less than a year away" - this is quite a comical statement for me. I have been building a visual learning enviorment for a bank. One of the requirements is it MUST be IE6 ready because it would be too much time and effort for them to update their browsers.

TheWerewolf
TheWerewolf

And that's native interfaces. Even Java, which fought hard to avoid it, had to add it. It's the main reason .Net was created - because Java was missing it at the time and Sun refused to consider adding it. Each OS has a rich set of internal features that people want to use. HTML5, by definition, has to be a small subset of those features. That sets the upper limit on what you can do. If you have an application that's relatively simple, doesn't have complex DB needs or file system needs and can live with having an external server of some kind (or you don't mind having a miniserver on your system) and the entire connectivity mess that brings, then HTML5 will be fine. Unfortunately, there are lots of cases where this isn't good enough. Me, I'll stick to smartclients written in .Net, thanks. There's nothing HTML5 brings to the table that makes me want to use it. 92% of my market is Windows users - crossplatform is nice, but hardly a major issue for me and products like Mono for Android and Mono for iOS fill in the missing bits nicely.

Andre Richards
Andre Richards

"6: Google led the way. If it seems like the Chrome browser has a huge head start with HTML5, there is a good reason for that." Correct me if I'm wrong, but I was under the impression that Google's Chrome browser was powered by Webkit, Apple's open source HTML rendering library. Wouldn't it be more accurate to say, then, that Apple led the way? (And yeah, I know that's one of those comments that will bring out the haters, but credit where it due, right?)

LordInsidious
LordInsidious

I think the biggest reason HTML5 will be taking a back seat to Flash and SilverLight for a long, long time (2014) is the canvas tag. is important but pales in comparison to having to re-code dynamic events like mouseover for objects defined dynamically in JS and the canvas tag.

Spitfire_Sysop
Spitfire_Sysop

I have been working on converting a couple of small websites to HTML5 and I am finding that it's better in all directions. I am ending up with smaller files that are easier to read. It makes sense out of some things that always seemed strange to me. How refreshing.

Justin James
Justin James

I don't think Microsoft has been quite as "tight lipped" as it seems. Microsoft is working hard to implement HTML5 in IE. IE9 has a fair amount of HTML5 in it, and they are working closely with W3C in the development (especially on the test suites). Because Microsoft is sticking to a more traditional, fewer releases schedule, it seems like they are lagging. They've responded by moving from one IE release every few years, to one per year. If that seems slow, consider the chaos that Mozilla is creating by moving to one release every 6 weeks, breaking extensions left and right and making it hard for enterprises to use it as their standard browser. IE10 is already in a "preview" so it is definitely available if you want to get an idea of what HTML5 in it will look like. The "Mango" update for WP7 brings the full IE9 browser into the phones, so HTML5, as supported by IE9, is now supported on WP7. In addition, apps can now host the browser, so it is easy to make an app that's just a viewport to an HTML5 app. This funky out-of-browser thing that they are doing with HTML5 in Windows 8, they are delivering that information at the BUILD event, which is in late August or September, if memory serves. We'll know more details then. My personal stand? Silverlight is more capable than HTML5+CSS+JS, particularly around things like graphics processing, multithreading/parallel processing, access to hardware, etc *If your application needs these*, then Silverlight is the better choice for a cross platform, out-of-browser (and maybe even in-browser) experience. If you don't need these capabilities (ie: typical data driven apps), I'd be using HTML5. Indeed, that's essentially Microsoft's stance as well. With WP7 now getting HTML5 capabilities, I'd bet that's soon going to be the party line on WP7. They've openly said it about Silverlight in the browser, and my guess is that they'll say the same about Silverlight on the desktop at BUILD. In fact, I wouldn't be surprised to see Silverlight essentially phased out in favor of the full WPF stack on desktop too, and relegated to being "WPF Light" for WP7-only. J.Ja

TechRepublic
TechRepublic

I heard Apple make a lot of arguments against Flash - It crashes our magical OS, it drains the batteries and resources from our revolutionary products, they don't wear black turtlenecks at Adobe, etc. I haven't really heard Apple use the "we would rather use open, standards based technologies" approach against Flash. The Apple/Flash fight is completely one sided: It was over the moment Apple decided it would not support Flash.

Justin James
Justin James

I spent a number of years on the HTML5 Working Group in W3C, but I haven't spent any time around WHATWG, so I really don't know much about the history there. I do know that Ian Hickson participates in both, and I know that WHATWG was around a long time before H5WG, which was more like W3C coming in on full panic mode trying to get a handle on the spec that had been brewing outside of their control. What I saw in H5WG, though, is that at least within that body, Google's work carries an outsized amount of weight, as a combination of it having a lot of visibility with Hickson, their release schedule, and the "we favor working code" approach to the spec. With them releasing every 6 weeks I think, compared to Firefox (until a few months ago) and IE being much slower, preferring working/released code basically guaranteed that what Google did on their own would drive the spec. J.Ja

bornbyforce
bornbyforce

Let's set all the arguments about standard compliance and browser wars aside. Even Microsoft doesn't really consider IE6 a secure web browsing option anymore. Your employer is asking for disaster.

admin
admin

Any bank still running IE6 internally or writing their customer-facing sites to IE6 would immediately lose my business if I learned of it. Such a bank is a ticking time bomb, just begging to be breached or hacked, since they clearly view data security as an inconvenience or an afterthought, rather than a priority and a necessity of doing business and upholding customer trust.

jcw002
jcw002

Stay in your armchair and get left behind. This place is changing with you or without.

canweriotnow
canweriotnow

Sure, we're not going to see native interfaces become part of the HTML5 standard. But it's also not something we should expect. The W3C is big into separation of concerns, which is why we have HTML, CSS, and JavaScript for controlling structure, presentation, and behavior, respectively. If you want to run native code on the client, there are things out there like Google's NaCl (http://code.google.com/p/nativeclient/) are making it possible. Secondly, on Android, for instance, you can create an app almost entirely in HTML5/CSS/JS, and execute "native" (Java) code from within the app via a JavaScriptInterface(). In addition (though I haven't used it yet), IIRC you can grant add'l permissions/allow local execution for apps in the Chrome Web Store. So I really don't think it's that big of a deal. Native interfaces have no place in the HTML5 standard, but most good APIs for building HTML5 apps are going to have an implementation method for that sort of functionality. Already HTML5 gives us local storage w/ SQLite, etc. So for me, it's a non-issue. YMMV.

cnoevil
cnoevil

Well... after all, html5 is hyper-text mark-up. One isn't supposed to be able to write for loops, functions, or methods with it. It's purpose is simple and straight forward - to define the content and to a degree, the structure of networked media. mark

JulesLt3
JulesLt3

I'd agree with that - it's interesting to see that when there is a true competition of interfaces (web, native, cross-platform tools like Adobe AIR) users seem to opt for native, even to access information retrieved from the web. Very few people pay to access web based apps vs the huge success of apps - that says a lot about what people like. Also, while we may be impressed at what Google Docs or 280 Slides can do, knowing the limitations of the browser, normal people just see a program that is more limited than Word. Which they already have, anyway. On the other hand, web interfaces are here to stay - no one wants to download an app just so they can deal with a business once - so having a standard that finally supports the concept of data types in forms, rather than treating everything as a string, is a big leap forward.

bornbyforce
bornbyforce

When you have something open source it means it is developed by people. And people are the ones who are leading the way. If I agree with your argument which implies the webkit being most important part of Google's HTML5 efforts, I would still need to give credit to all the companies and people who contributed to webkit and made it what it is today, not just Apple Inc who started it and legally owns it. PS. I dislike both Chrome and Safari for different reasons anyway.

Justin James
Justin James

Excellent question! Yes, Chrome uses the Webkit rendering engine, but Google came at a lot of these things from the opposite direction, their apps. For example, do you remember Google Gears, and how it then kind of disappeared? That's because they uses Gears to implement a lot of the stuff that because application support in HTML5, and when HTML5 got it, they could dump Gears. So a lot of it was in the API levels, above the rendering engine. J.Ja

mwclarke1
mwclarke1

it seems with the latest flash and browser upgrades recently many systems are experiencing all kinds for performance issues with flash. some are video driver issues but many are experiencing major CPU utilization hits and resulting in choppy video. I can no longer watch nay on-line video from home on DSL on any computer. Even on a underutilized DS3 at work, Most flash based on-line videos are an issue with high CPU utilization and choppy video recently.

canweriotnow
canweriotnow

Apple has said (in so many words) "we would rather use open, standards based technologies [than Flash]"... unfortunately, it's a load of crap.

danekan
danekan

IE6 went End of Life in 2008 and extended support only exists because XPSP3 is still in extended support mode through 2014.. older OSes it's already past end of life and no patching is being done. if they're that slow to upgrade hopefully they start now ehh

Justin James
Justin James

"Well... after all, html5 is hyper-text mark-up." That's true, but one of the stated aims of the HTML5 effort is to take HTML far past the "document markup" stage, and well into the territory of "application API". I personally am not thrilled with that, but you can't stop a tidal wave by shouting at it... J.Ja

Andre Richards
Andre Richards

Many open source projects have "owners" or companies that direct the development efforts. Webkit is an example but another would be Android and how Google maintains control over it despite it being open source. Apple does the bulk of the development work on Webkit. And since Webkit is the rendering core of the browser, it would account for a significant amount of its HTML5 compatibility.

Andre Richards
Andre Richards

I disagree with you. Internal dev tools matter not one whit to consumer adoption of a given technology. Apple, having dumped so many resources into making Webkit the premier HTML5 rendering library (the only one that passes the notorious ACID tests consistently) and open sourcing it, has done more to push the standard into people's hands than anything else out there. But regardless, your article doesn't explain any of what you just said. It just cites Chrome as proof that Google has been at the forefront. And since Chrome is powered by Webkit, that's simply a bad argument.

rengek
rengek

My 7 year old PC can run 3 flash heavy pages concurrently and never go beyond 70% CPU and I was intentionally trying to stress test it. Buy some dang memory for your computer. Your choppy video is probably due to your lack of due diligence in good codecs, drivers and players. (i.e. user error). It has next to nothing to do with flash. Stop trying to make up things to blame on flash.

Justin James
Justin James

Andre - You misunderstand my point. My point is not what's getting delivered into the hands of the users... it's what the W3C committees are looking at. Google took all of this stuff that they did, like Gears, and used it as Proof of Concept to bring to W3C, who then ratified it as spec, and then it got built into browsers. You don't see Apple doing that, because Apple doesn't do much with Web apps, let alone push the envelope so hard. J.Ja

WCarp
WCarp

Any video download can experience choppiness if there is a problem with data transfer.

Jaap Fieret
Jaap Fieret

Zou graag willen maar leef van een uitkering dus veel geld is er niet

danekan
danekan

Be it my dual core 3ghz 4GB RAM HP notebook, my macbook, my imac, or my HP dual core brand new desktop, i often experience choppyness with flash video.. particularly Youtube. The Flash player has been upgraded many times recently, introducing more codec options, namely H.264 which is very resource intensive. Though also recently in Flash, they've added hardware video acceleration capability for decoding. It's possible your 7 year old PC is so old that it's not capable of doing the latest hardware video acceleration so instead it's all being down by software, in which case for h.264 will likely mean smooth playback but at a lower frame rate. You say he isn't doing "due diligence" in choosing the proper codec, which makes no sense .... users can't choose codecs that Flash is using, a FLV file is already encoded video as some codec, it's up to the content provider to do that. The only way a user can really control it is by hacking around with a Greasemonkey script and using a third party client such as vlc, but 99% of users aren't going to do that nor should they have to. (But it has been proven that taking it out of Flash playback via this method will improve performance)