HTML5: Myths and misconceptions

Steve Hansen
January 13, 2014 —  (Page 1 of 4)
As HTML5 becomes more popular, the misinformation surrounding this new standard grows. It has become a catchall phrase for the mobile Web, and its features and capabilities are widely misunderstood.

The problem: Everyone wants HTML5, but they’re not quite sure what it is. Some view it as the answer to mobile apps. Others think they need to convert their applications to it.

How can you separate the myths from reality?

Working for a software company, we see HTML5 misconceptions nearly every day. So let’s examine some of the most common of these misconceptions, and explain why they’re false. Hopefully, this article will paint a clear picture of HTML5, and give you a better understanding of how it can improve your Web applications. But first, before we dive into the myths surrounding HTML5, let’s 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 1999, the organization started work on XHTML, a new language that combined HTML with XML.

Easter Island

Unhappy with the direction HTML was taking, a group of developers at Opera and Mozilla proposed a different vision for the Web at a W3C workshop in June 2004. They believed Web applications were not being adequately served by existing technologies, and outlined seven design principles that they viewed as critical to the future of the Web:

1. Backward compatibility and a clear migration path: Web applications should 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 likely be unsuccessful.

2. Well-defined error handling: Error handling must be clear and consistent across different browsers and user agents.

3. Users should not be exposed to authoring errors: Error recovery behavior must be clearly defined for every scenario, and error handling should allow for graceful error recovery.

4. Practical use: New features must be 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.

6. Device-specific profiling should be avoided: Desktop and mobile versions of the same browser should implement the same features.

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.

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.

(What changes have occurred in HTML5)

For more than two years, each group worked on differing specifications. The W3C worked on creating the XHTML 2 standard, while WHATWG worked on advancing HTML. In 2006, the W3C recognized that XHTML wasn’t gaining traction while WHATWG had gained serious momentum, and decided to join forces. Together, they worked to develop the specification now known as HTML5.

In January of 2008, WHATWG published the first working draft of the HTML5 specification, which outlined the changes and features included in it. Since then, browser vendors have worked to implement these features into their browsers in preparation for the standardization of HTML5.

In December of 2012, the W3C announced that HTML5 was complete, meaning all of the features had been finalized. While not officially a standard this year, most modern browsers already offer support, opening the door for the development of websites and applications that implement HTML5 features.

Related Search Term(s): HTML5

Pages 1 2 3 4 

Share this link:


01/14/2014 08:10:44 AM EST

Liked much the term "CSS app" ))) Thanks for the great article.

United StatesVahagn

01/17/2014 03:23:13 PM EST

Excellent Article, Kudos Steve Hansen. With all the marketing terms like 'Cloud Technology' and 'HTML5 Apps' rolling so easily off the tongues of developers that should know better. It is nice to see someone trying to shed some light on the subject. The reason, in my view, that there is no good way to define HTML5 app. Is that the whole notion is a misconception. Web 2.0 Apps find, at least its most noted origins, in the work by Google to approach web development with an entirely new approach. It used existing technology and standards of the day and came up with AJAX, later re-dubbed Ajax (due to its lack of dependents on XML). With Ajax we use (X)HTMLx.x and CSS and JavaScript connect to a back end using PHP, Python, or ASP etc. Typically connect to some type of Data Store (RDBM, XML flat file etc.) To make seamless 'No-Click' 'No-Refresh' web applications. Which is a huge step from the Click base web sites in use prior to this innovation. A web app can be just a part of a site or the whole site may be a series of web apps. The main confusion that I see is that new developers seam to believe that web apps only became possible with the advent of HTML5. They don't seam to understand that Web Apps predate HTML5 and HTML5 is merely a standard that can enhance and make development of web apps easier. It is not part of the standard itself. I have even seen professional authors in books falsely call Ajax a part of the HTML5 standard. No matter how we want to view it at the end of the day HTML5 is a standard (or proposed standard) that governs HTML. It is not a complete package as Marketers try to describe it as. There are many other web technologies like CSS, JavaScript, and json, XML, php etc... behind the scenes making those apps possible and no it's not all one big thing called HTML5. Thanks for the great article!

United StatesJamie R. Robillard Sr.

01/28/2014 03:29:10 PM EST

Hi Jamie, Thanks, I'm glad you liked it! I agree with you--many think that HTML5 is some great new technology that makes mobile web apps possible. They fail to realize that it's just the next iteration of HTML. I think the confusion stems from the name. We never referred to the prior HTML version as "HTML4." We simply called it "HTML." When people hear the term "HTML5", they instantly think it's some separate technology, when in reality it's simply the next iteration of HTML. -Steve

United StatesSteve Hansen

01/29/2014 01:02:05 AM EST

Steve, thanks for writing this. Lots of good info here. One correction though. You said: "For example, while some browsers support HTML5 features even without the HTML5 doctype, not every browser will. Updating the doctype minimizes the cross-browser headaches associated with a move toward HTML5." Can you please provide an example of an HTML5 feature that doesn't work if the HTML5 doctype is missing and another doctype is used instead? As it stands, I don't think that statement is true. The doctype really has nothing to do with anything you put in the page. The browser doesn't infer any meaning from the doctype other than "standards mode", which it gets from any valid doctype. You can use a valid XHTML doctype with all the HTML5 features you want and you'll have the same result. The only thing that will be different is that your pages won't validate. But validation means nothing; it's just a guide.


02/10/2014 11:59:59 AM EST

Hi Louis-- Yes, you are correct. The HTML5 doctype only puts the browser in "Standards Mode," and you could use HTML5 features without changing the doctype. However, I mentioned changing the doctype so you could avoid problems when rendering pages in older IE browsers. An older IE browser loading in "Quirks mode" won't support the HTML5 features it does in "Standards Mode." To be honest, I haven't tested the differences between using HTML5 features in older IE browsers operating in "Quirks Mode" vs. older IE browsers operating in "Standards Mode." I've just heard from others that "Quirks Mode" doesn't support everything correctly--which makes sense seeing as "Quirks Mode" essentially forces the browser to render the page as it would appear in IE5. All that to say--using the HTML5 doctype won't magically create an "HTML5 app," as some people seem to think. As you mentioned, it just forces "Standards Mode." However, using the HTML5 doctype not only lets your page validate as HTML5, it's also a precaution against older IE browsers loading in "Quirks Mode." --Steve

United StatesSteve Hansen

SD Times Blog: Developers can now charge for HTML5 Web apps in the Amazon Appstore
Amazon announced a change that allows developers to price HTML5 apps just like their native coded counterparts Read More...

News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>



Download Current Issue

Need Back Issues?

Want to subscribe?