HTML5 and the W3C Recommendation Ruckus

By Craig Buckler
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

The HTML5 specification has finally become a W3C Recommendation. It’s done … a mere fifteen years after HTML4.01. However, the W3C beat the estimated 2022 schedule by eight years.

If you believe the reports, web users are shouting from their virtual rooftops and holding impromptu parties. There are also bizarre stories detracting from the announcement and making ludicrous claims such as:

  • The status has changed despite bitter specification squabbles between the W3C and WHATWG.
  • HTML5 is Steve Jobs’ legacy and would never have happened if it weren’t for his foresight (in banning Flash).
  • The web is far from complete and HTML5 won’t be usable for another decade.

The question for developers: how does this affect our daily website building chores?

The answer: it has absolutely no impact whatsoever.

The reason is simple. W3C specifications do not tell browser vendors what to do; they record what has been done. This point continues to cause widespread confusion but the general process is straightforward:

  1. Vendor A implements feature X in their browser.
  2. Vendor B (and possibly C, D, etc.) applaud loudly and consider implementation in their browsers.
  3. Feature X is documented in a W3C specification.
  4. The implementation is discussed and refined. The specification status moves from Editors’ Draft to Candidate Recommendation and, finally, to Recommendation.

Vendors always have ultimate control. Features are not guaranteed to be implemented, usable or consistent just because they appear in a W3C document. Fortunately, while Google, Apple, Microsoft, Mozilla, and Opera are competitors, the process encourages interoperability because it’s impractical for developers to adopt an unstable HTML5 technology. If we don’t use it, there was little point in the vendor creating the feature in the first place.

Of course, some vendors have a bigger clout than others or can influence HTML5 in different ways. Google controls Chrome/Chromium — the market leader — so a feature is less likely to be usable until it reaches the browser. Apple is free to implement an iPhone-specific feature and do not necessarily care whether it becomes an official HTML5 technology because they control that device.

From a development perspective, none of this matters. The web is device agnostic. Building sites and applications is — or should be — a exercise in robust progressive enhancement. For example:

  • You can use the new HTML5 <input type="date"> control. Some browsers have full support and display a calendar. Some have mid-level support and provide basic date validation. Some have no support and fall back to a standard text box.
  • You can adopt CSS3 techniques such as animation. Some browsers have full support. Some require a vendor prefix, which you can choose to omit, add manually, or automatically. Some older browsers have no support for animations, but you can ensure your application remains usable without them.
  • You can store data on the client using IndexDB. You can detect whether it’s supported by checking window.indexedDB exists and fall back to another solution such as server-side storage when necessary. The application may not be as polished on older browsers, but it’ll continue to work.

Admittedly, many developers now depend on frameworks such as AngularJS and their applications would fail without a modern browser and JavaScript. That choice is fine when fall-backs would have limited viability. Consider an HTML5 fast-action deathmatch game; it could never work offline or with server-side-only processing. In those situations, you’re targeting the browser as a platform — not the web. It’s a subtle distinction but an important one.

HTML5 becoming a W3C Recommendation is great news but developers have been using it for almost five years. Sometimes a technology has good browser support. Sometimes we decide to use a shim. Sometimes we fall back to lesser functionality or slower server-side processing. Sometimes we simply abandon an old, infrequently-used browser. The decision is a compromise based on technical, logistical and economic constraints. The W3C specification status, vendor competition and standards body politics will always have a negligible impact.

That said, those who’ve been irrationally avoiding HTML5 because “the specification is still a draft” now have fewer excuses. HTML5 is complete; let’s focus our attention on HTML5.1!

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Stephen Wagstaffe

    I get it, very well put, sharing your passion for “Building Incredible Internet Things”.
    #HTML5 #IOT #Design #Development #W3C #WebSites #Browsers #Servers

  • HTMLCOIN is here to support the effort of the entire HTML5 Community! Triumphant & Victorious!

  • Stephen Cunliffe

    I’m not sure where Steve Jobs comes into this?… sure he had a grudge against Flash and saw (like everyone else) that HTML5 was a better solution for many things that Flash provided, but HTML5 was going to happen whether Steve Jobs was on board or not.

    In fact the odd thing is that if you visit now, you’ll see that iOS safari is actually one of the least capable mobile browsers… sure they were the leader when iPhone first came out, but they’ve been slipping ever since. Even the mobile Firefox browser on Firefox OS whips safari in support levels.

  • Craig Buckler

    His anti-Flash stance had little direct impact HTML5 but, do a search, and you’ll find several articles which make the connection.

    I suspect Safari will slip further now Google have forked webkit into Blink. It’s also one of the most difficult browsers to test because you need an Apple device. At least Microsoft recognised that, if they can’t support their browser on a non-Windows OS, they’ll provide development tools to help (more about that coming soon).

    • Stephen Cunliffe

      I agree… it’s odd that it is Microsoft “doing the right thing” but they deserve some credit for providing VMs and such. I think the other thing that worries me about Safari on iOS is that the cadence of updates seems tied to iOS releases which is too long in the browser world IMHO.

      • Craig Buckler

        That’s true enough and Safari’s looking increasingly clunky when compared with, say, Chrome on Android.

        It’ll bite Apple if they’re not careful. Many developers do not have access to a Mac or iOS device. If too many sites and apps begin to fail because they’re not being tested, users will blame Apple (whether that’s fair or not). The situation will worsen as Webkit and Blink diverge.

        It’s a shame Apple ceased Safari on Windows. Only a small proportion of people used it but I suspect a high number were developers.