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.
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.
HTML5 myths
It’s true that HTML5 ushers in some significant changes and brings capabilities to Web applications that will forever change the world of development. However, with every new major technological shift, myths often become intertwined with reality, creating a distorted view of HTML5 in many people’s eyes.
While misconceptions around this new standard abound, here are just five of the most common HTML5 myths I’ve noticed in the business world today:
1. HTML5 is one big thing. Some of the most common questions surrounding HTML5 share a single, flawed assumption. For example, what do each of these questions have in common?
• Do you support HTML5?
• Are your applications HTML5 compatible?
• How can I use HTML5 today if some browsers don’t support it?
Each of those questions stem from the myth that HTML5 is one big thing. It’s viewed like a software package, one that must be installed in order to use. This is false. Unlike a new piece of software or technology, HTML5 is not one big thing. Rather, it’s a collection of features. Together, that collection of new features is known as “HTML5.”
What does that mean for you? That means that despite the fact that HTML5 isn’t the official “standard” until mid-2014, you can start using HTML5 features today. It’s not a question of “HTML5 compatibility” or whether or not applications “support HTML5.” You don’t have to wait until every browser offers full support. If you have Web applications, you can use HTML5 features right now.
Now, will all HTML5 features work with every browser? No, but browser support grows with each passing day. To get a better understanding of which browsers support which features, I recommend visiting caniuse.com. It lists HTML5, CSS3 and JavaScript features and browser support for each one.
2. You must convert your existing Web apps to HTML5. Whenever new technology comes around, the same question arises: “Do we need to replace our current technology?” HTML5 is no different. Common questions surrounding HTML5 include:
• What happens to our non-HTML5 apps?
• Can we convert our current Web applications to HTML5?
• Do we need to replace our current applications?
As explained in the previous section, HTML5 isn’t one big thing. It’s the latest iteration of HTML. There’s no need to replace your current applications. You may add HTML5 features to your existing Web applications without worrying about any conversion process.
That being said, there is one thing you should do to your current Web applications: Change the doctype. In the past, HTML offered multiple doctypes, each one long and confusing. For instance, here’s an example of the “strict” doctype found in HTML 4:
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/HTML4/strict.dtd”>
Here’s an example of a loose HTML 4 doctype:
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/HTML4/loose.dtd”>
Here’s an example of a strict XHTML doctype:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
Those are just a few examples of past doctypes, but there are more—each one equally lengthy. HTML5 simplifies the mess, replacing all doctype tags with this:
<!DOCTYPE html>
“Converting” your current applications to HTML5 requires nothing more than replacing the current doctype with the new HTML5 doctype listed above.
What does changing the doctype do for your Web applications? It ensures that they validate as HTML5, and helps your HTML5 Web applications behave (relatively) consistent across browsers. 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.
(An interview with Michael Smith on HTML5)
3. HTML5 makes Web apps look native across all devices. Does HTML5 make Web applications look native across all devices? Will they automatically adapt the application depending on the user’s device? No and no. Yet, this is one of the most common myths of HTML5.
While HTML5 provides some nice features for use in mobile Web applications, it’s in no way responsible for applications adapting to the user’s device. A Web application built with HTML5 features will look no different than an HTML 4 application, and will certainly not automatically appear native across all devices and screens.
What is responsible for that?
That task falls squarely on the shoulders of Cascading Style Sheets. CSS controls the look and feel of the application, and lets developers create applications that adapt to different devices.
Without getting too technical, let’s quickly examine the methods used to create applications that adapt to differing screen sizes and devices. Currently, we find two popular approaches:
Responsive Design: Using the CSS3 “media queries” feature, the developer creates different sets of styles for varying screen dimensions and resolutions. The application identifies the user’s device dimensions and pulls the appropriate styles.
Adaptive Design: Adaptive design employs the use of multiple HTML files for different devices. Server-side logic identifies the user’s device and displays the appropriate file. For example, a typical adaptive Web application includes three separate HTML files: one for smartphones, one for tablets, and one for PCs/laptops.
Each approach delivers similar results, and comes with its own set of pros and cons. For instance, responsive design is often the best approach for informational websites and apps. Adaptive design is often better suited for data-driven apps that require more control over the HTML. The most important point: Both of these approaches are driven by CSS, not HTML5.
4. HTML5 automatically delivers offline access (or other features). HTML5 includes some great features, like offline access, geolocation, local storage, plug-in-free video/audio, and more. It’s safe to say that HTML5 offers more powerful features than any previous iteration of HTML.
But does HTML5 automatically deliver all of these features the moment you change your doctype? For instance, if I create an “HTML5 app,” will it automatically work offline or track my whereabouts using geolocation?
No.
Sure, HTML5 supports those features, but an “HTML5 application” does not magically provide offline access, geolocation, or any other of HTML5’s extensive features. For example, including geolocation in your Web application requires a fair bit of JavaScript. Building an application that still functions offline requires a cache manifest file and a good amount of configuration.
The very fact that developers can now include those features in their Web applications is amazing. But don’t assume HTML5 is a turnkey solution. Creating an “HTML5 app” is no different than creating an “HTML 4 app” unless you physically add the HTML5 features.
5. HTML5 app = Mobile Web app. Maybe I’m just arguing semantics here, but the term “HTML5 app” has become a catchall phrase for mobile Web apps. In the last year, I’ve see countless articles focused on the “HTML5 vs. native app” debate.
The only problem: It doesn’t make much sense. Despite what you might hear on the Internet, HTML5 is not synonymous with mobile Web apps.
To understand why, let’s first answer this question: What is an HTML5 app? That question is not as simple as it seems.
For instance, is an HTML5 app one that looks like a native app on a mobile device? I wouldn’t say that. You could build a mobile Web app that appears native on mobile devices using HTML 4.
Is an HTML5 app just a Web app with HTML5 features? I wouldn’t say that either. You could create a Web application incorporating HTML5 features that doesn’t work well on mobile devices.
Is it a Web app with an HTML5 doctype? You could say that, but—as mentioned above—simply changing the doctype won’t automatically deliver HTML5 features.
The truth is, finding a suitable definition for the term “HTML5 app” is no easy task. After all, what is commonly referred to as an “HTML5 app” is really a combination of HTML, CSS, JavaScript, and often a back-end programming language like Java or PHP. Why not refer to it as a CSS app or a Java app? After all, those are aspects of the application too.
I know: The term “HTML5 app” has caught on around the Web, but it’s always confounded me. Doesn’t it make more sense to refer to it as a “mobile Web app?”
