That old chestnut, attributed to any number of different parties, has been in circulation since long before there was an Internet, but it still speaks volumes to the curious situation developing today:
With multiple, parallel versions of HTML in use; a slew of different browsers in play, all of which implement those HTML versions slightly differently; and two separate standards-setting bodies directing traffic, the World Wide Web looks to have any number of possible futures.
For those of us in IT -- the people, after all, who have to deploy, test and support the browsers and systems everyone uses -- the decisions of theWorld Wide Web Consortium and the Web Hypertext Application Technology Working Group are more than just academic, and they raise some sticky questions.
How should we go about supporting browsers that are becoming more fluid, with point revisions every few weeks instead of every several months to a year? And how do we tap all of HTML's new, evolving functionality without breaking existing designs or compatibility?
To answer those questions -- and chart a course for HTML evolution in murky waters -- it helps to know a bit of background about these august institutions.
In this corner, W3C
The World Wide Web Consortium (W3C), the standards-setting body most directly responsible for the Web as we've come to know it, was formed in 1994 as a way to corral together a single, consistent version of HTML. This it achieved, at two costs.
The first involves enforcement, or the lack thereof: The W3C's standards areRecommendations (they insist on the capital R), which aren't backed by any enforcement. That's because attempts in the early 2000s to provide officialconformance testing for W3C recommendations fizzled out amid concerns that the group would become too authoritarian or too commercial.
The other cost is the speed of decision-making. The W3C, whosemembership is a broad and diverse mixture of companies, educational institutions and individuals, has been consistently criticized for being stodgy and hidebound. After XHTML 1.1 was published in 2001, it took the W3C until 2006 to release eight working drafts for XHTML 2.0. Such a pace just wasn't working for a Web that was becoming more consumer-focused and commercially driven.
In that corner, WHATWG
In retrospect, it's no surprise that another group -- the Web Hypertext Application Technology Working Group (WHATWG) -- arose in 2003 to tackle "the development of HTML and APIs needed for Web applications." WHATWG is a conglomeration of engineers from Apple, Mozilla and Opera; all three have a hand in the browser market, and that's how WHATWG drives progress -- from the browser side.
"The WHATWG is faster-moving and able to take direct action on standards because many of the members own the browsers that users rely on," explains Forrester researcher Jeffrey Hammond. "The WHATWG follows the golden rule: He who has the gold -- browsers in this case -- makes the rules."
Often the WHATWG's quicker actions spur the larger W3C to adopt a de facto standard more rapidly than it otherwise would, he says.
One significant case in point: The WHATWG's work with HTML5 was adopted by the W3C in 2007 as the basis for the current W3C-sanctioned working draft of HTML5. Moreover, by 2009, the W3C had abandoned work on XHTML 2.0 in favor of HTML5.
"W3C is certainly the more presidential and regulated master of Web standards, but WHATWG is more progressive and focused more on the delivery [of] HTML and related technologies," says Christian McMahon, former CIO of GoIndustry DoveBid and current managing consultant at Web development 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."
Related reading: Three HTML5 animation tools: Adobe Edge, Sencha Animator, Tumult Hype (Insider: registration required)
The current state of HTML
Because of this back-and-forth between the WHATWG and the W3C, we've ended up in a peculiar place as far as Web standards go. Let's take stock:
HTML is a "living standard."
The most confusing and potentially distracting aspect of the current state of Web standards, especially for IT managers, is that HTML5 exists not as a single cohesive specification but as a collection of different features under the general umbrella of "HTML5" (or just "HTML," without the numeral, if you're on board with WHATWG's campaign to drop version numbers going forward). Support for any one of those features (e.g., the video tag, native drag-and-drop, the file-manipulation API, or websockets) depends entirely on the browser (see a list of variations here).
Consequently, it's that much harder to pick any one of those features and support it consistently. Any long-term planning has to be done in terms of a specific product -- a browser -- rather than a specific feature. This can drive IT people crazy, especially the most sophisticated ones: Shouldn't it be the standard, not the product, that dictates their choices?
The timetable is uncertain.
It follows that if HTML is a collection of evolving features rather than a completed specification, it's not easy to predict when a given feature will be available. Different browsers have different incremental levels of support for HTML5, which means gaining access to many of the individual features in HTML5 is entirely a matter of which browser you're using and what revision you're on.
It's also not clear when a given feature may show up in a given browser, or in what form: You can only count on what's there now, or what's been there for a few revisions, or what's rumored to be on the way.
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 to implement HTML5, and sometimes HTML generally. Chrome, for instance, has historically been a good supporter of HTML5, with Firefox, Safari and 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 new standard"? 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 our users (and ourselves) to an exhausting rolling schedule of browser upgrades just to stay on top of things?
The short answer to both those questions, thankfully, is "no," for three principal reasons.
First, implementations trump standards.
At least for IT people, anyway -- they're concerned more with what they actually deploy, since that's what their people most directly use in the first place. "Classic IT shops are consumers of technology; how the standards evolved is moot to them," says independent consultant Jay Hemmady, former regional CIO of Market Transport and former CTO of Bidwell (now Ameritrade).
To wit: Few people care that Xerox invented the GUI as we currently know it; they only care about how it's implemented on their desktop. Likewise, for most shops, the goal isn't to use the HTML5 video tag; it's to find the best way to render video using a given browser. In other words, standards mean nothing without a workable implementation.
That, in turn, means IT should keep its eye on what features are showing up in which browsers, and let the standards continue to evolve as 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 specific platforms and browsers, and not generic concepts about standards, while acknowledging that this strategy requires some work. "Use a site like HTML5 Test to figure out what works on those browsers and what doesn't," he recommends.
"Take a progressive enhancement strategy that starts with basic textual content and adds capabilities and UI as you detect browsers that support advanced features," he continues. Finally, "use a library like Modernizr to detect what features a browser supports, and use a template like Boilerplate to get started."
Third, products are easier to work around than standards.
In the short run, it's far easier to switch or upgrade browsers than it is to influence the development of a particular standard. You could even try lobbying the browser maker to add a given feature (though the latter typically only works if your voice is among many clamoring for the 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 product makers might be worried about the standards bodies, and the IT departments not so much. Compatibility, integration and co-existence are 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-setting bodies do their work and concentrate on targeting specific browsers to deliver desired HTML5 features. But what's the best way to accomplish that goal without making yourself, your department or your users crazy?
One possible approach, in settings where a browser is being deployed as part of a consistent desktop, is to decouple the browser as much as possible from any desktop it's installed on. Remote virtualization or self-contained app deployments (e.g., PortableApps) are two ways to accomplish this. You can then upgrade the browser independent of anything else on the system, with as few external dependencies as possible.
This approach is particularly recommended if you have chosen a browser that has a fairly aggressive upgrade cycle (e.g., Chrome or Firefox); the upgrades can be rolled out by the IT department rather than the browser maker.
For people developing public-facing apps: Wait until a given feature is uniformly supported by the major browser share using your application, then add it. Derive actual usage statistics from your site logs; don't rely exclusively on user feedback to decide which browsers to support, as the loudest voices don't always represent the lion's share of actual users.
Whenever you can, keep development on HTML5 discrete from development for 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 those elements until, one, the majority of browsers have it and, two, the features in question are implemented as consistently as possible across browsers.
Keep in mind that the story is going to be different for product makers rather than rank-and-file IT supporters. In this case, we actually have it easier in the long run than commercial product developers, since IT departments typically don't compete in the open marketplace, but rather concentrate on serving our users. "Do you want to be the only tablet maker that doesn't support WebSockets or IndexDB when you're doing everything you can to attract developers to your platform, which is one choice among five?" says Hammond. "Probably not."
Where does this all leave us, savvy IT people watching the Titans (W3C and WHATWG) tussle over the future of the Web?
There's no denying the evolution of HTML5 is a mess but also unavoidable at this point -- and on the other side of that mess is a whole new kind of Web. "We're in a period of short-term pain in order to get long-term gain," says Hammond. "It's platform fragmentation, which is driving browser fragmentation, which is driving innovation. As a result, the level of support for standards and proposed standards is all over the place."
Once those standards are adopted, things should settle down, Hammond predicts. "We'll see greater pressure from all to support them."
In the meantime, hold on tight and enjoy the ride. "Evolution is messy during periods of punctuated equilibrium. That's the kind of era we're in right now."
No comments:
Post a Comment