SVG as a Stylesheet Language

The SVG community has provided me with much of the motivation for the examples and demos that I have produced in the recent period. This is because many of the problems they face are not actually unique to them, even though they might appear so. For example, they want to produce great looking applications, but they have at their disposal only a rendering language, not a complete application language--they can therefore do the "great looking" bit, but they can't do the "application" bit. They also want to be able to produce widgets that can be re-used in other applications, but they only have available JavaScript and basic OO techniques to achieve their goals. Time after time, great applications are produced, but they have practically no consequence for the rest of the community, and are more of a testament to the tenacity of their programmers than a commendation for the language.


Short video showing an application 'skinned' with animated labels. (You may need to select 'Play' on the context menu, to see the animation.)

XForms and XBL to the Rescue

I've argued before that I think XForms and XBL provides a way out of this, and I believe key to solving this is to understand that SVG is most suitable for defining a specific manifestation of some application's user interface, and not for defining the whole shebang.

If SVG developers take the 'everything-in-SVG' approach, they'll end up in the same situation as HTML programmers have, where everything becomes script because the language isn't powerful enough to cope. But the HTML model is hardly a great one to follow, given that any major innovations that are taking place are doing so by using some old (but recently rediscovered) scripting techniques, going under the name of Ajax.

Language-types

I would suggest that a first place to start is to be clear about differentiating between the roles that different languages play. For the purposes of this discussion I would break languages into two types--abstract and rendering.

Abstract Languages

Abstract languages allow us to specify our intent. It might be XHTML, used to specify some sort of structure, and XForms, used to indicate the functionality that we want to achieve. It might also be parts of MathML, which allow us to define equations without being specific about how those equations should be rendered. Whatever it is though, it does not say how something is to be rendered.

Rendering Languages

Rendering languages are those that produce some sort of output that the user can interact with. It might be graphically based, such as SVG or X3D, but it could also be VoiceXML, SSML, parts of MathML or even XHTML again. Whatever it is, it is most likely very specific. Whilst in an abstract language we want to say "give the user a message that they cannot delete this customer", in our rendering languages we want to be able to say "place a blue rectangle on the display, and inside it put some white text saying 'you can't delete that, bozo!'".

SVG as a Stylesheet Language

SVG obviously falls into the camp of a rendering langauge, but how do we make use of rendering languages like SVG, without them cluttering up our applications? The answer is to use some sort of dynamic object-extension.

A Dynamic Object-extension Language

By dynamic object-extension I mean adding new features--such as properties and methods--to an existing object, but at run-time, not compile-time. The features you want to add are specified in some XML mark-up, but that mark-up should be outside of your application, so that we have clear separation.

XBL is the most well-known language for providing object-extensions, and is the model for sXBL, a much smaller language from the SVG Working Group at the W3C.

Whichever language is used is irrelevant, the main point is that this technique provides us with major benefits in code maintenance, re-use and testing. It's more powerful than Aspect Oriented Programming, since our aspects are created at run-time not compile-time. It's also more flexible than traditional OO programming, since objects can be extended in a number of different ways. To me dynamic object-extension is the way to get control over large applications in a way that can be extended in the future.

An Example

If you have looked at our Sidewinder Viewer (available for download here) you might have seen that the latest version comes with a full-featured application that interacts with Google Desktop Search (GDS). The application is built using standard XForms techniques, with a few clever bits to make configuration easy. The UI, however, is pretty 'traditional', with grey rectangles for buttons.

However, the fact that it is an already existing 'finished' application makes it an ideal candidate for illustrating how to extend an application's user interface without touching the code. On the XForms Wiki I've put a tutorial and code that uses XBL with SVG to create buttons that:

• use filters to give a rounded effect;


• obtain their captions from the XForms engine, and be updated if the data changes;


• use the application's CSS to obtain colours which will be used for the captions and the background;


• use SMIL to 'fly' the button's label in, but use CSS properties to determine when to fly the text.

This last point is a very important development, in that we are not binding to specific events like mouse-over, but to CSS classes. In other words, the functionality in the SVG button is truly independent, encapsulated and re-usable.

Conclusion

Note that the only changes needed to the actual application are a link in the header to indicate what binding rules should be used; the code to achieve the 'animated label widget' is kept in a separate XBL module. The application can therefore still run on a platform that does not support SVG, and the module can be easily used in other applications--with no compiling. The flexibility of this architecture makes testing and auto-generation of applications much easier, since the logic is separate.

We'll also shortly be allowing users to add their own binding rules that are independent of the web application itself, which will therfore give us a turbo-charged greasemonkey of our very own. (I really like Greasemonkey, by the way!)

Tags: XForms | webapps | Ajax | JavaScript | programming | patterns | Greasemonkey | SVG | XBL | Aspect-oriented Programming