[clipart]Robin Berjon posted about what his SVG 2.0 Wishlist would be. I think he used the hatchet a little too much, so I thought I’d give some feedback. Since he doesn’t support comments (boo!) here we go.

Chopping defs

This was probably my biggest annoyance/concern since, to my knowledge, the <defs> elements causes zero problems. Why would <head> or <g style=”display:none”> be preferable to <defs>? The defs elements provides semantics to a SVG document. Specifically, it acts like Flash IDE’s “stage”, where graphical editors can store and find the re-usable elements in a drawing. I don’t see any benefit to getting rid of <defs> nor do I see a problem that it causes. Why are you using <section> elements when <div> will do just fine on your blog, Robin? 😉

Chopping SMIL

I think chopping SMIL at this point would be a bad idea, considering that all native SVG browsers are just coming online with this stuff now. Yes, SMIL is vastly underused, but frankly SMIL has not had a chance to prove itself – both in user agents and in graphical editors. I’d say now that it’s been (being) finally implemented, give SMIL a chance and drop it in SVG 3.0 (or whatever comes next) if it is still too under-used.

Your alternatives to SMIL are CSS3 Animations for simple cases (sounds good) and JS+DOM for complex cases. I disagree with the latter as the only way to animate complex SVG. I think that SMIL still has good uses there. Out of curiosity Robin, what do you think of SMIL Timesheets?

What we do need to solve is the DOM interface for SMIL. I agree baseVal and animVal are truly hated. In general, I think declarative animations make sense for SMIL, but I don’t know about the mixture of SMIL + DOM – that never quite made sense to me.

Maybe move SVG+SMIL out into its own SVG 2.0 Module and see how it fares and provide SVG DOM Core 2.0 that’s leaner, meaner and leaves out the SMIL?

Attributes and CSS Properties

What’s the migration strategy? If the SVG 2.0-capable browser encounters an attribute that was present in SVG 1.1 and not present in 2.0 – what should it do? Ignore? <circle fill=”blue” /> becomes black?

Not all editors universally love inline style attributes (though the popular ones do). Inline style attributes are another layer of parsing, another micro-syntax for hand authors, and can actually bloat the markup – unless you have more than 3 presentational attributes 😛

I think removing the CSS properties as attributes will actually end up confusing authors further (what? i can set the radius of the circle using XML but not the stroke-width?). I think the decision to make presentational attributes was a conscious one based on the fact that SVG is such a visual language.

I guess I don’t have a better solution for CSS properties as XML attributes, because I admit that it is confusing as it stands, but I’m not convinced that simply removing them is the answer.

Slicing – not Chopping

[clipart]I hope that SVG 2.0 does become leaner. I just think that now that browsers are seemingly rallied around 1.1 Full and people are actually starting to use SVG that we need take a more cautious approach with changes. To me, carefully and iteratively shaving is a better approach than swinging a hacksaw and see what you end up with. Sorry to mix up so many blades in my analogies.

Here are some things I wouldn’t be upset about if they went away:

  • <symbol> – hardly needed if <use>-referenced elements could have a viewBox, I don’t think they add considerable semantics like defs does
  • <tref> – sure, I’ve never used it
  • <view> – agree with your comments
  • <audio>, <video> – agreed that HTML5’s versions are the future
  • <switch> – never lived up to its potential, unfortunately (though I guess this leaves server-side or JS as solutions for localization?
  • <font> and related – I agree with your idea to move it out of the ‘core’ spec. Put it into a module and see what happens with WOFF, etc
  • <foreignObject> – I agree that this shouldn’t be necessary to mix HTML in SVG. If inline HTML can somehow show up directly inline with SVG then we could also do away with <textArea> and others
  • version and baseProfile – I think I agree with you on this one, they could be dropped. But if this is done, we need a good way of marking features non-conforming and obsolete going forward. HTML5 still has spec text for the <font> element.

My Wishlist

I liked your “Better HTML Inlining” idea. I think it has merit.

You seem to be extremely focused on paring down the language so that implementers can reduce their “SVG code footprint”. While this is definitely a concern for me as well, I think your proposals for removal do not pay enough attention to authors, tool-makers and existing content.

Personally, I think the major focus for SVG 2.0 should be on one thing:

Making the DOM Suck Less

This alone could seriously help reduce the SVG code footprint in the long run (though I still don’t understand how browsers could easily obsolete their SVG 1.1 DOM code yet). I hope to see the SVG WG hosting a DOM Summit as mentioned by shepazu. I look forward to reading/seeing concrete examples and spec proposals from attendees there.

Once the SVG DOM is improved and we have interoperable implementations of SVG well-deployed around the web, then I would think about seeing what else needs to be cut in the next-next version of SVG.

§606 · January 29, 2010 · Software, SVG, Technology, Web · Tags: · [Print]

Comments are closed.