How "Widgety" should SVG Get?

Widgets have an interesting pedigree. Originally used as a humorous term for a small machine of some sort in a manufacturing process, widgets have made their way into the programming lexicon as a short-hand term for components used in software application development. These components are generally lightweight and are very seldom stand-alone, serving instead as some kind of snap-together Legos* to make application development go faster.

HTML has long had a staple of seven or so such widgets for building web forms, components that are fairly primitive and limited in their capability, but that serve to acquire enough information to make them both easily implementable on about any platform and basic enough to minimize cross-browser differences.

XUL, covered in my previous post, is a larger (albeit still finite) collection of widgets that provide enough flexibility to build what we consider traditional desktop applications. What differentiates XUL from HTML, however, is the presence of another layer, the XML Binding Language (XBL) that provides a set of interfaces for defining new Widgets using a largely XML based framework. XBL can both extend the functionality of existing XUL widgets (and HTML widgets, for that matter) and can define new ones from scratch.

This extensibility mechanism is something that developers should think hard about. Limited component architectures can only carry you so far. Eventually, you come across a need for a component that can't readily be built within the existing widget framework, or that needs to be skinned in a different way than the current set can handle. XBL provides a way of building not only structure but data structres, attaching (or removing) events, and metadata into new items introduced into any given namespace. In simple terms, this means that you can keep your core presentation language (be it XHTML, XUL, or SVG) as focused on its task as necessary, while adding in a reusable set of intermediate components that push into the application layer.

SVG is already an extraordinarily large and complex namespace, one that is proving difficult for many vendors to implement in its entirety. To add into this the requirement for additional core widgets puts two forces against one another that should be cooperating - the vendor community trying to put together decent workable implentations and customers/developers who want to see more functionality at the core level.

When talking about XML technologies, I've often differentiated between foundational schemas - ones that effectively define the toolkits that people use to make the web - and application schemas (the languages that use these primitives to build something useful). SVG is a foundational schema, perhaps even more so than XHTML is. In theory, you could replace XHTML with SVG (though it would entail a huge amount of SVG to do it), you couldn't replaces SVG with XHTML, however. XUL isn't foundational, though it isn't quite at the application level, either - it falls somewhere in between. Again, however, it is possible to create XUL with SVG (not necessarily practical, but possible) while the opposite isn't true.

And this is consequently where the crux of the debate about SVG widgets comes from. It is possible to create an editable text box in SVG (1.2), even if there wasn't an editable attribute in the spec itself. The attribute exists because while it is possible to build this kind of editor with SVG, the overhead of doing this in script is prohibitive (I speak from personal experience here). Beyond this one particular component, however, it is safe to say that most widgets could readily be created by some combination of SVG elements. This is the prevalent view that is spurring the recent developments in sXBL. Rather than establishing this additional set of widgets (an approach taken by the now defunct Corel SVG efforts in creating dSVG), sXBL takes the approach that components can be built using an XML language that would be far more flexible than any limited widget set.

XBL is far from perfect. I am dismayed by the overreliance in the original Mozilla implementation of XBL of RDF, which, while suitable for some applications, adds a layer of complexity to building apps that many developers are uncomfortable taking. I find RDF confusing, and I've worked with it on and off for the last four years. I'd also prefer to see XPath rather than CSS being used as the selector language, for reasons I've outlined before. However, all of this pales in comparison to the obvious benefits that an XBL of any sort provides.

One of the other facets that I think will become a much bigger factor within two-to-three years is the idea of incorporating SVG as an equal partner within the DOM. Adobe's SVG viewer is a powerful application, but so long as it is limited to being "in the box" it's utility will always be more for stand-alone applications rather than components, for memory reasons if nothing else. ASV used as a behavior for defining SVG code directly within a web page has much more potential for making SVG a foundation for Widget development, especially once you have an XBL-like mechanism to create SVG as shadow-entities of other XML constructs. I've played with this some in the Mozilla SVG builds, and there's more than a little power in being able to reference an SVG group in exactly the same way that you do an HTML element.

Right now, we tend to pre-impose what we know of established functionality on our ideas of what can be done with such technologies, but realistically, once you can break out of the box (one of the biggest advantages that SVG promises, when you get down to it) there will be a whole generation of web designers who will see existing web applications as being staid and dull. We need to get to that point, first, but it's coming.

-- Kurt Cagle