All posts tagged ‘W3C’

A Brave New Web Will Be Here Soon, But Browsers Must Improve

The great promise of HTML5 is that it will turn the web into a full-fledged computing platform awash with video, animation and real-time interactions, yet free of the hacks and plug-ins common today.

While the language itself is almost fully baked, HTML5 won’t fully arrive for at least another two years, according to one of the men charged with its design.

“I don’t expect to see full implementation of HTML5 across all the major browsers until the end of 2011 at least,” says Philippe Le Hegaret, interaction domain leader for the Worldwide Web Consortium (W3C), who oversees the development of HTML5.

He tells Webmonkey the specification outlining the long-promised rewrite of the web’s underlying language will be ready towards the end of 2010, but because of varying levels of support across different browsers, especially in the areas of video and animation, we’re in for a longer wait.

Most web pages are currently written in HTML version HTML 4.01, which has been around since the late 1990s. The web was mostly made up of static pages when HTML was born, and it has grown by leaps and bounds since then. Now, we favor complex web applications written in JavaScript like Gmail and Facebook, we stream videos in high-definition, we consume news in real-time feeds and generally push our browsers as far as they’ll go. These developments have left HTML drastically outdated, and web authors have resorted to using a variety of hacks and plug-ins to make everything work properly.

HTML5 — which is actually a combination of languages, APIs and other technologies to make scripted applications more powerful — promises to solve many of the problems of its predecessor, and do so without the hacks and plug-ins.

We’re already close. All the major browsers are providing some level of support for HTML5.

“There’s strong support already in Firefox and Safari. Even Microsoft IE8 has some partial support,” says Le Hegaret, referring to some code within HTML5 that enables the browser to pass information between pages.

Browser makers are approaching support incrementally, adding features little by little with every subsequent release. Some, like Mozilla, can build new features into the next release in a matter of months. For others, like Microsoft, it takes much longer.

Google Chrome is maturing extremely quickly and already supports most of HTML5. This is mostly because Google didn’t start from scratch — the company chose to use the open source Webkit rendering engine, the same one used by Safari. Still, this doesn’t mean both browsers support HTML5 equally.

“Video support between Safari and Chrome, despite the fact that they are both using the same underlying engine, is totally different because video support is not part of the Webkit project at the moment,” says Le Hegaret.

It’s actually this very issue — support for playing videos inside the browser — that continues to be one of main factors blocking the broad adoption of HTML5.

The way the specification is written now, website authors will have the ability to link to a video file as simply as an image file. The video plays in the browser without using a plug-in, and the author can create a player wrapper with controls.

But browser vendors are stuck arguing over which video format to support. Mozilla, Google and Opera are interested in the open source Ogg Theora video format. Apple has substantial investments in its Quicktime technology, so it’s pushing for the Quicktime-backed H.264 format. Microsoft wants people to use its Silverlight plug-in, so Internet Explorer isn’t supporting native video playback in the browser at all.

Google has voiced support for Ogg, but it has also recently made a bid to purchase On2, a company that makes a competing video technology. Rumor has it Google might release On2′s video technology under an open source license once the sale is complete.

Until these issues are sorted out, consumers and content providers alike are forced to rely on plug-ins. Le Hegaret says that while these plug-ins have certainly helped the web arrive where it is today, they continue to be a burden on the user.

Setting up any browser to support both H.264 and Ogg Theora requires at least one plug in, which harms the user experience.

“It’s hard today to ask people to install a plug-in unless the payoff is huge,” he says. “What’s driving the most successful plug-in, which is Flash, is video support. If you can’t see YouTube, your life on the web is pretty miserable. You’re missing a lot.”

Plug-ins aren’t just harder on web users, but they’re hard on web developers, too.

“Building with Flash or Silverlight in a way that lets you share information between the content appearing inside the plug-in and the rest of the page presents some challenges,” says Le Hegaret.

Unlike its predecessor, HTML5 has been designed with web applications in mind. The current HTML5 specification includes a media API that makes it easier to connect animations or video and audio elements — things traditionally presented within a Flash player — with the rest of the content on the page.

“You get a smoother application if you use HTML5. You’re not crossing a software layer. It’s all part of the same application.”

Unfortunately, the YouTubes of the world aren’t going to make a baseline switch from Flash to HTML5 unless they know there’s strong support for it in the browsers.

But they are testing the waters: Wikipedia is experimenting with HTML5 video support by serving Ogg Theora video to browsers that can handle it, and Flash to everyone else. YouTube and the video site Dailymotion have also set up special demo pages using this technique.

Le Hegaret says we’ll be in this period of transition — a dual-experience web where content sites serve HTML5 video along with a Flash fall-back — for a while.”

Web developers will continue to have to understand that not everyone is using the latest generation web browser, and that’s OK in the short term.”As far as being able to make the switch to a pure HTML5 web altogether, Le Hegaret says that’s only possible once browser vendors sort out their differences.

Once that day arrives, the final switch to HTML5 will be in the hands of the content providers. It’s up to them to begin coding for HTML5 standards and ditching support for old browsers.”

There are still a significant amount of people out there using IE6,” says Le Hegaret. “As a developer right now, you can’t really ignore it. Hopefully, in two or three years, you will be able to start ignoring IE6.”

See Also:

File Under: Events, HTML5, Web Standards

Tim Berners-Lee Sees Promise, Challenges in HTML5

SANTA CLARA, California — The man credited with founding the world wide web is both excited and cautious about its future.

Sir Tim Berners-Lee, the British physicist who first designed the way web servers deliver pages to web browsers nearly 19 years ago, sees great promise in HTML5, the much-anticipated rewrite of the language used to build web pages.

“I think (HTML5) is great,” he said at the Worldwide Web Consortium’s (W3C) annual member gathering, taking place here this week.

HTML5 is a mixture of several different technologies that allow content creators to do more with web pages. It defines rules for presenting video, audio, mathematical equations, complex layouts, 2-D animations and non-standard typefaces. Each bit of technology has its own working group within the W3C chartered with developing that one component.

“We’ve had the pieces for a while,” he says. “Seeing all these things finally coming together is exciting, and it multiplies the power of each one,” Berners-Lee says.

HTML5 also enhances the way browsers can store and process data, which has led to the creation of more complex and rich web applications that run in the browser like Gmail, Facebook and apps that allow real-time data sharing, like Google Wave.

“Yes, this is a markup language for web pages,” he says, “but the really big shift that’s happening here — and, you could argue, what’s actually driving the fancy features — is the shift to the web becoming a client-side computing platform.”

The HTML5 specification is close to completion. The most recent releases of browsers like Firefox, Chrome, Safari and Opera all support most of the technologies being rolled in to HTML5. Microsoft’s Internet Explorer supports fewer of HTML5′s advancements, but it’s catching up. HTML5 is expected to become an official recommendation by late 2010 or 2011.

Now that the web has been elevated to a more powerful computing platform by HTML5, Berners-Lee says it has also given rise to complicated security issues.

“You got a piece of code from site A, and you’re person B running a browser you got from company C, and that code wants to access data stored with company E for the purposes of printing it on a printer owned by company D — How do you build that so that it’s not susceptible to all kinds of nasty attacks?”

“The technology is very exciting, but there’s actually a lot of work to do in these corridors to make it work on the real web in a secure way.”

See Also:

Microsoft Wants to Separate the Canvas 2D API from HTML5

In an e-mail sent to the mailing list on Wednesday, Microsoft’s Eliot Graf proposed removing the Canvas element, which is used to create complex vector animations in the browser without plug-ins, from the HTML5 specification. Graf also proposed launching a new, separate specification for the Canvas 2D API.

His e-mail:

In his mail describing why he created a separate Canvas 2D API specification, Doug Schepers wrote [1]:

> There is a chance that currently Canvas could be a blocker on progress

> for the HTML5 spec, and at this point, Canvas is so widely implemented

> that I don’t think it’s at risk, so I hope this isn’t disruptive. I am

> available to help with any editing that needs doing, but I hope that

> others will also work with this draft, and step into the editor role.

At Microsoft, we agree with the sentiments expressed by Doug, Maciej [2], and others about creating a separate Canvas 2D API specification. [3] We are prepared to offer editorial resources to aid in the completion of this separate specification. We have looked over Doug’s initial document, made some editorial enhancements, and are prepared to follow through in taking feedback and maintaining the specification.

We believe that some sort of accessibility API functionality is needed in the canvas element. However, the exact nature and depth of that functionality presents a dilemma that may block progress on the HTML5 spec. We also think that the Canvas 2D API may be a desirable feature used in other technologies such as SVG.

Starting with Doug Schepers’ initial draft, we made changes to get the document to adhere to the W3C PubRules [4], enhance readability, and improve logical flow of the document. In addition, we foresee adding sample code throughout the specification, where appropriate. No normative changes have been made. As with all drafts, the Canvas 2D API specification is still a work in progress. We would like to solicit feedback about the changes that were made (see below TODO) and about further changes that the working group would like to see.

Our updated version is published at






Microsoft Internet Explorer is the only modern browser with no plans to support Canvas — Firefox, Chrome, Safari and Opera all do. Redmond’s opposition makes sense, as the animation capabilities Canvas provides would conflict with Microsoft’s plans to speed adoption of its Silverlight platform, which affords web authors many of the same capabilities using a proprietary plug-in and commercial development software.

Several list members pointed out that if Microsoft has the resources to author the spec independent of HTML5, those resources could be better spent building support for Canvas into the browser.

A follow-up response from Ian Hickson, a Google employee who is the primary editor of the HTML5 spec, points out a few clear problems with this strategy and stresses that it doesn’t seem list a good idea:

IF we’re going to split out the 2D API — and I’m not really sure if at this point that’s something we should do, frankly — then I would much rather we do it based on the text in the HTML5 spec now, and would much rather we have an editor who is able to give this the full-time attention that it needs.

However, I’m really not sure at this point that it even makes sense to extract the API anymore. The API intergrates pretty tightly with the rest of HTML, for example it refers to HTMLVideoElements, the HTML5 “structured clone” feature is defined in terms of canvas interfaces, and so on. There would have to be a two-way reference, which would be a maintenance nightmare, and which would just delay the progress of both documents.

What are the problems that we are trying to solve by splitting out the API at this point?

The whole thread, which is still growing, can be viewed here.

What do you think? What’s Microsoft up to?