Tab Completion

Cameron McCormack, one of the chairs of the SVG Working Group, just posted some proposals for revamping the SVG DOM (Document Object Model - the JS API for interacting with the elements in the page).

I think the ideas are pretty great! They boil down to a few basic proposals:

Put all the SVG elements into the HTML namespace

This is the core of the idea, and I'm in favor of it for several reasons.

For one, it means FUCK NAMESPACES. While the concept of namespaces is great, and the execution of them is good in most languages (see: Python modules), XML namespaces are terrible. They're verbose, hard to remember, and pollute everything with bullshit like createElementNS(). By putting all of the elements into the HTML namespace, we can just ignore the namespace, since the HTML DOM already just assumes everything is there.

For two, it gives us a nice hook for attaching brand new interfaces to elements with the same name. Two elements of the same name in different namespaces are technically different elements, and can have different classes representing them. We've been looking for some kind of hook or Big Red Switch to throw away the old SVG DOM for a while, and this particular switch accomplishes that goal, and is a great idea all by itself.

For three, it lets us do a little spring cleaning and get SVG to match the conventions of HTML. Way back in the day, SVG and HTML were competing in the standards marketplace to be the language you wrote documents in. That battle was decided a long time ago, though, and HTML won. SVG is now a fancy and useful image format, and integrating itself more tightly into HTML rather than standing on its own will only help it. For example, we can make all the element and attributes names case-insensitive, like HTML, and maybe rename a few attributes that have migrated into CSS properties to match the CSS spelling (using dashes instead of casing to indicate word boundaries).

For four, it lets us more easily just slot into the HTML parser. I often end up writing my SVG pages in HTML by just adding a <!doctype html> to the top of it, because that lets me use unquoted attributes. (Such a small thing, but so annoying to not have...) Since SVG elements are now in the HTML namespace, we can just use the HTML parser all the time, and drop HTML elements directly into the page. (This still isn't trivial, as we have to define the rendering model for non-SVG elements. This is something CSS can do, though, and it's long overdue anyway.)

Throw Away the Old SVG DOM

We all know that HTML's DOM is terrible - it was written at a time when Java was expected to be a major web language and JS was just a toy script, so there's tons of super-clumsy idioms which don't make sense today.

SVG, though, is a whole 'nother ballpark here. It grew up in the same environment, but got even more attention from standards people back when, so it grew even more arcane and clumsy shit.

For example, many SVG attributes can be animated. To handle this, the SVG DOM doesn't expose those attributes as normal values. Instead, they're a special object with .baseVal and .animVal properties. This makes for a really, um, special way of interacting with the DOM. Some properties you can just set directly to a value, while others you have to indirect through baseVal, and you just have to memorize which is which by yourself. (To get around this, I almost always ignore the interface and just read/set attributes via get/setAttribute() calls, because it's predictable.)

In the new HTML-namespaced SVG elements, though, we can throw all that away and start fresh. Properties can go back to just reflecting their value, with animation layered on with a separate mechanism, like CSS does.

SVG also invented a bunch of bizarre classes for things. For example, there are a bunch of array-like classes which all reflect their length with a .numberOfItems property. Yes. .numberOfItems. Not .length.

We've learned a lot about how to design user-friendly interfaces for things like these in the past two decades, and WebIDL (the specialized programming language we use to specify classes and whatnot in DOM) has grown to reflect these. Cameron is the editor of WebIDL, so he's in a great position to redesign this stuff properly.

Innovate in some new Author-friendly APIs

Two big things that are planned with the new SVG DOM will make it much easier to interact with some of the most complex bits via CSS.

The first is reflecting a bunch of attributes that currently take lengths, angles, and similar values as something more intelligent than strings. It's silly that you have to parse the string "3em" yourself and figure out what the width of an em is if you want to match it with something in pixels - the browser has all of this information already, and can do it for you much more efficiently!

This is similar to something we've toyed with for a long time in CSS, which does the same thing - reflecting CSS properties as something more than just a string. I'm going to make sure that SVG and CSS evolve together on this so you don't have to learn two ways to do the same thing.

The second is producing a more convenient API for creating/adjusting a <path> element. <path> has always used a somewhat bizarre, super-compact format for specifying how it twists and turns. Modifying this directly as a string is horrible, but so was the over-engineered API that you could alternately use.

SVG plans to add a new more convenient API for building up a path, possible by taking the existing Canvas API and adding to it as necessary for the missing commands. (Separately from this, we're also adding some new commands to <path>, particularly for doing circular/elliptical arcs more conveniently. Lessons learned from JS libraries!)

Maybe this could lead to just layering the Canvas API directly on top of the new <graphics> root, so you can easily do retained-mode graphics with the same moderately convenient syntax? TIME WILL TELL.

Anyway, I'm uncomfortably excited about all of this.

Tab, all of this is all super-exciting work. Yes, yes, and yes to all of this. I'm especially interested in seeing a souped-up, stripped down API for modifying paths. Something that treated paths simply an array of points, with a more intuitive, somewhat higher-level set of array methods geared to the things people actually want to do.

Reply?

I also am excited. I'm working on a storybook that uses SVG heavily for graphics. I'll continue to eagerly watch from the shadows.

Why not just merge HTML5 into SVG, to convert SVG syntax to HTML? CSS filters, effects, animations, etc. applies the same to HTML tags and SVG too.

IMO the weirdest thing is that SVG is more about "Things I Want to Have" or "Things I Think May be Handy to Have" rather than Scalable Vector Graphics. You know, when people talk about separation of Model and View in W3C standards I want to laugh (or cry because of all that stupidity)... Also, the only true modular standard I can think of is XML Namespaces, at least judging by the size of it.