Bill Gates on Personal Computing

You can tell Microsoft still don't understand the web, because they make comments like this:

IBM is no longer at the center of the computer industry, he asserted, for two reasons. First, the industry is now centered on personal computing. "As much as IBM created the IBM PC, it was never their culture, their excellence," he said. "Their skill sets were never about personal computing."

Actually, personal computing dates from the 1990s. We're now entering a different era - call it "web computing" or "social computing", where the focus is on collaboration and networks of people.

Facebook and Flickr are not personal computing - the world doesn't sit on your C: drive any more.

Times have changed, and you have to ask whether Microsoft's "culture", "excellence" and "skill sets" are keeping pace.

Multi-touch and DOM events

The iPhone has highlighted a weakness with the HTML DOM - it has keyboard events and mouse events, but nothing for touch screens.

You can try to kludge touch screens using the mouse interface, or if you're simply looking to code drag-and-drop or resize, you can wait until HTML 5 comes along and use its new attributes "draggable" and "resize".

But if this doesn't work, you're stuck. And for other user interfaces, such as accelerometers in the Wii, the situation is even worse.

Sensors

So it's time to resuscitate my sensors proposal, which provides a framework for any sensor, not just a touch screen.

What it takes is a single new HTML DOM javascript function - document.sensors() - which returns an XML document of all sensors that the page has access to, e.g.:

<sensors xmlns="http://sensors.org/namespace">
<keyboard shift="" ctrl="" alt="" ins="" value="ab"/>
<mouse x="20px" y="30px" left="down" right="none" middle="none"/>
<touch pressure="30" x="150px" y="50px"/>
<temperature value="23C"/>
<video src="file://c/program%20files/webcam/webcam.mov"/>
<accel x="2" y="0" z="0"/>
<location latitude="37.386013" longitude="-122.082932"/>
</sensors>

This document is constantly being updated with the latest values - here, you can see there is a keyboard, mouse, touch screen, thermometer, webcam, accelerometer, and GPS. The namespace would define a standard basic set of sensors, but I'm sure that extra ones could evolve over time.

So, any web designer can access the latest status of the environment, in an extensible, standard way, using javascript.

In the case of a touch screen, you could place an onchange() listener on the element, to be notified of any movement. You could also watch out for multiple elements, if several fingers hit the screen.

Security

Some of the sensory information is private, so various security measures should be in place to protect prying eyes from getting access to it. I've listed a few ideas:

• Only pages with focus can see the sensory data
• Browsers allow site-specific permission settings for each sensor
• Webcam and background sound files can't be posted back to web servers

Conclusion

The simple suggestion above provides a much more comprehensive approach to human computer interaction than today's HTML DOM events. It handles not just keyboards, mice and touch screens, but all types of sensors - from thermometers to accelerometers to webcams - in a standard, extensible way. And it brings the web into many new areas - from security cameras to production line control to satellite navigation.

CSS and XPath selectors

Many people have noticed the similarities between CSS selectors and XPath - and it's fair to say that XPath is far more powerful.

In fact, XPath can do pretty much anything that CSS can, plus much more.

select the parents of all paragraphs:

//p..

select alternate list items:

//ul/li[position() mod 2 = 0]

select table cells with a value less than 10

//tr[number(td) < 10]/td

Yet another CSS wish - XPath stylesheet selectors

No existing browsers have XPath enabled inside stylesheets. But wouldn't it be great if they did?

All it takes is a new CSS selector - XPath(string), where string is an XPath expression.

For example, selecting paragraphs containing the word 'Chris':

XPath("//p[contains(., 'Chris')]") {border: 1px solid black}

Of course, XPath doesn't itself handle pseudo-elements or pseudo-classes like :hover - but we can mix and match the XPath function with other CSS (e.g. colouring any hovered paragraphs containing two hyperlinks):

XPath("//p[count(.//a) = 2]") :hover {background-color:red}

And it can work with other selectors too, e.g. finding <ul>s directly underneath any <p> element, and shading them alternate colours:

p XPath("ul/li[position() mod 2 = 0]") {background-color: white}
p XPath("ul/li[position() mod 2 = 1]") {background-color: silver}

Following the usual CSS rules, if the XPath function contained mis-formed XPath, the style could be ignored. Also, it would be ignored if it returned anything other than element nodes (i.e. no attribute nodes or strings). And the default starting node of the XPath query is the document element, unless clarified by preceding CSS selectors.

Why not implement it?

As you can see, just by adding a single new selector, the CSS language is extended in so many ways.

XPath has already been agreed as a W3C recommendation, and has already been implemented in the major browsers.

I therefore see no good reason, other than inertia, why such a powerful new feature can't be added as soon as possible!