SVG 2.0 — My Wishlist
Time to do the laundry
SVG has grown a lot over the past decade. It is now available in the vast majority of phones, and in all browsers save Internet Explorer. Even there, the SVG Web project has made it possible to use it universally, and as Microsoft has recently joined the SVG Working Group, hope is blooming that the next version of their browser will support it natively. As with any technology that has grown over time, hindsight allows one to evaluate past decisions more clearly. As SVG becomes as ubiquitous a part of the Web stack as HTML or CSS, I believe that it is time to revisit these decisions in order to make it easier to use and evolve going forward. My wishlist for the next version is therefore far more concerned with changing or removing existing parts than with adding new features. This is just an early shopping list, more thinking and discussion is required before actually jumping in with most of these items.
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>) 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
<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
animVal dichotomy as well as
all of the
SVGAnimated* interfaces. I'd be curious to find out just how much that change alone would
A number of attributes that are currently part of SVG could be reused directly from HTML instead
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
style will have no effect in what it changes if the same information is already
provided by the
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
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.
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.
set, and (perhaps)
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):
a, and possibly
We can then get into fun questions. For instance, can we remove
g and use
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).
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
those that are to resources. HTML isn't completely consistent in that respect (e.g.
script/@src) but SVG can try to be.
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.
Could this be replaced with
<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.
- This ought to be in CSS only.
- A nice idea, but having CSS point to an SVG resource should suffice.
- 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.
- 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
usetrees should be simplified.
- Useless, painful.
Could it be replaced with
- 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
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:
- the full complement of filter elements
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! •