Will the Next Web Platform Please Hold Still?

[AJohn360]

Will the Next Web Platform Please Hold Still?

 

In an effort to not only accelerate the pace of Web development but also to add excitement to the idea that Web development is happening at all, Mozilla is launching development tracks for the next two editions of its Firefox Web browser — versions 5 and 6 — immediately, with hopes to push both into general release before the end of the year. This while Microsoft previews Internet Explorer 10 on the heels of its IE9 release, and Google projects Chrome 13 just one year after Chrome 7. Meanwhile, HTML5, the next version of the Web’s primary language, appears to have entered a permanent gestation phase. All the confusion has prompted Web developers — many of whom still use IE6 as their baseline for Web site support — to ask this question: What do we develop our sites against now?

 

by Scott M. Fulton III

 

 

Here is a seemingly simple enough question: What’s the minimum level of browser support provided by your team’s Web site? If your answer is Internet Explorer 6, which officially died in October 2006, then every browser maker today including Microsoft will tell you that’s not what it should be. You’re not taking advantage of the vast repository of features that most Web browsers presently installed, regardless of their brand, offer, they’ll say.

So which browser represents the baseline? With browser version numbers accelerating like speeds at the Indianapolis 500, the baseline browser has become impossible to gauge. Microsoft released IE9 in mid-March 2011, and began previewing IE10 to developers literally the same day. Mozilla released Firefox 4 one week later, and now is actively testing not only Firefox 5 but Firefox 6. Opera Software, for too many months an also-ran, premiered a dramatically improved Opera version 10 in December 2009, which runs as well as or better than any competitor. Version 11 came only one year later, but in successive months Opera began testing version 11.5, and the whispers have already begun surrounding Opera 12. And just one year after Google made what it characterized at the time as an historic release of Chrome 5, it has generally released Chrome 11.

Version numbers may have already become meaningless. And for large organizations tackling major Internet-facing projects that could span 18 months or two years in the gestation phase, it’s past the point of being called a “problem.”

“There’s a danger in moving too fast sometimes. Large institutional organizations need something a little more standard, a little more stable,” says John Foliot, who chairs the Media Sub-group of W3C, the organization responsible for creating and maintaining the specifications for the Web. Foliot — one of the people responsible for declaring what the Web is, from a technical standpoint — is leading the call to slow things down.

“Look at the banking sector, for example, or hospitals, the oil industry. Large organizations that need to pull together a comprehensive strategy for marketing, or intranet/extranet, or one of these large-scale projects, need something stable that they can reference… I hate to use the word ‘bible,’ but they need a stable build so they’re all speaking the same language,” he says.

What Foliot would like that stable reference to be is called HTML5. You’ve probably heard of it, and may have even seen its shiny new shield logo. You would think the answer to the question, “What is HTML5?” would be, “The fifth edition of HTML.” Not really.

As these questions get simpler, their answers get more complex. Perhaps the only immediately sensible one, at least for now, is this: It’s what your Web development team needs to know to produce a contemporary Web site that meets your users’ and customers’ expectations for appearance, performance, reliability, and accessibility.

Or as Opera Software’s Web evangelist, Bruce Lawson, puts it: “HTML5 gives us more tools in our arsenal, but it’s not a qualitative change. It has to do with separation of concerns, progressive enhancement, graceful degradation, and unobtrusive scripting.”

But these are only partial answers. If everyone’s expectations for Web performance was equally high, IE6 would command far less than the 11% worldwide usage share that recent NetApplications analytics data projects. The most current stable releases of the top five most utilized browser brands on the planet — IE, Mozilla Firefox, Apple Safari, Google Chrome, and Opera — purport to “support HTML5.” And all five will happily make the argument that, since they support HTML5, so should your Web site.

But let’s assume they’re right. What does that mean? Typically, supporting a platform means adopting specific behaviors and including, or linking to, certain code. If you “support Flash,” then it’s expected that your Web site serves up video or functionality that can be run by Adobe Flash Player. Is HTML5 a language, a platform, a code base, a set of behaviors? Most HTML5 proponents render a meaningless response such as, “It’s all of these and more!” but over time, their tone has grown suspiciously salesmanlike, taking on the air of Chevy Chase’s proclamation that “New Shimmer” is a floor wax and a dessert topping.

The Union of All Sets

If you were to compile every browser maker’s list of principal HTML5 components into a single master list, what you end up with will at least contain the following:

HTML5 prescribes a new way to compartmentalize the components of a Web page designed to be read as a formal document. For example, contiguous elements of text about the same topic can be grouped into a <section>, which HTML5 treats differently than a <div>. Navigational links now have a <nav> element all to themselves; and <header> and <footer> elements are clearly demarcated rather than casually derived. Heading levels become specific to the section, not the document, so the <h1>, <h2>, and so on within a footer have both their own layout and their own context, which is important especially when text inside a section is imported from another source. This use of explicit section designation where there was none before is enormously beneficial for publishers of articles or factual wikis. But the fact that older browsers ignore tags they cannot parse could lead to circumstances where new articles could appear well-formatted in newer browsers but catastrophic in older ones — specifically, those installed on a majority of PCs and smartphones.

Video on a browser that purports to “support HTML5” should be capable of being processed by a codec managed by the browser itself, as opposed to a plug-in (which is actually a separate program, like Flash and Silverlight). Previously, the plan was for that built-in codec to carry no royalties or licensing requirements. But the implementation of the pipe dream of “royalty-free video” opens the floodgates to a cesspool of legal disputes, the scope and depth of which not even the largest members of the Web development community are adequately prepared to wade through. Today, the most-used video delivery platform on the Web is Flash, though Flash development tools are not free and are likely to never become free. And although H.264 — the highest-definition codec Flash supports — is licensed free for non-commercial use, once that use becomes commercial, it carries an explicit royalty fee.

A new and sophisticated API called WebSocket enables, for the first time, a formal mechanism for client and server to exchange messages in a session context. Today, developers are using a function called XMLHttpRequest in Asynchronous JavaScript (AJAX) for “under-the-table” messaging so that browsers can update parts of pages in response to specific events. Also, a fast-growing number of developers are using a third-party tool called Comet to enable real-time communications, which is vitally necessary for applications such as stock trading, videoconferencing, and intelligence gathering. WebSocket would replace all of this with something that’s presumably official, but what remains to be seen is whether WebSocket would necessarily be better, or more efficient, or faster than Comet.

One of the original inspirations for HTML5 was the opportunity to implement a cornucopia of revised screen gadgets called WebForms. These are the graphic devices used to collect data and submit it to the server; and in their new incarnation, their internal events and even the validation of their contents can be handled without the use of JavaScript. An important new property for these gadgets is ContentEditable, which sets up local storage buffers enabling users to alter the contents of entire pages on-screen as though they were editing a word processor document. (Imagine this for a wiki site.) But in order for a site to provide input forms within browsers that don’t yet support HTML5, developers may still have to develop JavaScript functions anyway, retrofitting older browsers with the functionality that HTML5 would have provided otherwise.

The Canvas element in HTML5 is a cross-browser graphics platform that lets developers plot dots, lines, and shapes (not unlike the great home computers of the 1980s) in two-dimensional space without invoking any third-party plug-in. Until a respectable percentage of installed browsers support Canvas, developers may have to utilize fallback modes for less predictable platforms such as SVG (which isn’t used by older builds of Internet Explorer), or even fall back to desperately slow, classic HTML objects.

One new HTML5 component that is already altering the browser security model is Web Storage, a specification for allocating secure, general-purpose memory on the client side for maintaining any kind of data without the use of cookies. Not only does this help maintain session state (the illusion of being logged on) but it makes possible an entire universe of Web-based applications that, up to now, require plug-ins like Flash and Silverlight. This is one major class of functionality that a browser can either have or not have, to put it bluntly, and not having it essentially closes the browser to higher-order Web apps. For software manufacturers to someday deliver fully functional substitutes for installed apps to browsers, Web Storage may be critical.

Depending upon whom you ask, this list may be somewhat longer or much longer. For example, you may read about new methods for graphical font embedding, or support for 3D graphics libraries like WebGL, or support for reading external files using a file system that stays inside the browser’s secure sandbox. There are actually dozens of other examples, all of which have been declared by someone to be part of HTML5, some of which either may be correct now or may become correct at some indeterminate date.

“HTML5 has become an umbrella term, and I don’t think browser manufacturers can take the rap for that completely. Tech journos can take the rap for it, and also the community can take the rap for [the fact that] anything that looks snazzy and sexy gets called HTML5,” says Bruce Lawson, a Web evangelist for Opera Software as well as a long-time contributor to the Accessibility Task Force of the Web Standards Project. “You wouldn’t believe how many e-mails I get saying, ‘Bruce, would you give me some feedback on my HTML5 page,’ and I look at it, and it’s no more HTML5 than my vacuum cleaner. Because it looks snazzy and it’s got a rounded corner and a drop-shadow, people are calling it HTML5.”

The Gating Factor

In recent months, each of the five major browser makers has laid claim to being representative, or more so than anyone else, of HTML5 or “true HTML5.” Perhaps the most attention-getting attempt in recent months came from Microsoft, which during its MIX 11 developers’ conference last March went so far as to state its IE9 browser was indicative of a kind of purified form called “native HTML5,” implying that any other browser may deliver some kind of unauthorized derivative.

“Native experiences continue to be the best experiences,” stated Microsoft corporate vice president Dean Hachamovitch during his keynote speech. “On phones, for example, people consistently choose native applications over Web sites. As developers, we’d rather have native support for important features rather than an add-in or a hack.

“Now, lots of things lose in translation,” Hachamovitch continued. “Dante is best in Italian. Shakespeare is best in British. Surak is best in Vulcan. It’s just [that] some things are just not the same in translation. And the same is true for the Web. The sites that you visit and the sites that you write are better when your browser runs them natively. Every library, every layer, every abstraction between your site and the device challenge performance, reliability, and the overall experience… The only native experience of the Web of HTML5 today is on Windows 7 with IE9.”

“It kinda pisses me off when people misuse the term ‘HTML5,’ but I appreciate that I’m in a minority,” Opera’s Bruce Lawson remarks. “I’m the old guy shaking his cane and shouting, ‘Get off my lawn!’ to the local children.”

“‘Native HTML5’ is just an empty concept,” Lawson continues, “because HTML is designed not to be native to anything. It’s designed to be the carrier of the Web, which is how it’s supposed to work on any browser, on any operating system, on PDAs and phones and desktop computers and speech synthesis for people who are blind. It’s designed not to be native. ‘It does not compute,’ Mr. Spock would say before setting his phaser to stun.”

John Foliot agrees with Lawson over the nature of Hachamovitch’s phrase. “First of all, there is no such thing as ‘native HTML5.’ That’s a marketing term,” Foliot says. But he understands Hachamovitch’s underlying message — that the Web should be delivered by the browser, not so much by things attached to it — and argues in favor of looking for common ground. “They’re not wrong,” he says, referring to Microsoft, “because I think what they were really saying is, if you use the standards, then you will get cross-browser support and you will get a common implementation expectation.”

Who Determines What’s “Common?”

Historically the keeper of the specifications for Web standards has been the consortium that now goes by the abbreviation W3C. But in 2004, individuals representing Apple, Mozilla, and Opera — all of which continue to participate in W3C — formed a separate organization called the Web Hypertext Application Technology Working Group (WHATWG), to which Google has recently contributed suggestions and guidance. WHATWG became the kind of proving ground for new concepts which may (or may not) become part of the HTML5 specification. In February 2011, citing confusion over not only the direction but the very purpose of lumping every new component into a collective “next version” context, WHATWG decided it would drop the “5” from the name of the concept it was working on, in favor of “HTML” or even “HTML, the Living Standard” as a broader framework.

So it was that the body comprised of the principal deciders of what constitutes HTML5 declared it wasn’t really up to them.

Rob Sayre, an engineering director at WHATWG member Mozilla, attempts to sort this out for us. “Web developers focus on features that work reliably across browsers,” says Sayre, “and they adopt new HTML5 capabilities once a sufficient percentage of their users have modern browsers. That means the gating factor for feature deployment is not the pace of development in the leading browsers, but rather the [relative sizes] of their user bases on older browsers and operating systems… When developers focus on broadly-implemented Web standards, they’ll arrive at a feature set that all browsers have an incentive to support. The list of HTML5 features in that stable category will continue to grow, even as each market participant pushes the boundaries in line with their interests.”

Opera’s Bruce Lawson adds that to a greater extent in recent months, HTML5 has been incorporating functionality belonging not to the next generation but instead to the current generation of browsers. “I think a lot of people maybe haven’t understood that a good whack of HTML5 standardizes stuff that was in the browsers anyway, and was never previously standardized,” Lawson says. “People shouldn’t necessarily be overly alarmed that there’s this new standard there, because a lot of it is stuff they’ve already been using anyway as proprietary stuff in various other browsers.”

Although Google was reluctant to provide attributable quotes for this article, a representative for the company essentially disagrees with Mozilla’s Sayre. The rapid and accelerating release cycle for Chrome and other browsers, the representative remarks, gives developers more flexibility and incentive to drop IE6 as their baseline and incorporate more functionality into their sites and Web apps. Google is careful to implement changes in Chrome, the representative added, in such a way that existing sites don’t break.

As for a baseline, rather than use browser capability as a model, the Google representative suggested looking to the general functionality level of Web apps that are in wide use. Gmail should stand as an example of the level and variety of functionality that developers can adopt today and feel safe about doing so, the representative said.

“Hot, young Web developers out there who are chomping at the bit to use all the cool stuff the day it’s released, or the day it supports more than two browsers,” argues the W3C’s John Foliot, “need to understand that if it’s not stable, there’s a real danger in trying to incorporate it into large projects.” Boutique shops often have the best opportunity to integrate new functionality into their Web sites, Foliot adds, making them more accessible and more popular. But the result is an expanding customer base, all of whom have to be maintained as the business grows. When that happens, the opportunities for these same shops to keep integrating new features diminish. When a specification changes (or when corporate politics makes it retroactively changed), what had been a simple feature adaptation becomes something more like a platform migration.

Web standards and standardization continues to be a political issue among browser makers, if only just to keep up appearances. In March 2010, Chrome became the first browser to integrate Adobe Flash, thus setting Google apart from other HTML5 proponents (Mozilla included) who argued in favor of adopting only open, non-proprietary standards. Then just two months later, in a move that confused nearly everyone, Google released to the open source community the VP8 video codec it had obtained through the acquisition of its creator company. That gave Google a stake in either potential outcome of the built-in video argument. Microsoft responded in April by integrating the H.264 codec into Internet Explorer, under the authority of its licensing agent, MPEG LA. That prompted Google to drop H.264 support directly last January, in a move that enabled it to take an opposite political stance to that of Microsoft (the kind of move that’s always popular with the “tech journos”) while at the same time continuing to integrate Adobe Flash which, incidentally, includes H.264.

This from two companies which claim their respective products to be “the HTML5 browser.”

So should either of these companies, or any browser maker, have a final say as to what HTML5 is or becomes? Being part of Opera makes Bruce Lawson a contributor to WHATWG, which now perceives the “HTML Living Standard” as open to new and different features the way Wikipedia is open to new and different facts.

“HTML5 is a specification,” says Lawson, “but it’s not a monolithic specification. It is a fabulous party bag full of goodies. They’re all actually quite discrete, but it just so happens that they are stuck in a great, big sack marked ‘HTML5.’ So what I always say to developers is, the question of, ‘What is HTML5?’ or, ‘When will HTML5 be ready?’ or, ‘Which browsers support HTML5?’ There’s no real answer to the question. The answer to the question is, ‘What do you need to use for this particular project?’” Then you go to caniuse.com, which tells you what browsers natively support those technologies, he says. “Then you go to your client or your boss and say, ‘That’s gonna work in all of the browsers that we need [to support].’ Then you employ them or not.”

Over the years, Canadian/Californian John Foliot and Briton Bruce Lawson have become close personal friends, but on this point they agree to disagree. Foliot believes the W3C’s job at this point is to certify the features that browser makers have already made stable, and declare them to be snapshots of a specification that Web developers can rely upon for stability.

“WHATWG produces a perpetual beta. The W3C takes those betas and essentially does milestones, saying, ‘This is the specification as supported,’” states Foliot. “Before any particular W3C recommendation becomes a full-blown specification, there have to be two independent implementations of that specification.” So for someone who believes the specification process should accelerate to match the speed of the features invention process, Foliot has this advice: “If there’s one message I would give to the general development community, it’s that it doesn’t all have to be done tomorrow. Sometimes a little bit of patience and time allows you to come up with something that’s ultimately better.”

[falkencreative]

Source: http://www.softwarequalityconnection.com/2011/05/will-the-next-web-platform-please-hold-still/