Error getting theme layout

Is HTML5 ready for Big Enterprise?

Posted @ 10:20 pm by Grady Kuhnline | Category: Strategy, Technology, Uncategorized | 0 Comments

Recently I was looped into a discussion for one of our Fortune 100 clients regarding the use of HTML5. Given the broad usage and excitement that HTML5 has generated over the last few years, it may come as a surprise that they had some strong reservations about using it. I have found that a number of enterprise clients might have some misconceptions about HTML5, often based on outdated information. I thought I would take time to respond some of the general concerns we hear about HTML5 and why it is a mature technology ready for the enterprise.


The current draft HTML5 spec is only partially supported by the latest browsers

This is, of course, extremely misleading and completely misses the point of the HTML5 spec and how it was designed. HTML5 was designed differently than previous versions of the spec, so that partial support wasn’t such a problem. Previous versions, such as HTML4, or XHTML 1.0, took many years to ratify and implement. This was largely due to overreach on the part of the spec writers – they tried to cram every feature into one huge spec.

The monolithic spec approach caused numerous problems, namely that correcting issues with any small part of the spec became very time intensive because the entirety of the spec had to be updated at once. This slow process broke down completely with XHTML 2.0, which took many years to develop and was eventually dropped altogether. While the W3C (the standards body that controls the official HTML spec) toiled away on XHTML – ignoring backward compatibility issues – a separate standards group, the WHATWG, invented HTML5.

The WHATWG started as a collaboration between Apple, Mozilla and Opera to work on a more flexible standard that catered to the needs of browser vendors. At the time, there was intense debate about whether XHTML2 or HTML5 was the right way forward. XHTML2 was a strict standard, but it broke the web as we knew it. HTML5 was the looser standard that already had broad support in all of the major browsers – that was in 2008.

To combat the problems of a monolithic, slow-moving, perpetually outdated spec, HTML5 has been divided into numerous subcomponents that are individually versioned to allow for vendors to safely implement the finished portions of the spec faster, without needing to wait for the entire spec to be finalized. This was done specifically to allow for faster ratification by the standards bodies, faster implementation by the browser vendors and, importantly, faster adoption by developers.

The history of HTML living spec states that, “the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification rather than freezing it in a state with known problems, and adding new features as needed to evolve the platform.”

This strategy actually worked! The HTML5 spec isn’t 100% complete but you can already use it today. You can see a few sites explaining which features of HTML5 are ready for use today.


Internet Explorer is the key browser missing HTML 5 support

This is wholly untrue – although it’s clear that the statement is targeted at IE8 and below. It’s important to stress that, since IE9 was released in 2011, Internet Explorer has offered cutting-edge HTML5 support. Each release of Internet Explorer since version 9 has been on par with or even better than the state-of-the-art HTML5 support at the time it was released – particularly for the features that matter for the everyday web.

Microsoft, however, has suffered from a weak upgrade strategy. Internet Explorer has a slower release schedule (a year or more) compared to Firefox and Chrome (6 weeks), so features arrive slower on that platform. While every other browser now has a forced upgrade strategy, Microsoft allowed its users to keep older versions around much longer. To make matters worse, users of Windows XP cannot upgrade to IE9 because of a Microsoft policy designed to encourage customers to upgrade to a newer version of Windows. This has made IE8 an artificially popular browser, though many XP users appear to be using Firefox or Chrome instead of sticking with an outdated browser.

The key takeaway here is that Internet Explorer is not the problem – old versions of Internet Explorer are.


Internet Explorer is the most widely used browser in the world

While I don’t have the browser stats for this particular client available, I can say that this statement is not true at all! At best that statement is extremely misleading.

The following chart shows the partially combined market share of browsers in the US from August 2013. You can see that only 2 browsers in that list have weak HTML5 support – IE8 and IE7.


9-23-2013 3-24-52 PM


Designing a site without Internet Explorer in mind is a bad idea

Agreed. We would never do that! However, even Microsoft has been asking website developers to consider techniques such as progressive enhancement to allow for sites to adopt modern HTML5 features, while providing acceptable fallback support to the minority of users that still use an outdated browser.


Regardless of newer browsers, IE 8 and below do not support HTML5

This again, is only partially true and very misleading. A number of key features of HTML5 were inspired by Microsoft’s non-standard implementations in Internet Explorer. In many ways, HTML5 is a standardization of proprietary features that were first implemented in older versions of Internet Explorer. In a surprising amount of cases, IE has supported a version of an HTML5 feature for longer than HTML5 has been a standard. For instance, @font-face has been supported in Internet Explorer since version 4, released in 1997! Microsoft has supported gradient backgrounds and 2D transformations since IE 5.5 was released in 2000. Other features, such as CORS, have had proprietary support since IE8.

Importantly, every HTML5 tag can gain partial support in all versions of IE, at least for CSS, with a widely used HTML5 Shiv. This small piece of JavaScript helps older versions of IE recognize the new markup to allow them to be styled. In fact, Microsoft is recommending that developers use HTML5Boilerplate and Modernizr as the starting point for their templates – those projects already includes the HTML5 Shiv by default.

It is true, however, that supporting an HTML5 feature in IE8 and below will usually require a JavaScript fallback, called a polyfill, to map the HTML5 functionality to the analogous proprietary IE functionality. While the HTML5 Shiv will make elements styleable, it will not perform any magic. For instance, the shiv won’t make IE8 natively support date pickers on form inputs.


It will take some time before the 60% of users migrate to IE9 or newer

This is already untrue for the general public. Again, I don’t have access to the clients browser stats, but the publicly available information suggests that IE9 and above account for around 70% of Internet Explorer’s total market share in the United States – around 68% worldwide. A supermajority of IE users are already using a browser with good HTML5 support.

This is largely a result of time, mixed with the fact that Microsoft has been aggressively trying to sunset Windows XP and force people to upgrade to the latest version of IE. Official support Windows XP ends in April 2014. Importantly, Windows XP is the only operating system where IE8 is supported. Starting with Windows Vista, IE10 is the currently supported browser. Microsoft began a campaign in January, 2013 to aggressively push users to upgrade to IE10 and that campaign seems to have worked really well!

Looking at the current browser stats for the US in August, 2013 there are a few things that stand out:

Expanding the search to all browsers worldwide in August, 2013, we can see a similar story:


Most HTML5 features are only partially supported by browsers and may change, causing pages to break unexpectedly in the future

This is pointing out that building a website using experimental features of a browser is a risky proposition. Especially for features that are based on an incomplete spec. It is indeed possible that an experimental feature could change functionality in a future version of a browser, and this might lead to unforeseen issues in the future.

I would add, however, that this is the case with all browsers – even when you are not relying on experimental browser features. Even newer versions of Internet Explorer have been known to break features that were stable in older versions – that’s why they invented compatibility mode. Web developers are at the mercy of browser vendors, regardless of the existence of an officially recommended specification.

The good news is that it’s in best interest of the browser makers to avoid breaking the web. And, encouragingly, there is strong evidence to suggest that browser vendors take backwards compatibility very seriously – particularly for features that are broadly implemented. In fact, that’s actually how HTML5 came into existence. The browser makers banded together (forming the WHATWG) to create a spec (HTML5) that wouldn’t break the web, but would allow them to add in new features to push the web forward.

It’s important to note that it is simply not true that most of the HTML5 specification is experimental or likely to break. Looking through sites like HTML5 Please and Can I use, it seems obvious that there is broad browser support for all of the most useful portions of HTML5. While there are also portions of HTML5 where browser support is minimal or the specification is unstable, references such as HTML5 Please make these pitfalls easy to avoid. They point out, explicitly, which features are ready for today’s mix of browsers. There are many other references available that help a developer decide if the HTML5 feature they’re intending to rely on is likely to have negative future consequences (see above).

The features that SolutionSet would recommend for a given project are based on proven technologies that have been stable and supported by a majority of browsers for many years. We take special care to provide acceptable fallback support (often transparent to the customer) to support less capable browsers, such as IE8. We avoid features when they have buggy support in browsers, or when they are based on outdated specs. In most cases, controversial features simply aren’t necessary for making the types of websites we need to make for our clients.

It’s possible to make informed decisions about which features of HTML5 to support without alienating the minority of your customers that are using an outdated browser. And, the overwhelming majority (more than 90% in most locations) of your customers that have chosen to use a modern browser will appreciate the new experiences HTML5 allows.

Is your big enterprise ready for HTML5?


Leave a reply

Error getting theme layout