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!

Browser User Interfaces

You can tell we've really begun to understand the web in the last five years, because while browsers have got more powerful, their user interfaces are now simpler and clearer.

This isn't always the case; think back to the office suite wars in the 1990s, when Microsoft and others added endless cluttered options, menus and functions to every release of their word processors and spreadsheets.

See the screenshots below of IE4 versus IE7 - the later release is much more streamlined.

The next version of Firefox, v3.0, is simplifying even further by merging History and Bookmarks into a much more powerful, unified interface: Places.

How far can this go?

Even further! I've listed some ideas below which would simplify and extend whole areas of browser design:

Calendar

Show the current time in the browser bar. When clicked, it opens your pre-defined calendar site (e.g. google calendar), and you can also drag text onto the clock from a webpage (e.g. "meet in Canary Wharf tonight at 7pm") to add events to your calendar.

Location

For devices with GPS. Show the current location in the browser bar (e.g. "Canary Wharf"). When clicked, it opens your pre-defined map site (e.g. google maps), and you can also drag text onto it from a webpage (e.g. "Canary Wharf") to view that place in a map.

Style

Subscribe to an external CSS stylesheet to control default and override settings like font name, font size, link underline, and audio volume. The stylesheet is cached locally and can be edited in a user-friendly manner via the subscribed website. Mozilla could set up their own stylesheet site as a start.

Page Analysis

Display page file size, security information, "view source", "view HTTP headers", error messages, and spelling or grammer checks. This could be done by posting the page to a subscribed analysis website, if security allows.

Tabs and Windows

Drag hyperlinks onto the tab bar to open them in a new tab, or drag them outside the browser window to open them in new window.

The goal is to reduce the browser interface down to a very few, powerful functions.

There's a common theme with the ideas above: functionality that used to be part of the browser - e.g. default fonts, page information - is now provided by a website. You enter the website details in the browser, and the browser hands over the appropriate information.

Websites are likely to be much better than the browser at certain tasks, because of the speed of application development and deployment on the web, the power of HTML and mashups, and the funding of Silicon Valley. It also allows browser makers to concentrate on page rendering, their core competency.

Security Considerations

Of course, the problem with handing features over to websites is security.

The most obvious example is browsing history - this would be much more powerful if it was integrated with your search engine. The problem is, uploading personal information to a web server is arguably even more insecure than storing it on your local computer.

Until privacy is improved on the internet, browsers will have to retain certain functions, like browsing history.

Conclusion

Experience has taught me that a few, simple, deep principles are always far better than many shallow ones. When I see something very complicated, I know it's just as likely to be a weakness in the design as in my understanding.

So it's great that browser makers are able to simplify their products, while extending their features.

Folders and File Categorisation

Microsoft's Vista, like XP, comes pre-built with folders called "My Documents", "My Photos", "My Music", "My Videos", and even "My Scans".

They're useful for about 10 mins, and then you run into issues - it stops you from categorising your files any other way, for example by project or by customer. Something is very wrong.

The best solution is multi-dimensional categorisation - being able to view your files by document type, project, customer, or any other cut.

However, since WinFS was removed from Vista's feature list, it isn't possible to do this. But for online storage, like Google Apps, these features should be straightforward - right?

Google gets it wrong too

Wrong. There's Google Docs & Spreadsheets, Google Photos (a.k.a. Picasa), Google Videos (a.k.a. YouTube), Blogger, and many other tools.

But there's still no way to group your files together into a "project folder".

They've made a few stabs in that direction - for example, you can attach Picasa images to Blogger entries, and Google Search in the US now works across file types. But in general, it's even further behind Microsoft.

How it should work

The obvious technology for combining all these file types is HTML.

Imagine creating an online project homepage, with links to the appropriate photos, videos, blogs, emails, spreadsheets, or even calendars. You could either upload new files, or link to ones previously uploaded to sites like YouTube.

The key point is that every perspective - project, file type, author, etc - should have its own homepage, allowing you to view or edit appropriate files. Many of these files will appear in several different places - the author's homepage, plus the project homepage, plus YouTube - but that's ok, because it reflects life!

Why WinFS didn't work

Looked at this way, it's obvious why WinFS failed, and Vista still has those pre-built folders like "My Photos". You simply can't categorise files without web technology - the URL, the hyperlink, the homepage, mashups, even the Wiki.

It's also a reminder that we're still at the foundation stages of computing - categorising files is a basic requirement that no one has truly accomplished yet.