Hey Josh,
I think the better way would be the SVG standardisation route. But I think we're both aware how long it can take to get standards even into draft. I live in hope.
While I'm not happy about using groups myself, it's certainly possible to use far less code and be consistent with a number of other functionalities. What I'm more unhappy about is creating a new data format which is inconsistent and wholly separate from what has gone before, this is going to lead to large amounts of code and maintenance headaches.
My proposal only requires that we make assumptions for editing. It follows existing rules which means that it invents nothing and doesn't add to the specification to be supported going forwards. It uses exactly what we'll have to support anyway, only the manner in which I've used it exotic.
Of course I'm happy to use what ever approach is best overall, I'd like a few more arguments against groups before I dismiss the concept completely.
Best Regards, Martin Owens
On Sat, 2011-10-01 at 06:07 -0700, Josh Andler wrote:
Much more important though... perhaps it's most appropriate that we go about this in an *even more difficult* way. Come up with a solid solution that is svg appropriate, create and refine all of the semantics, pitch it to Tavmjong to get his feedback, and in the end submit it to the SVG WG for SVG 2.0. We can be a testing place (as Tav is doing in a branch currently for gradient meshes), namespace everything appropriately, etc.