Although HTML 5 is still a draft specification, it's impact is being felt across the technology landscape as this is written. In creating a new standard, the W3C was mindful of the latest developments in applied web application technologies, such as the growing popularity of media-rich Web sites over static brochure-ware, and innovations like AJAX.  I say applied because one of the key drivers behind the new specification was the understanding that the last decade or so of web development can be summed up as "forcing browsers to provide an experience they were never intended to," as I often mention to my colleagues. Anyone who has worked as a web developer can sympathize with the amount of hacks, workarounds and plugins needed to deliver a modern, interactive experience. And that's just within a single browser, let alone making your site cross platform. Hopefully, HTML 5 can begin to address this quagmire by making the underlying markup both relevant and applicable to what the web is actually used for these days. I won't go into detail with regard to the specification and it's potential,  but instead focus on how it will change the game specifically for the CMS software industry. So how will this impact authors, administrators, contributors on the web? Let's dive into the features and see how. Clearer separation of navigation, header and footer elements With the new elements types for navigation items and such, you'll not be surprised that browser safe, standardised and design-agnostic navigation can be provided out of the box in CMS. With standards around the underlying HTML of the navigation, CMS vendors can reliably provide more advanced site creation, navigation management wizards without having to worry about supporting the top 15 AJAX libraries and approaches out there. This portability can be achieved today with good effect using CSS and List elements, but these new elements should also help put to rest the debate about what type of navigation model to use and perhaps more importantly, provide the syntactic sugar to help search engines understand your site structure that much easier; for example, without the need to generate an XML sitemap. Local storage database Arguably the most obvious benefit to software vendors of all types is the local storage facility. No longer do we have to worry about flaky connections and long-workflow-abandonment. With local storage comes the promise of authoring web pages while on your flight to Texas, replying to blog posts in the train tunnel and a slew of other offline scenarios. Immediately, the mobile application development realm becomes far more interesting as offline caches can be stored in the device for interrogation when not connected, and in general, a faster experience when checking the local cache for your documents, as opposed to constantly "pulling" from the web server.  Long, multi-step online business processes won't be abandoned as often when users realise they can pick up right where they left off. Essentially, web apps will behave much more like desktop applications in their statefulness. I expect the memory allocation for each domain to be increased quite quickly, as pressure from vendors to store local caches of binary documents and other rich media will quickly surpass the 5MB suggested limit. Flash, Silverlight and Applets, oh my! The impact of web sockets, or the ability of web pages themselves to call and respond data sources, based on the socket pattern. If that sentence just flew right over your head, think about chat or instant messaging applications. They have traditionally been implemented in Flash or other RIAs du to the in built capabilities of the 3rd party plugin to supply the infrastructure. Although corporations like Facebook and Google have overcome this with their COMET based chat clients at significant development cost; this new infrastructure provided in the specification, could level the playing field for everyone else that is not as fortunate. "Essentially, what it does is lays the groundwork to have equivalent functionality that Flash or Silverlight provides," says RedMonk analyst Michael Cote. With the addition of new elements or tags for video and audio, the specification is pointed squarely at vendors like Adobe and Microsoft in an attempt to swing the balance back in favor of Google, who employ's HTML 5 lead editor Ian Hickson open standards. What does this mean for CMS software as we know it? For one, vendors will have an option outside of siding with Adobe or Microsoft, avoiding allegiance and licensing headaches when it comes to picking a video player of choice. Outside of the media player debate, CMS vendors can hope to bring a level of control and configuration not found in RIAs today. Most CMS struggle with anything besides supplying a basic XML file for Flash objects to ingest. That's about as far as they go today. With the new specification opening up the breathing room a bit, we could see a standardised approach to feeding parameters, content and even deploying objects within the RIA. CMS are great when it comes to deployment, rollback and versioning of code, and up until now, CMS functionality has been for the most part shut out of the equation because it had to hard stop at the executable level: the .SWF file. It was impenetrable. Now, CMS vendors can perhaps go deeper into the actual DNA of the RIA and allow authors to probe, create and adjust the contents and interactions just as richly as pure HTML or any other text markup. As with most trends, we'll have to watch for the final evolving uptake and following impact of these new standards. If the mind-bending Jedi tricks AJAX developers have crammed into ailing browsers is any indication of the future, we're sure to see many uses no one can anticipate right now. What are some ways in which you think the popular CMS platforms will be affected by the coming of HTML 5?