SVG 2.0 — My Wishlist

Better HTML Inlining

While SVG was designed to be embedded inside of HTML far better than plugin-based solutions, doing so is still more painful that it ought to be. For instance, if I want to include a simple shape inside of an HTML flow, I currently need to do the following:

<p>
  Follows a very pretty rectangle.
  <svg xmlns='http://www.w3.org/2000/svg' width='100px' height='50px' viewPort='0 0 100 50'>
    <rect width='100' height='50' fill='#f00'/>
  </svg>
  Weren't you impressed with how nice it looks?
</p>

Some of the issues that make the above clumsily long are being addressed by HTML5 (e.g. the namespace declaration, though you do trade that for having to close the rect element with </rect>) SVG still requires a defining context. It would be much nicer to be able to simply say what you mean and nothing more:

<p>
  Follows a very pretty rectangle. <rect width='100' height='50' fill='#f00'/>
  Weren't you impressed with how nice it looks?
</p>

CSS can provide the context needed to perform the painting here, both in terms of position in the flow and of size of the containing box. Some things may have to be restricted, and in some situations using <svg> will still be needed, but at least the simple cases should be simple.

A Better DOM

That the SVG DOM is imperfect is no revolutionary statement. Even the SVG WG tried to improve it by exploring alternative approaches as part of SVG Tiny 1.2's “µDOM”. Not only is it slow and ugly, but it also accounts for a massive part of implementations' footprints.

How exactly to improve the SVG DOM would warrant a larger post. To keep things simple for the time being, I would contend that the two wishlist items that follow (not exposing CSS properties as attributes, and dropping SMIL) would already help a lot by making it possible to drop almost all CSS-related interfaces and killing the much hated baseVal/animVal dichotomy as well as all of the SVGAnimated* interfaces. I'd be curious to find out just how much that change alone would buy us.

A number of attributes that are currently part of SVG could be reused directly from HTML instead (SVGStylable, SVGLangSpace...), thereby further reducing the size. Once the DOM has been simplified, we can start looking at adding a small number of interfaces that would enable more useful manipulation of some of the more complex types, such as path data.

Drop Properties as Attributes

The fact that CSS properties are exposed as attributes has long been a cause for confusion. People have trouble understanding why fill inherits but width doesn't. It does not make reading SVG easier — off the top of their heads, few people can say what colour the following rectangle will be:

<rect width='100' height='50' fill='red' style='fill: green'/>

(The answer is green, because non-CSS sources of style information have a specificity of 0. Except in a mobile implementation where it would be red. Except that some mobile implementations support the style attribute. But not always.) At the scripting level, this is problematic because a script that uses setAttribute instead of style will have no effect in what it changes if the same information is already provided by the style attribute.

Using attributes is more straightforward, easier to use from XSLT and similar server-side technology, and is the option chosen by SVG's Mobile profiles (where CSS isn't supported). But that isn't enough to compensate for the fact that having two systems is worse than having just one that isn't perfect. In addition to the confusion and scripting issues, most authoring tools use the style attribute. Most importantly, today's approach to scripting, rooted in HTML, is based around modifying style (e.g. in jQuery you'd use the css method) and SVG should “just work” in that respect.

As a result, I used to much prefer relying on attributes, but that was when SVG mostly stood alone, in between the two browser wars when we had little choice other than to do our own thing. The game has changed, and so should SVG.

This change removes over 50 attributes.

Drop SMIL

SMIL doesn't play well with the DOM. This makes it largely useless inside of applications and libraries, and problematic in situations that involve scripting. Better integration has been billed as forthcoming for essentially ever but is yet to be seen — and there are good reasons to doubt that it can be done, or at least done in a way that will make anyone happy. On the face of it, declarative animation is a good idea. Animations (at least the complex ones) are typically easier to author inside of a tool, and a declarative syntax is much easier to handle for a tool than scripts that are interleaved with things that may be doing completely different tasks. But making it part of the tree just doesn't work.

Today we have alternatives. CSS Animations work nicely for a lot of uses. They are declarative, but since they sit outside of the document tree they don't suffer from the same DOM manipulation issues (in fact, they are overall well-integrated into the DOM). Essentially, CSS Animations define a form of external “time sheet” that can address a large number of SVG's animation use cases. And where CSS Animations can't reach, we can rely on the DOM to work — as is done on a vast majority of Web pages.

This removes: animate, animateTransform, animateColor, animateMotion, mpath, set, and (perhaps) animation, as well as their attributes.

More Lacunae Values

The use of lacunae values is reasonably widespread in SVG, but to the best of my knowledge a comprehensive review of where and how they are used has not been undertaken and might prove useful.

Use HTML Wherever Possible

A number of features can be nicked from HTML instead of being integrated directly inside of SVG — even though when nicked they should be usable without having to resort to foreignObject. When making this statement, I often hear people saying “But SVG had that first!” That may be true, but who has the most momentum and the largest user base?

Candidates for this raft of direct elimination include (but aren't necessarily limited to): audio and video, script and style, a, and possibly image.

We can then get into fun questions. For instance, can we remove g and use div instead? Can we get rid of transform and use CSS transforms instead? There is a limit to the amount of changes that we can do before it breaks too much content — unless we decide to really shake things up (but I doubt this will be the case).

Kill XLink

I explain in Reusing the Useless why I think that using XLink was a bad idea, so I won't repeat the case here.

Of course though, we don't want to remove the ability to link to things. But everywhere that XLink is used, it can be replaced either with href for links that are user-traversed or src for those that are to resources. HTML isn't completely consistent in that respect (e.g. link/@href vs script/@src) but SVG can try to be.

Drop version, baseProfile

These two attributes are largely cases of Naïve Versioning. At the best of time they are useless, the rest of the time they're harmful. There is no doubt whatsoever in my mind that they should be purely and simply eliminated.

Revisit Some Elements in Light of Actual Usage

It is unclear that some elements are actually being used as they were intended, that they bring enough value to the table to justify their continued existence, that they are implemented, or that they couldn't be replaced with something that's already supported elsewhere. My list of elements to review includes:

desc, title, metadata

These aren't used as much as they were expected to be, and several of their uses are suboptimal. Besides, they match functionality that shouldn't be SVG-specific.

defs

Could this be replaced with head? Isn't <g style='display: none'> enough?

font, font-face, font-face-format, font-face-name, font-face-src, font-face-uri, definition-src, glyph, glyphRef, hkern, vkern, missing-glyph, altGlyph, altGlyphDef, altGlyphItem

SVG Font is a useful format, but it may be slowly superseded by WOFF. Also, it could sit in its own specification without necessarily being part of Core SVG.

color-profile

This ought to be in CSS only.

cursor

A nice idea, but having CSS point to an SVG resource should suffice.

foreignObject

A more controversial option, but could we figure out a way of ridding ourselves of this one? It may be too difficult, but it's certainly worth discussing.

switch

Too painful to use, too brittle, and underused.

use and symbol

These should either be yanked, or made a lot more useful. CSS inheritance down use trees should be simplified.

tref

Useless, painful.

tspan

Could it be replaced with span?

view

Nice idea, but poorly supported and probably doesn't have enough of a generic use case to justify keeping it.

Don't Change Everything Though

It is tempting to use this moment to change a number of annoyances, but there has to be a limit so that we don't go reinventing the entire language — which would likely lead to a Second System Syndrome, and cause the WG to disappear down a hole and never return. For instance, I would very much like to switch to a non-dated namespace (which we could do if we decided not to be backwards compatible at all) or to rename the filter elements so as to lose the useless fe prefix (as I've explained previously), but I am willing to live with keeping these as I think that trying to fix them will break too much that already exists.

It's rather instructive to look at what remains if the SVG WG were to go the rather hardcore way of following all of the recommendations here:

• circle
• clipPath
• ellipse
• the full complement of filter elements
• g
• line
• linearGradient
• marker
• mask
• path
• pattern
• polygon
• polyline
• radialGradient
• rect
• stop
• svg
• text
• textPath

That's a very manageable list. It also has the interesting property that it is strongly focused on graphics. These aspects not only make SVG more implementable, they make implementations more reliable. It also simplifies the tasks involved in extending it as the total surface of non-orthogonal features is reduced.

But if I go on any longer I'm going to start rambling. Thoughts? Screams? Beer? Send me your feedback!