Browser as information broker

The phrase "browser as information broker" has been around for a year or so, and finally some of the vision is becoming reality.

My interpretation of that vision is that the browser will link data on a webpage to services that consume it. For example, if a date appears on a page you're browsing, you could drag it to your calendar application - or if a location appears, you can open it up in a map.

It's a powerful vision, and it's actually part of the Semantic Web mission. As Tim Berners-Lee explains, we've already gone from linking computers to linking web-pages. Now we need to take that next step - linking data.

There are three parts to solving this problem - semantics, services, and connections.

Semantics

Firstly, web developers have to mark sections of a page with meaning - this is a location, that is a date, etc, in a standard way that computers can understand.

There are several active approaches

• HTML itself has existing elements (e.g. the "unordered list" element, <ol>) which indicate meaning, and more are being added in HTML5 - e.g. the <time> element.
• HTML has several attributes, especially "class", that can be used in a semantic way. People are trying to standardise class names and HTML structure to indicate data like dates and locations; this is called Microformats.
• Groups can register protocols for various content types. For example, there is a common "mailto:" protocol in HTML links, which commonly opens up an email application. Protocols are established via internet standards.
• The W3C is pushing an ambitious new language, RDF, as the foundation of its Semantic Web vision

In the wild, the first three approaches have good momentum, perhaps because they work well with existing technologies, though they seem to compete with each other. If they hit limitations, RDF will be the obvious choice!

Services

People have to develop websites to manipulate data. Actually, a lot of this has already been done - what is Google Maps except a service to manipulate location data, or Microsoft Live Calendar except a service to manipulate dates & times?

Connections

The browser has to connect the user to relevant services when it spots data. For example, when it spots a location, it should present a nice interface that allows the user, if they desire, to view it in Google Maps.

The forthcoming Firefox 3 enables these connections for protocol handlers. It implements the HTML5 API for registering protocol handlers against a particular website, which tells the browser to use (for example) Yahoo! Mail whenever it sees a "mailto:" link.

It will be fascinating to see how this evolves. To become popular, web developers will have to be confident that high quality services exist around a protocol. What protocols will make the grade?

There are no (or very limited) automated browser connections for any of the other semantic approaches (HTML tags, microformats, and RDF). I would therefore predict that protocols will become the favoured approach to marking up HTML with extra meaning, with perhaps the exception of HTML5 <time>, which will work great with web forms.

Browsers are slow

When Safari 3 was announced, the marketing pitch centered around its 'blazing speed'. Steve Jobs even used precious keynote time explaining a chart comparing browser execution speeds for a javascript benchmark.

That was great news, mostly because it refocus debate on the current shockingly poor state of browser performance. Take any site with a bit of Ajax code, e.g. Gmail, and it's guaranteed to be far slower than a client equivalent.

In the past, javascript speed didn't matter. If you're using a dial-up modem, then the limiting factor is bandwidth, and you don't notice javascript performance. If you're accessing a Web 1.0 site with limited javascript, there won't be a delay.

But the world has moved on. Modern client applications - such as games - ruthlessly use native processing power, including rich graphics and parallel threads. Browsers just haven't caught up.

It's encouraging to see, particularly in the Mozilla community, some serious debate about how to speed things up. Work has started on Tamarin, a project to compile javascript to native code on the fly. Firefox 3 will use the Cairo graphics software library, which can take advantage of hardware acceleration. And there's been great debate about making parallel browsers.

It'll be a few years before most of these efforts come to fruition. In the meantime, Moore's law and a few performance tweaks will help a bit, but we'll be left with great web applications unwritten due to performance concerns.

Writing a browser in HTML

Browsers contain two basic components - a rendering engine (which displays HTML, CSS and javascript), and the chrome (the browser interface, including back button, URL bar, favourites, settings, etc).

Though web developers only worry about the rendering engine, users mostly care about the chrome. Tabbed browsing, the search bar, well organised history and favourites, and full page zoom controls are recent chrome innovations critical to improving the user experience.

But how do browser makers write the chrome? Not using HTML, CSS and javascript - it's like they don't trust their own code!

Instead, they use their own user interface frameworks - Mozilla, for example, has a markup language called XUL. If you look at XUL, it's pretty much a non-standard competitor for HTML5. It's been great for Mozilla until now, of course, but what's the point once you have HTML5 itself? Why maintain code for two separate markup languages?

Using HTML5 to program the browser chrome would make extensions, such as the popular Firefox extensions or even single-use applications like Prism, vastly easier to develop. They would also simplify browser code and reduce its footprint.

Finally, HTML browser chromes would be a real test of HTML5, CSS3 and javascript, overcoming the online / offline schism (the chrome appears even if you're offline) in a novel way.

As HTML5 gets stronger support by browsers, we may see a new tipping point, where HTML becomes the default user interface framework even for local client applications. We'll see an HTML browser chrome in the next few years.