XForms has a problem

XForms is the W3C’s XML language for programming forms on the web. It handles new user interface controls, better data validation, and easier form submission.

It does this by strictly following the "MVC" approach to data management – a ‘model’ is stored in the XHTML head, containing data structures bound to user interface form controls. When you enter values into the form controls, the model automatically updates too, and it’s the model that gets submitted.

In order to get the model to work, XForms defines an incredibly powerful binding engine, like a spreadsheet where cell values can depend on each other. It’s here that I have the problem. Why is the binding technology written inside the XForms spec? It’s useful for so many purposes (e.g. spreadsheets) that have nothing to do with forms – or even XHTML - and it stands on its own as a fundamental use of XML.

For example, I might have an SVG document where I want to bind the width of a circle to the length of a line. I can’t use XForms binding, because it’s not an XHTML document and even if it was, I don’t want to follow the MVC approach.

So, the tag should be pulled out of the XForms spec and put in a new XML bindings spec, that doesn’t force you to follow MVC (or even XHTML).

That way, all XML developers will gain a new technology that provides so much value, especially in animations. And XForms will become much simpler, and more targeted towards its role in enabling web forms.

Web Office suites and Vector Ajax

I’ve already argued that the lightweight web office suite will gain popularity, but not as separate presentation, spreadsheet and word processing applications, but one integrated application that caters for all three.

This application will have to take advantage of Vector Ajax – the use of inline VML / SVG to store and transfer data. That’s because it will allow lines, circles and more complex shapes to be drawn on the page.

VML / SVG is perfect for the task. It’s accessible, part of the DOM, and contains all the functionality you need (plus more) to handle drawing and annotations. In comparison, Flash doesn’t offer the same integration with the DOM – any office website will be a combination of HTML and graphics.

In fact, the <foreignobject> element in SVG is also perfect for displaying the "slide sorter" view, where you can see all the slides scaled down together and re-arrange their order.

I’m very surprised that there haven’t been more start-ups offering web presentation suites. After all, presentation software translates very well to "road warrior" types that have internet access, but no corporate LAN access. I suppose this is partly because the technology is quite a rare skill (SVG / VML) and tricky, due to differing implementations on each platform.

Maybe Google, as rumoured, will offer a presentation application as part of Google Apps.

When this happens, we’ll see the next phase of vector graphics adoption on the internet.

Browser Acceleration and Orientation

Perhaps the most revolutionary thing about both the iPhone and the Wii is their ability to detect acceleration and orientation. The iPhone automatically converts from landscape to portrait mode depending on which way you hold it, and the Wii was designed to allow tennis strokes, golf shots or boxing matches simply by moving the control.

Ideally, the same functionality should be available on the web. You can imagine a browser that

• Rotates between landscape and portrait mode, depending on device orientation
• Scrolls up, down, left and right based on device acceleration

But what if the web developer wanted access to the same information? You can imagine websites that

• Display maps, orientated to the direction the device is pointing at
• Provide games based on "pointing", e.g. golf games
• Provide games based on "moving", e.g. tennis games

The web developer will want to be able to access acceleration and orientation information, and use it to alter HTML, SVG or Flash.

Unfortunately, there's no standard for this on the internet. There is, however, a fairly obvious place where it could go - the javascript event object. In the same way that this object stores the current mouse location (for devices with mice), you can imagine it also storing x, y, and z axis acceleration and orientation (for devices with accelerometers and gyroscopes).

One interesting question concerns privacy. Does it matter that someone could track the orientation or acceleration of your phone, if you were logged on to their website?

Personally, I can't see this happening soon - the demand just isn't there yet. But once phone browsing takes off, after two or three years, it will be very interesting to see how this field develops.

In the meantime, the W3C should look at extending their standards to allow for acceleration and orientation. And phone browser providers, such as Opera, should consider upgrading their browsers to take advantage of the latest in user interface design.