Business Tech

3D graphics became ordinary first in games, then in operating systems, and on Thursday, it took a significant step toward being built into Web browsers as well.

The Khronos Group, which oversees the OpenGL graphics interface, announced that its work with Mozilla to bring hardware-accelerated 3D graphics to the Web has reached draft standard form. The standard, called WebGL, lets programmers who use the Web's JavaScript language take advantage of the fact that video cards can handle 3D graphics with aplomb.

The group now wants commentary from Web developers and others who might be involved with WebGL so it can be finalized. "I anticipate us moving toward a spec that is not provisional, not merely a draft, in early 2010, the first quarter," said Arun Ranganathan, chairman of the WebGL working group and standards evangelist at Mozilla.

Internet Explorer remains the dominant browser in terms of usage, but all four of its main challengers--Mozilla's Firefox, Apple's Safari, Google's Chrome, and Opera Software's Opera--are working hard, sometimes in an informal alliance, to get ahead by advancing the Web state of the art.

WebGL fits into that effort, and not just academically. All four of those browser makers have endorsed WebGL, and developer test versions of Firefox, Safari, and Chrome have it built in. Microsoft declined to comment for this story beyond reiterating its general support for standards.

Ultimately, building 3D support into the Web could advance user interfaces of Web applications--including games, the popularity of which can be a powerful incentive for upgrading to the latest technology.

It's not clear exactly how it will play out, though, Ranganathan said. The arrival of Canvas, an advanced 2D interface for browsers, has led to a blossoming of graphics work, and he expects a similar change with 3D graphics.

But don't hold your breath for Web-based first-person shooters that rival native applications. First, even if 3D is accelerated, there are plenty of other processing and user interface constraints on Web applications. Second, even after WebGL is standardized, it must be built into browsers, people must upgrade to those new versions, and programmers must learn how to support the technology.

WebGL isn't the only 3D Web work under way. Google has its own O3D project, which currently is a browser plug-in but that the company also is building directly into Chrome.

O3D is a higher-level interface, though, not a direct competitor. Details are technical, but O3D uses a retained mode approach to WebGL's immediate mode interfaces.

And of course, a decade ago there was VRML--virtual reality modeling language, a file format rather than interface. A VRML successor called X3D, though, can actually make use of WebGL, and indeed a project called X3dom aims to do just that.

Sometimes it's the little things that count.

The most prominent feature of Firefox 3.6 is Personas, which let you reskin the browser with thousands of different looks. But my single favorite change is a subtler change to the open-source browser's user interface.

Specifically, when you open a link in a new tab, it appears immediately to the right of the active tab. Before, the new tabs would appear to the far right of the strip of tabs.

Yup, that's it. For those of us who spend hours a day in a browser, though, the new tab behavior helps group related tasks together. I constantly shuffle among dozens of tabs, and the new approach automatically brings some organization to my cluttered life.

However, I know it's not everybody's favorite browser behavior. So along with explaining why I like it, I'll also take some potshots and share instructions on how to get the old way back.

Why it's better
The more things I do with a browser--and the number has increased steadily for years now--the more important it becomes to be able to find different tasks amid the chaos. Microsoft and Apple understand this, as evidenced by the new taskbar features in Windows 7 and dock expose in Mac OS X 10.6, aka Snow Leopard. Those features make it easier to pluck out the one window you need from among the many you may have open.

There's a pattern to how I spawn the dozens of tabs I use as a day progresses. On a variety of pages--Gmail, Google Reader, Yahoo Finance, somebody's blog post--I'll encounter a host of links to other pages. I'll middle-click my mouse button to open interesting pages as background tabs, then use Ctrl-Tab to switch to the new pages when I'm ready. I repeat this pattern many times a day.

With the old behavior, each tab appeared to the far right of the tab strip. That's fine when getting started, but when I've moved halfway across the list and want to open another batch, I want the new ones--call them children--to open next to their parent tab. When I go away and come back, or when I lose place juggling tasks, it's easier to find my bearings again.

It's like being in a library. When you're in the European history section, you don't want to find books on rewiring your house and on vegetarian cooking.

As a longtime Firefox user, I didn't realize tab positioning could be better. When I started using Google's Chrome, which introduced the new tab behavior to me, the scales were lifted from my eyes. I immediately could get to the next tab with a quick press of Ctrl-Tab on the keyboard rather than have to use the mouse to click over to the far end of the list. I use both browsers daily, but until the Firefox 3.6 beta arrived, the new-tab position had become a sore point for me when in Firefox.

The change is actually a big deal in a couple ways. First, even seemingly minor changes in software can be disruptive. Old habits die hard, and computer users wrestling with constant change can get angry when more is foisted upon them.

Second, though, browsers are assuming an ever greater role in what people do in their personal and professional lives, and keeping one's bearings is commensurately important. That's especially true for those people for whom a gaggle of browser tabs represents a collection of chores going on in parallel.

Internet Explorer 8 categorizes related tabs by color.

(Credit: Screenshot by Stephen Shankland/CNET)

How the competition handles it
Tabs are now universal among browsers, but new-tab behavior isn't. Firefox and Chrome handle it the way I like best, but how do others tackle the issue?

First, let's look at Internet Explorer 8. Microsoft showed it understands some of the challenges of tab management in its latest version of its browser by coloring child tabs the same hue as their parents, but I have a gripe with how it works. Specifically, although child tabs get the same color as their parents for easy grouping and arrive to the right, grandchild tabs are the same color as child tabs. Similarly, grandchild tabs appear to the far right of the whole group of child tabs.

In my mind, I consider grandchild tabs a separate group from the child tabs. But with IE, grandchildren get the same color and position treatment as children. The only way to get a new color is to start a fresh empty tab There's no easy way to give grandchildren a new color without causing some confusion, though--should the child be the same color as the original parent or change color to be grouped with the grandchildren?

Next is Opera, which gives users a choice. By default, it opens new tabs to the far right, which I don't like, but in the Advanced|Tabs section of the preferences dialog box, you can check "Open new tab next to active." Huzzah!

There's a subtle change here I don't care for, though. Tabs always appear immediately to the right of the active tab. I'd rather have all one tab's children appear in sequence to the right. For example, if a parent tab is in position 1, then the first child would be in position 2, the second in position 3, and the third in position 4. Opening three child tabs in Opera leaves the parent in position 1, the third child in position 2, the second child in position 3, and the first child in position 4.

Last, there's Safari. It does it the old way I loathe with no option to change. Too bad.

Firefox can show thumbnail previews of new tabs, but I find them hard to recognize in front of busy Web pages.

(Credit: Screenshot by Stephen Shankland/CNET)

Why it's not enough
Most browser makers are excited about the fact that their software is subsuming more and more computing tasks that previously ran on computer operating systems. But as browsers inherit this central importance, they also inherit some of the hassles.

The new tab positioning behavior in Firefox is a step in the right direction, but there's more that needs to be done. Moving from one tab to a related adjacent one, whether through a keyboard command or mouse clicking, is a minor change. But things get harder when you need to switch from one group of tabs to the next.

There's work under way here. Opera is perhaps the leader with the ability to show thumbnails as you use Ctrl-Tab to cycle your list of open tabs.

Firefox has been noodling with the approach too. It tried then dropped tab thumbnail previews earlier, but the technology is still present. Using the about:config system for tweaking the browser (more on this later), you can change the "browser.ctrlTab.previews" setting to "true."

But for reasons that aren't clear to me, I don't find this effective either in Firefox or Opera. Perhaps I haven't used it enough, or the thumbnails are too small to be immediately recognizable, or they're just hard to see against the noisy background. There's a good reason that Apple dims the background most of the way to black when using Expose.

Aero Peek in Windows 7 lets the task bar show a glimpse of Firefox and IE tabs.

(Credit: Screenshot by Seth Rosenblatt/CNET)

Windows itself is helping, too. The new taskbar in Windows 7 can show individual tabs, once browsers support the feature. It's in Internet Explorer 8, and it's in the new Firefox 3.6 beta.

Add-ons such as Firefox Showcase can further tweak Firefox. (Indeed, for a wealth of options, check Mashable's handy Firefox tab management guide.)

More interesting to me, though, is work under way to expand Firefox's "awesome bar" abilities. Today, typing in it opens Web pages and retrieves ones you've already visited or bookmarked. In the future, it could be able to move you to another open tab, too. I'm a keyboard guy, so particularly appreciate this idea.

You can get a taste of the idea now. If you've enabled the "browser.ctrlTab.previews" option, hitting Ctrl-Shift-Tab will not only show you thumbnail previews, but will put a cursor in a search box.

Typing the letters of the Web page name will winnow down the thumbnails. For example, typing "netap" will cull my open tabs so only Net Applications and NetApp show. If you have a bunch of similar tabs all open, this might not help much, of course.

However, the feature only works with the tabs of one browser window, so if you can't use it to search among other browser instances.

How to get the old way back
Perhaps I've convinced you that the new approach is better. But perhaps not--in which case I encourage you to share your thoughts in the comments so people will hear more than my opinion.

For those who don't like the new tab positions, you can revert to the old method.

To get the old style back for new tab position, use Firefox's about:config system.

(Credit: Screenshot by Stephen Shankland/CNET)

First type "about:config" in the Firefox address bar. You'll get a warning that you're tinkering with Firefox's innards and you should be careful, but this isn't brain surgery, so don't be frightened. Click the "I'll be careful, I promise" button, and you'll see a big list of all the browser settings that can be tweaked.

Next, in the text box labeled "Filter:", type "tabs.insertRelatedAfterCurrent"; you should see just one entry below. In the column marked "Value," double-click on the word "true" to change it to "false." You're done.

But I'd encourage you to at least give the new way a try. If you don't like it, you can always change back.

Google's Chrome is still the fourth-place browser in terms of usage, but it gained more than others in October when it comes to stealing usage away from the dominant Internet Explorer.

According to Net Applications' browser usage share statistics, Chrome gained from 3.2 percent to 3.6 percent from September 2009 to October. The company bases its statistics on visits to a global network of 40,000 Web sites, dusted with some statistical processing.

Next was Mozilla's Firefox, which rose from 23.8 percent to 24.1 percent. Apple's Safari rose from 4.2 percent to 4.4 percent. Opera was essentially flat at 2.2 percent.

The big loser was IE, which dropped from 65.7 percent to 64.6 percent, according to the statistics.

Internet Explorer rivals generally gained market share in figures from July, shown at top, and August.

(Credit: Net Applications)

After resetting its methodology to better account for global variations, Net Applications' browser usage statistics have resumed an earlier trend in which Internet Explorer's main rivals edged ahead.

Mozilla's Firefox had the most notable gain, from 22.5 percent to 23 percent, while Google's Chrome rose from 2.6 percent to 2.8 percent. Apple's Safari was flat at 4.1 percent, and IE dipped from 67.7 percent to 67 percent. Opera, in fifth place just before this week's release of Opera 10, was essentially flat at 2 percent.

The browser wars are back in full swing. Though IE remains dominant, rivals are racing to build in new features to make the Web a better foundation for applications--the vision Netscape had back in the first generation of browser wars of the 1990s. Only recently has Microsoft joined the HTML 5 discussion in earnest.

This time profitable powerhouses such as Google are pushing this Web applications facet of cloud computing, and even Microsoft is embracing the trend with an online version of Office en route. Using the browser and the Web to run applications has a lot more meat on its bones after a decade of work.

Microsoft is working to wean the world from IE 6, the version of the browser that shipped with Windows XP, and has made some progress, according to Net Applications' statistics.

Version 6 still rules the IE roost, but it's dropping in usage.

(Credit: Net Applications)

IE 8 usage increased from 12.5 percent to 15.1 percent usage from July to August, while IE 6 dropped from 27.2 percent to 25.3 percent. IE 7 decreased from 23.1 percent to 21.1 percent.

Mozilla's newer version 3.5 of Firefox, released in June, also made gains from 4.5 percent to 8.9 percent. Firefox 3.0 dropped from 16.2 percent to 12.5 percent.

Using a modern browser is important when it comes to bringing the Web application technology to fruition. Older browsers lack support for advancements in page layout and graphics, HTML features such as built-in video, and perhaps most crucially, fast execution of Web-based JavaScript programs.

Net Applications changed its methodology, with Apple faring worse in the new statistics and Opera and Chrome getting a boost. These figures are for July.

(Credit: Net Applications)

Apple's share of the installed base of Web browsers has plunged in half--but because of a methodology at a firm that produces the statistics rather than anything Apple or computer users did.

Net Applications, which compiles statistics based on the 160 million unique visits to a network of 40,000 Web sites using its analytics service, dramatically lowered Apple's browser share when the firm concluded its methodology needed refining. Specifically, the company concluded that there was a disconnect between visits to its site network and actual Web use in some areas such as China, said Vincent Vizzaccaro, executive vice president of marketing.

To try to better reflect reality, the company adjusted its statistics through use of the CIA's estimates of Internet population, according to its explanation. Consequently the company took a month to change course then released updated statistics from May and earlier that dramatically changed some figures.

I'd personally like to offer browser makers my gratitude for realizing that my screen isn't big enough.

I'm one of those people who wants every bit of display real estate I can get. The more I can see of the document I'm writing, the in-box I'm scanning, and the photo I'm editing, the happier and more productive I am.

The maximize button is my friend. Toolbars are my enemies.

So I'm happy to report that browser makers are paying new attention to the issue. It's important to me for reading Web sites, but it's really important to me for the new generation of Web applications. A row of pixels saved once in the browser is returned again with each Web-based application.

Mozilla's ultimate goal is to make the user interface step into the background as much as possible--indeed, the mobile-phone version of Firefox now under development has no visible user interface until it's needed. "Every time a user has to think about how to do something, instead of what we want to do, we as software creators have failed," said Aza Raskin, Mozilla's leader of user interface work.

But it's not simple to redesign the browsers. Users can be confused when interfaces change, some controls are essential, and hiding them can cause problems.

"The challenge to reducing UI (user interface) is in recognition versus recall. People generally use what they see," Raskin said. "How can we provide one-click access to everything possible on the Web without also cluttering the screen? That's a question we are still answering."

Microsoft's case is illuminating. Its Internet Explorer 7 hid the menu bar, though it could be revealed by pressing the Alt key, but IE 8 shows menus by default. (It can be hidden again by default if people choose, and I do.)

Reclaiming real estate
There's been some work in this area for years. For example, hitting the F11 key in Windows puts Firefox into a full-screen mode, hiding title, menu, address, and tab bars. And Microsoft's Internet Explorer 7 hid the menu bar, though it could be revealed by pressing the Alt key; IE 8 shows menus by default again, though it can be hidden again by default if people choose, and I do.

But now the pixel reclamation effort is taking off in earnest. The big statement came in September 2008, when Google revealed its Chrome browser--ironically named because it aims to move the user interface elements, called chrome, as much into the background as possible.

Chrome wiped out the title bar altogether and arrayed its browser tabs in the newly freed space. It also wiped out the menu strip and tucked the options into two drop-down menu buttons to the right of the address bar. Information that would show in a status bar, such as the actual URL of a Web address you're hovering your mouse over, appear in a temporary box that appears on the lower left. When you search a Web page, another small window appears in the upper right. (Chrome looks somewhat different on Mac OS X, which always uses a menu bar at the top of the screen that's detached from the browser Window itself.)

An example of Chrome's latest interface on Windows.

(Credit: Screenshot by Stephen Shankland/CNET)

Chrome on the Mac can't free up the menu bar real estate, so it looks different than on Windows.

(Credit: Screenshot by Josh Lowensohn/CNET)

Missing at launch was a full-screen mode, but Google rapidly filled in that gap. This max-screen ethos is one reason that Chrome, at present at least, is my default browser.

Another change came with Safari 4 from Apple. Like Chrome, it added the two-button menu icons toward the upper right. Unlike Chrome, it sports a traditional menu bar as well, though with the Windows version it can be hidden to free up some real estate.

Safari 4 lets you hide the menu bar--but between the beta and final versions, Apple moved the tabs to the more conservative position immediately above the browser Web page.

(Credit: Screenshot by Stephen Shankland/CNET)

Unfortunately, in my opinion, Apple backed off from another change between the Safari 4 beta and final version. Initially, the browser sported tabs in the title bar, like Chrome, but Apple later moved them into the more conservative position immediately above the Web page.

The next move comes from Mozilla, which leads development of the Firefox browser.

With the dash to release Firefox 3.5 now over, developer attention again focuses on the future. Last week, mock-ups of Firefox 3.7 arrived to trigger discussions of what the final interface should look like. On display were two Chrome-like characteristics: the two menu icons and the missing menu bar.

Shortly afterward came the Firefox 4.0 mock-ups, moving the tabs to the title bar in one option that's even more Chrome-esque.

This Firefox 4.0 mock-up shows a very Chrome-like interface.

(Credit: Mozilla)

One of the big assets Firefox has is its extensions system, which can be used to customize the browser. One I like is autoHideStatusbar, which reclaims the status bar real estate except when I need it in order to see where a link on a Web site leads. I also use Tree Style Tab to move tabs off to the left; I typically need vertical space more than horizontal.

In the same vein, those who were enamored of the Firefox 3.7 mock-up look can try it themselves in the real world with a three-step change LifeHacker put together.

The Web app era
How all these changes will shake out isn't clear yet. But what is clear is that influential developers believe thin frames are better than thickets of icons, menus, bars, and boxes.

The Web application trend is one reason this trend is important.

Consider for a moment Microsoft Word. Especially when the newer version's ribbon of icons is active, it requires a fair amount of area to house its controls.

Now consider Google Docs, which must add its word-processing user interface elements with those already present for the browser itself. Those using the application must bear a double burden. It's like going back to the era of 800x600-pixel displays.

Now factor in the Web application future--Picnik for photo editing, Zoho for office productivity, Bespin for programming, even Microsoft Office soon. These applications are increasing in number, sophistication, and importance, even if they aren't replacing desktop applications as soon as Google Chrome OS developers might hope.

A little bit of screen real estate saved in the browser is multiplied many times over across this range of applications. And of course, conventional Web browsing can benefit, too, offering the possibility of more information and less scrolling to get to it.

It takes real work to pare back a user interface without impairing software's utility. But until the day arrives when my screen is displayed on an entire office wall or directly on my retina, I'll hoard every pixel that browser developers can give me.

XHTML 2, we hardly knew you.

XHTML 2, a technology intended to build a more powerful Web from the ground up, met a quiet end last week, spotlighting the difficulties of standardization in a fast-moving Internet. Introduced in 2002, XHTML 2 was a centerpiece of standards work at the World Wide Web Consortium (W3C).

But incompatibility with the existing Web and a direction at odds with Web developers' desires doomed it to a slow demise. On Thursday, after a long reconciliation with browser makers who'd struck off in a different direction, the W3C announced that it will wind down development of XHTML 2 this year.

Ultimately, Web browser makers had the upper hand in charting the Web's future.

(Credit: Stephen Shankland/CNET)

Instead, the group will channel those resources into standardizing what the browser makers have been toiling on all these years: HTML 5, a sprawling collection of new features to improve the present Hypertext Markup Language. Although elements of XHTML 2 will live on in HTML 5, overall, the browser makers prevailed.

"XHTML 2 was a beautiful specification of philosophical purity that had absolutely no resemblance to the real world," said Bruce Lawson, HTML 5 evangelist for browser maker Opera.

So what went wrong? In short, the Web has many masters, but the ones with final say over its nature are those who build it page by page, not the standards group trying to create a new foundation.

XHTML 2 was designed to reform the Web as a medium for publishing documents, but the developers--and the browser makers who listened closely to those developers--instead wanted a platform for interactive applications. And while that direction prevailed, its incarnation in HTML 5 faces its own set of challenges now.

The consensus for HTML 5 support has been building for years, and the W3C already had been increasing its involvement in its standardization well before it decided to put an end to much of the competing XHTML 2 standard. Although the HTML-XHTML split has been fractious at times, there's inescapable tension between standards groups trying to chart the future and vendors whose products relate to those standards.

"I will not say it's been the smoothest way of doing things, but it's not an unnatural way for things to proceed," said Mike Smith, leader of HTML work at W3C, speaking of the reconciliation process that rejuvenated the W3C's HTML work. "Vendors are the ones who drive innovation on the Web for the most part."

Why XHTML?
So if it's so clear today that HTML 5 is the way to go, why was so much energy, time, and research invested in XHTML 2? It was an attempt start afresh without HTML's shortcomings.

The X in XHTML stands for XML, which in turn stands for Extensible Markup Language. XML is a broad technology that uses a strict set of tags to label different types of content in a document, and XHTML was engineered specifically for the Web. XHTML brought rigor to the loosey-goosey and slap-dash world of HTML, and it would have permitted developers to employ a broader range of computing engines called parsers to digest and process the XML, Smith said.

XHTML "was a cleaner and better-architected version of HTML," Smith said. And in its earlier years, it had support. "At the time when XHTML 2 was first conceived and specified in the early drafts, most everybody thought it was a good idea. A lot of people in hindsight want to look back at it now and make the claim that they knew it wasn't going to have success," Smith said.

XHTML 2.0 made it to working draft stage, but only parts of the specification will live on in HTML 5.

One example of its utility is the tight coupling of textual information with a graphs encoded with the SVG, or Scalable Vector Graphics format, Smith said. Another advantage was better browsing with the limited abilities of mobile phones.

One of the big problems with XHTML 2 was that it wasn't backwards compatible, though. Not only could it not be used to display existing Web pages, but Web browsers had to be expanded with an entirely new engine for handling the XML. Notably, Microsoft's Internet Explorer, the dominant browser by far, couldn't handle XHTML on its own.

Another problem was that there was plenty of demand for improvements to HTML, which W3C had declared finished with version 4.01 in 1999.

"People were so focused on XHTML 2 that they were substantially less interested in modifying the application model and introducing new features to HTML that developers were clamoring for," said Arun Ranganathan, standards evangelist for Mozilla, the organization behind the Firefox browser. "We felt the standards going on at the time...were disconnected from a large majority of developers.

Microsoft agrees with its browser rival.

"We've never heard a strong request from our developer audience and customers for XHTML 2," said Amy Barzdukas, general manager for IE.

Enter WHATWG
One crucial moment came five years ago when Opera and Mozilla representatives showed the W3C an idea called WebForms for improving HTML. "We jointly presented this paper to W3C, who rejected it," Lawson said.

Mozilla's Brendan Eich and Opera's Ian Hickson were displeased with how things went. "The best way to help the Web is to incrementally improve the existing web standards," concluded Eich, founder of the JavaScript Web programming language, after the meeting in a blog post.

Eich also announced there an Opera and Mozilla plan to take that evolutionary route. They launched an open e-mail list called WHATWG, short for Web Hypertext Application Technology Working Group. Apple, which offers its own Safari browser, soon began participating, too.

"It became a de facto standards organization without the formality of W3C. It's where we went to figure out what the future of the Web was," Ranganathan said.

Eventually, the Web-application direction won over the W3C. "Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally," said Web founder and W3C Director Tim Berners-Lee said in 2006.

But Berners-Lee at the time also maintained the commitment to the "well-formed," more rigorous XML-based future: "It is important to maintain HTML incrementally, as well as continuing a transition to well-formed world, and developing more power in that world."

In practice, the W3C world and WHATWG world involve many of the same people. That probably eased the reconciliation to the current state, where WHATWG and W3C operate simultaneously, the first more informal and the second with more careful handling of intellectual property concerns.

Ultimately, HTML carried the day. What began with interest in more sophisticated Web sites such as eBay blossomed with the arrival of Ajax, which used JavaScript to build more sophisticated Web-based applications. And Web applications weren't just theoretical ideas.

"When Gmail and Google Maps and Ajax came along, it became really clear we needed a new set of technologies that made it easier to make those kinds of applications," Smith said.

The transition culminated with W3C's bare-bones news last week: "Today the director announces that when the XHTML 2 Working Group charter expires as scheduled at the end of 2009, the charter will not be renewed. By doing so, and by increasing resources in the HTML Working Group, W3C hopes to accelerate the progress of HTML 5 and clarify W3C's position regarding the future of HTML."

Some features of XHTML 2 will be built into HTML 5, so the XHTML 2 work won't have been for naught, assuming a critical mass of browser makers do in fact include the necessary XML parser along the HTML parser.

HTML 5: no walk in the park
Though the W3C-WHATWG dust has mostly settled, the standard is far from finished, and indeed looks a long way off.

The present approach involves a give and take between browser makers trying out new features and the standards group codifying them. Features can't make it to the ultimate W3C state, "final recommendation," until at least two browsers support the feature compatibly, Smith said.

In practice, that means adventurous Web developers who choose to support the new technologies in effect are blessing them even though the technology might well change.

HTML 5 elements came from all over. Canvas, which involves two-dimensional graphics, began at Apple's Safari and now has won over Opera, Firefox, and Google's Chrome. ContentEditable, which lets Web pages be edited in place, came from Microsoft. Google now is working on a faster communication feature called Web Sockets. Programmers for WebKit, the open-source project underlying Safari, are developing DataGrid, which brings spreadsheet-like tables with sorting and editing to Web pages.

"The speed of the web is continuing to pick up in general," Barzdukas said. HTML 5 feature support figures prominently in the browser sales pitches from Google and from Mozilla, with its "upgrade the Web" tag line for Firefox 3.5.

Actual standardization, though, remains distant. Mozilla's Ranganathan hopes for drafts of some HTML 5 elements this year and a draft of the full specification in 2010.

The HTML 5 built-in video situation is illustrative. Hickson, the HTML 5 editor and now Google employee, posted a lament about HTML 5 video last week because browser makers don't agree on whether to support the patent-free Ogg Theora format, preferred by Opera and Mozilla, or the commercially popular H.264 format, preferred by Google and Apple. The upshot for now: HTML 5 is trying to standardize video but doesn't specify which format to be used.

That pace of HTML 5 standardization important, given the importance Microsoft places on supporting actual standards and the company's commanding market share.

"The support of ratified standards (that Web developers) can use is something that we are extremely supportive of," Barzdukas said. "In some cases, it can be premature to start claiming support for standards that are not yet in fact standards."

The SunSpider test shows Tracemonkey-enabled Firefox leading the newest Chrome build in JavaScript performance--for now at least. Test results reported in seconds, so smaller is better.

(Credit: CNET News)

Correction 12:00 p.m. PDT: This report has been updated to reflect Firefox performance with the TraceMonkey JavaScript engine enabled, in which case Firefox is fastest at the SunSpider test.

With new beta versions out for Firefox and Google Chrome, I thought I'd see how things have changed when it comes to testing the speed of JavaScript, the programming language that powers many cutting-edge Web applications such as Gmail and Google Docs. The answer: both browsers made big strides, but Firefox still beats Chrome on one widely-used performance test.

When Chrome was released, I ran Google's JavaScript speed test on Firefox 3.0.1, the initial Chrome beta, Internet Explorer 7 and 8 beta 2, and Safari 3.1.2. Chrome led the speed test with an overall score of 1,851 and Firefox in second place at 205. A bigger score is better on this test.

Running the same test on the latest developer version of Chrome, 0.3.154.3, boosted the browser's score to 2,265--a 22 percent increase. And Firefox jumped 15 percent to 235. Firefox 3.1 beta 1. However, that test measures Firefox without its new TraceMonkey JavaScript engine enabled; a bug in TraceMonkey trips up the test by invoking a print dialog box. (There aren't any new versions of Safari or IE to test, though Safari likely will see a boost from its earlier score of 170 from the SquirrelFish Extreme JavaScript engine.)

In September, Firefox backer Mozilla countered Google's benchmark suite, spotlighting Firefox's superior results using the SunSpider speed test. Here, TraceMonkey works, and Firefox maintains its lead over Chrome and the others.

The newest Chrome beta is 22 percent faster on Google's own JavaScript benchmark. Firefox's performance score increased 15 percent--but that doesn't factor in TraceMonkey, because a bug breaks this test.

(Credit: CNET News)

I couldn't run SunSpider when Chrome was released because the site was out of commission that day, but it's up and running again now, so here's the latest results for the four browsers--and bear in mind here that a smaller score is best for SunSpider: TraceMonkey-enabled Firefox led with a score of 2,257; Chrome was second at 2,904; Firefox 3.1 beta 1 with no TraceMonkey next with 4,233; Safari 3.1.2 followed at 6,351; and IE 8 beta brought up the rear with 9,025.

Mozilla's Mike Shaver said the bug that impairs the Google JavaScript test--one reason TraceMonkey isn't enabled by default--should be fixed "soon." For those who want to try the their own tests, Tech-Recipes has useful instructions on how to enable TraceMonkey.

Why you should care
Why does all this matter? A few reasons.

First of all, JavaScript is widely used in innumerable ordinary Web sites, and Internet companies have found that even small improvements in Web page responsiveness increases user interaction with their sites. A snappier response is better for everyone.

Second, for the more avant garde, JavaScript powers many sophisticated Web sites and Web-based applications, endowing them with features such as drag-and-drop, pop-up dialog boxes. Faster JavaScript means companies such as Zoho, Google, and Yahoo can build more features into the Web applications and that users will find those applications easier to use. And these more interfaces are spreading to mainstream sites, too.

Last, on the programming front, JavaScript is vying with other technologies for building rich Internet applications. Microsoft steers developers to Silverlight, Adobe Systems continues to improve its Flash and Flex technology, HTML itself is getting more powerful. And of course there's the larger competition between Web-based applications and those that run directly on the PC, such as Microsoft Office.

A final note: The same benchmark caveats apply this time around, too. Your mileage may vary--my tests were on a dual-core Lenovo T61 with Windows XP. There are other performance attributes that affect Web browsing besides JavaScript performance. And even in the narrower realm of JavaScript, benchmarks like these don't necessarily represent the workloads that will have you pining for a faster machine.

Google introduced Chrome in part because it wants faster browsing and the richer Web applications that speed will unlock. So how does Chrome actually stack up?

Google's Chrome overpowers the other browsers on the five subtests by which Google measures its browser's JavaScript performance.

(Credit: Stephen Shankland/CNET News)

Lars Bak, the Google engineer who was the technical leader for Chrome's V8 JavaScript engine, said at the launch event Tuesday he's confident Chrome is "many times faster" than the rivals at running JavaScript, the programming language that powers Google Docs, Gmail, and many other Web applications.

But when pressed for specifics, he told me to try them out. So I did.

Google offers a site with five JavaScript benchmarks. On each one of these tests, Chrome clearly trounced the competition. I hope benchmarking experts and developers will weigh in with comments about how well these tests represent true JavaScript performance on the Web--either for ordinary sites or for rich Web apps.

Here's the site description of the speed tests:

• Richards: OS kernel simulation benchmark, originally written in BCPL by Martin Richards (539 lines).

• DeltaBlue: One-way constraint solver, originally written in Smalltalk by John Maloney and Mario Wolczko (880 lines).

• Crypto: Encryption and decryption benchmark based on code by Tom Wu (1,689 lines).

• RayTrace: Ray tracer benchmark based on code by Adam Burmister (3,418 lines).

• EarleyBoyer: Classic Scheme benchmarks, translated to JavaScript by Florian Loitsch's Scheme2Js compiler (4,682 lines).

Google's overall score is head and shoulders above the competition for executing JavaScript.

(Credit: Stephen Shankland/CNET News)

A few notes: First, your mileage may vary; I ran these tests on my dual-core Windows XP machine.

Second, my apologies here to Opera, whose browser I don't have installed.

Third, I tried to run the SunSpider benchmark tests as well, but perhaps because a lot of other curious people had the same idea on the day Chrome launched, I couldn't get to the site.

Click here for full coverage of the Google Chrome launch.