{"id":606,"date":"2010-01-29T13:20:31","date_gmt":"2010-01-29T13:20:31","guid":{"rendered":"http:\/\/www.codedread.com\/blog\/?p=606"},"modified":"2010-01-29T13:23:27","modified_gmt":"2010-01-29T13:23:27","slug":"svg-2-0-wishlist","status":"publish","type":"post","link":"https:\/\/www.codedread.com\/blog\/archives\/2010\/01\/29\/svg-2-0-wishlist\/","title":{"rendered":"SVG 2.0 Wishlist"},"content":{"rendered":"

[clipart]<\/object>Robin Berjon posted<\/a> 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.<\/p>\n

Chopping defs<\/a><\/h3>\n

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><\/a>? 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? \ud83d\ude09<\/p>\n

Chopping SMIL<\/a><\/h3>\n

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.<\/p>\n

Your alternatives to SMIL are CSS3 Animations<\/a> 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<\/a>? <\/p>\n

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.<\/p>\n

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?<\/p>\n

Attributes and CSS Properties<\/a><\/h3>\n

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? <\/p>\n

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 \ud83d\ude1b<\/p>\n

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.<\/p>\n

I guess I don't have a better solution for CSS properties as XML attributes, because I admit that it is<\/em> confusing as it stands, but I'm not convinced that simply removing them is the answer.<\/p>\n

Slicing - not Chopping<\/a><\/h3>\n

[clipart]<\/object>I hope that SVG 2.0 does<\/em> 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.<\/p>\n

Here are some things I wouldn't be upset about if they went away:<\/p>\n