The nice thing about standards is there are so many of them to choose from.
That old chestnut, attributed to any number of different parties, hasbeen in circulation since long before there was an Internet, but itstill speaks volumes to the curious situation developing today:
With multiple, parallel versions of HTML in use; a slew of differentbrowsers in play, all of which implement those HTML versions slightlydifferently; and two separate standards-setting bodies directingtraffic, the World Wide Web looks to have any number of possiblefutures.
For those of us in IT — the people, after all, who have todeploy, test and support the browsers and systems everyone uses — thedecisions of the World WideWeb Consortium and the WebHypertext Application Technology Working Group are more thanjust academic, and they raise some sticky questions.
How should we go about supporting browsers that are becoming morefluid, with point revisions every few weeks instead of every severalmonths to a year? And how do we tap all of HTML’s new, evolvingfunctionality without breaking existing designs or compatibility?
To answer those questions — and chart a course for HTML evolution inmurky waters — it helps to know a bit of background about these augustinstitutions.
In this corner, WEC
The World Wide Web Consortium (W3C), the standards-setting body mostdirectly responsible for the Web as we’ve come to know it, was formedin 1994 as a way to corral together a single, consistent version ofHTML. This it achieved, at two costs.
The first involves enforcement, or the lack thereof: The W3C’sstandards are Recommendations(they insist on the capital R), which aren’t backed by any enforcement.That’s because attempts in the early 2000s to provide official conformancetesting for W3C recommendations fizzled out amid concernsthat the group would become too authoritarian or too commercial.
The other cost is the speed of decision-making. The W3C, whose membershipis a broad and diverse mixture of companies, educational institutionsand individuals, has been consistently criticized for being stodgy andhidebound. After XHTML 1.1 was published in 2001, it took the W3C until2006 to release eight working drafts for XHTML 2.0. Such a pace justwasn’t working for a Web that was becoming more consumer-focused andcommercially driven.
In that corner, WHATWG
In retrospect, it’s no surprise that another group — the Web HypertextApplication Technology Working Group (WHATWG) — arose in 2003 totackle “the development of HTML and APIs needed for Web applications.”WHATWG is a conglomeration of engineers from Apple, Mozilla and Opera; allthree have a hand in the browser market, and that’s how WHATWG drivesprogress — from the browser side.
“The WHATWG is faster-moving and able to take direct action onstandards because many of the members own the browsers that users relyon,” explains Forrester researcher Jeffrey Hammond. “The WHATWG followsthe golden rule: He who has the gold — browsers in this case — makesthe rules.”
Often the WHATWG’s quicker actions spur the larger W3C to adopt a defacto standard more rapidly than it otherwise would, he says.
One significant case in point: The WHATWG’s work with HTML5 was adoptedby the W3C in 2007 as the basis for the current W3C-sanctioned workingdraft of HTML5. Moreover, by 2009, the W3C had abandoned work on XHTML2.0 in favor of HTML5.
“W3C is certainly the more presidential and regulated master of Webstandards, but WHATWG is more progressive and focused more on thedelivery [of] HTML and related technologies,” says Christian McMahon,former CIO of GoIndustry DoveBid and current managing consultant at Webdevelopment firm Jamaza.
In the end, McMahon and other industry watchers agree, the two standards groups are best off collaborating and not competing. “Working together is the only real way to create stability in recommended standards.”
The current state of HTML
Because of this back-and-forth between the WHATWG and the W3C, we’veended up in a peculiar place as far as Web standards go. Let’s takestock:
HTML is a “living standard.”
The most confusing and potentially distracting aspect of the currentstate of Web standards, especially for IT managers, is that HTML5 existsnot as a single cohesive specification but as a collection of differentfeatures under the general umbrella of “HTML5” (or just “HTML,” withoutthe numeral, if you’re on board with WHATWG’s campaign to drop versionnumbers going forward). Support for any one of those features (e.g.,the video tag, native drag-and-drop, the file-manipulation API, orwebsockets) depends entirely on the browser (see a list of variations here).
Consequently, it’s that much harder to pick any one of those featuresand support it consistently. Any long-term planning has to be done interms of a specific product — a browser — rather than a specificfeature. This can drive IT people crazy, especially the mostsophisticated ones: Shouldn’t it be the standard, not the product, thatdictates their choices?
The timetable is uncertain.
It follows that if HTML is a collection of evolving features ratherthan a completed specification, it’s not easy to predict when a givenfeature will be available. Different browsers have differentincremental levels of support for HTML5, which means gaining access tomany of the individual features in HTML5 is entirely a matter of whichbrowser you’re using and what revision you’re on.
It’s also not clear when a given feature may show up in a givenbrowser, or in what form: You can only count on what’s there now, orwhat’s been there for a few revisions, or what’s rumored to be on theway.
The browser has become the standard
The end result of all this is that specific browsers — and sometimes specificversions of specific browsers — have become the only reliable way toimplement HTML5, and sometimes HTML generally. Chrome, for instance,has historically been a good supporter of HTML5, with Firefox, Safariand Internet Explorer in rough order after that.
What it means for IT
What does it mean for IT folks if indeed “the browser is the newstandard”? Must we hang on to each word the WHATWG and W3C hand down as”the future of the Web”? More importantly, do we need to submit ourusers (and ourselves) to an exhausting rolling schedule of browserupgrades just to stay on top of things?
The short answer to both those questions, thankfully, is “no,” forthree principal reasons.
First, implementations trump standards.
At least for IT people, anyway — they’re concerned more with what theyactually deploy, since that’s what their people most directly use inthe first place. “Classic IT shops are consumers of technology; how thestandards evolved is moot to them,” says independent consultant JayHemmady, former regional CIO of Market Transport and former CTO ofBidwell (now Ameritrade).
To wit: Few people care that Xerox invented the GUI as wecurrently know it; they only care about how it’s implemented on theirdesktop. Likewise, for most shops, the goal isn’t to use the HTML5video tag; it’s to find the best way to render video using a givenbrowser. In other words, standards mean nothing without a workableimplementation.
That, in turn, means IT should keep its eye on what features areshowing up in which browsers, and let the standards continue to evolveas they will.
Second, product versions are easier to target than standards.
It’s easier to make something for a specific browser — or a specific iteration of that browser — than it is to write to an abstract standard. (“Chrome version 15 and up” is a narrower target than “HTML5.”) Also, browsers tend to widen their feature support over time rather than narrow it, which also makes targeting easier.
Forrester’s Hammond agrees that IT managers should focus on specificplatforms and browsers, and not generic concepts about standards, whileacknowledging that this strategy requires some work. “Use a site like HTML5 Test to figureout what works on those browsers and what doesn’t,” he recommends.
“Take a progressive enhancement strategy that starts with basic textualcontent and adds capabilities and UI as you detect browsers thatsupport advanced features,” he continues. Finally, “use a library like Modernizr todetect what features a browser supports, and use a template like Boilerplate toget started.”
Third, products are easier to work around than standards.
In the short run, it’s far easier to switch or upgrade browsers than itis to influence the development of a particular standard. You couldeven try lobbying the browser maker to add a given feature (though thelatter typically only works if your voice is among many clamoring forthe same feature, and even then it’s no guarantee of success).
“It’s the product manufacturers that elect to use or not use standards.IT shops [just] acquire the products,” says Hemmady. “The productmakers might be worried about the standards bodies, and the ITdepartments not so much. Compatibility, integration and co-existenceare more important to IT departments than adherence to standards.”
How to cope
We’re agreed, then, that it’s IT’s job to let the standards-settingbodies do their work and concentrate on targeting specific browsers todeliver desired HTML5 features. But what’s the best way to accomplishthat goal without making yourself, your department or your users crazy?
One possible approach, in settings where a browser is being deployed aspart of a consistent desktop, is to decouple the browser as much aspossible from any desktop it’s installed on. Remote virtualization orself-contained app deployments (e.g., PortableApps)are two ways to accomplish this. You can then upgrade the browserindependent of anything else on the system, with as few externaldependencies as possible.
This approach is particularly recommended if you have chosen a browserthat has a fairly aggressive upgrade cycle (e.g., Chrome or Firefox); the upgradescan be rolled out by the IT department rather than the browser maker.
For people developing public-facing apps: Wait until a given feature isuniformly supported by the major browser share using your application,then add it. Derive actual usage statistics from your site logs; don’trely exclusively on user feedback to decide which browsers to support,as the loudest voices don’t always represent the lion’s share of actualusers.
Whenever you can, keep development on HTML5 discrete from developmentfor HTML4 and XHTML. The latter two are stable, known quantities.HTML5, on the other hand, has a lot of elements that are still protean,and therefore you shouldn’t formally add support for any of thoseelements until, one, the majority of browsers have it and, two, thefeatures in question are implemented as consistently as possible acrossbrowsers.
Keep in mind that the story is going to be different for product makersrather than rank-and-file IT supporters. In this case, we actually haveit easier in the long run than commercial product developers, since ITdepartments typically don’t compete in the open marketplace, but ratherconcentrate on serving our users. “Do you want to be the only tablet maker that doesn’t supportWebSockets or IndexDB when you’re doing everything you can to attractdevelopers to your platform, which is one choice among five?” saysHammond. “Probably not.”
Where does this all leave us, savvy IT people watching the Titans (W3Cand WHATWG) tussle over the future of the Web?
There’s no denying the evolution of HTML5 is a mess but alsounavoidable at this point — and on the other side of that mess is awhole new kind of Web. “We’re in a period of short-term pain in orderto get long-term gain,” says Hammond. “It’s platform fragmentation,which is driving browser fragmentation, which is driving innovation. Asa result, the level of support for standards and proposed standards isall over the place.”
Once those standards are adopted, things should settle down, Hammondpredicts. “We’ll see greater pressure from all to support them.”
In the meantime, hold on tight and enjoy the ride. “Evolution is messyduring periods of punctuated equilibrium. That’s the kind of era we’rein right now.”