Hi, Jasper-
Jasper van de Gronde wrote (on 7/15/10 4:47 AM):
We discussed this general issue a bit at LGM and basically the SVG WG does not see SVG as "the graphic core", but rather as something that can be used for (hand-)authoring and animation.
Correct.
For example, they would also be interested in adding the notion of a layer. It's a bit like we're using SVG as assembly language while they're trying to develop C++.
Well... maybe C. :) I realize you're joking a bit, but I don't think that's a great metaphor. SVG was *never* intended as a graphics core, which should be clear from the feature set of SVG 1.0: client-side scripting with a full event model and special graphical APIs, declarative and scripted animation, interactivity, linking, CSS support, and so forth... it was intended as a Web format, with all that entails. Maybe a better metaphor is the difference between HTML used as a text format like RTF versus the way it's used today to make interactive applications; both are valid uses, and they are both HTML.
I can see why they would want that, as it would be pretty cool to have a format that can be edited interoperably by different editors, and it can be very hard to animate a spiro for example if the renderer has no notion of it (you'd have to animate the bezier, which would not have the same effect).
Exactly. Also, these paths are rather smaller in file size than the equivalent Béziers.
But I think you're absolutely right that this is putting a pretty big burden on renderers and that it might be better to have a more focussed format.
A new path command is not a large burden to place on renderers. I realize that Javascript is easier to code than C, but I put together my script lib in an afternoon. How much time would that spare people trying to hand-author Béziers? I think it's a very good investment of implementers time.
The real danger is that it will be disruptive to the ecosystem since it wouldn't be backwards-compatible, so older authoring tools and browsers couldn't make sense of it, and would only render the path up to the point where the new command was made. But that's a minimal risk right now, and is the risk of any new features of SVG, including new gradients.
Personally I'm thinking that it might be best to select a subset of SVG and/or create a different format specifically for this purpose, but feel free to tell the SVG WG how you feel about this kind of thing on the SVG mailing list.
Effectively, Inkscape has already done that... as a static authoring tool, you do not implement the linking, declarative animation, or scripting effects, and that is not required of you. In fact, the SVG WG is clarifying different categories of SVG user agents, including static ones, so Inkscape can occupy the niche it feels best suited for. But that is not a good rational not to add new features to SVG, in my opinion.
Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs