She also explained that the process of figuring out what to change for HTML5 involved finding the common things that were being done with HTML4 and seek to make those easier and better. This is meant to clear the hacks out of the system and lend itself to higher productivity, since it minimizes the time that Web developers have to spend working around weaknesses in the old system.

Finally, Rewis emphasized the introduction of error handling into HTML5 as a huge benefit. Error handling is of course the key to robust systems and by extension to developing quality systems.

In May of this year, the HTML5 specification entered the Last Call phase, pointing to 2014 as the timeframe for final Recommendation for the standard. There is, though, no need to wait that long to make things happen by solving problems with HTML5.
Why HTML5 matters
There is no longer a single operating platform to rule them all, and in truth, it has been a very long time since there has been one. As Mac machines and Linux-based PCs gained popularity, the Web offered a safe middle ground that helped developers, and the companies that paid them, avoid the tradeoff of single-client support versus building the same application multiple times. The downside, though, was that Web applications have historically meant sacrifices in functionality and difficulty in development relative to native applications.

As more and more organizations are facing the need to have their internal applications support Android, iOS and Windows, something has to give or something has to go unsupported. Many are hailing the greater functionality provided by HTML5 as the potential solution. The logic goes that better, easier-to-develop Web applications done with HTML5 and JavaScript will deliver the best of both worlds.

A word of caution here: We have heard these promises before, and not that long ago. The promise of rich Internet applications sounded a lot like this same story, but in that case the engine behind the promise was always a plug-in, such as Silverlight or Flash. But as vendors like Apple disallow plug-ins on their systems, this becomes an unworkable strategy. Even Microsoft appears poised to have Windows 8 not support plug-ins within the Metro version of the IE10 browser.

One application developed that works well on all platforms would be great, but there are still major things that Web applications cannot accomplish. This means that while HTML5 will help prevent developers from having to create multiple versions of their Web applications, there is still room for native applications. As we will see, the work done in HTML5 can be useful there as well.

What changes with HTML5
HTML5 has already been designed, and it really is less a work in progress than a specification going through its final phase. A major goal of HTML5 has been to better enable what people are already doing on Web pages. Accepting that the greater goal is to facilitate better Web application development, there are several areas where this can be realized. Most obviously, it introduces a slew of new elements, including those that are getting a lot of attention (like the canvas and video elements) to others that are more mundane, such as the figcaption or article elements.

The W3C provides a great resource for seeing exactly those elements that have changed or been added. For example, one of the most common tags there is, the anchor tag, has had the target attribute un-deprecated because it has proven useful in Web applications. The anchor element has also seen the addition of the Media attribute.

This evolutionary process is like taking phrases that are common in regular speech and developing shortcuts for them as we see done all the time in texting. If you are familiar with the meaning and use of the term LOL, then you should appreciate how these evolutions can help. The problem is that change is painful for people, and the bigger the change the greater the leap required.