HTML5: Myths and misconceptions

As HTML5 becomes more popular nowadays, the misinformation about this new standard grows. The problem is that everyone wants HTML5, but they’re not quite sure, exactly what it is. Some view it as the answer to mobile apps. Some others think that they need to convert their applications to it. So how can we separate the myths from reality? While working for a software company, we see HTML5 misconceptions nearly each and every day. So let us see some of the most common of these misconceptions, and explain why they are false. Hopefully, this article will give a clear picture of HTML5, and give us a better understanding of how it can improve our Web applications. But first, before we go through the myths surrounding HTML5, let us just quickly explore its history to give you a better idea of what it is and where it came from. A brief history of HTML5 After publishing HTML 4.0 in 1997, the World Wide Web Consortium (W3C) discontinued work on HTML, with the belief that further extending HTML would be difficult. Instead, in the year 1999, the organization started working on XHTML, a new language that combined HTML with XML.   Unhappy with the direction HTML was taking, a small group of developers at Opera and Mozilla proposed a different vision for the Web at a W3C workshop in the year June 2004. They believed Web applications were not being adequately and properly served by existing technologies, and outlined seven design principles that they viewed as critical to the future of the Web industry: 1. Backward compatibility and a clear migration path: Web applications should always be based on technologies that developers are familiar with. Any solution that does not offer a clear migration path, or requires the use of binary plug-ins, will be absolutely unsuccessful. 2. Well-defined error handling: Error handling must be clear and consistent across various browsers and user agents. 3. Users should not be exposed to authoring errors: Error recovery behavior must be clearly defined for each and every scenario, and error handling should allow for graceful error recovery. 4. Practical use: New features must be well justified by practical use cases and based on real sites where developers previously used workarounds to bypass the limitation. 5. Scripting is here to stay: Scripting should be device- and presentation-neutral, but should be avoided where more convenient declarative markup can be used effectively. 6. Device-specific profiling should be avoided: Desktop and mobile versions of the same browser should implement the same features in al versions. 7. Open process: Web applications will be core to the Web, and development should take place in the open and should continuously be visible to the public as well. In a vote following this presentation, the W3C rejected the proposal, choosing instead to continue working on XHTML. However, rather than abandon their goal, Opera and Mozilla (later joined by Apple) formed the Web Hypertext Application Technology Working Group (WHATWG) to work on creating their vision for the future of HTML.