![](https://secure.gravatar.com/avatar/eb3fe37da4a199eb4e3b479d8a57f808.jpg?s=120&d=mm&r=g)
On Wed, 23 May 2007 11:35:48 -0700, Ted Gould <ted@...11...> wrote:
I'm concerned about using a switch here, will applications like librsvg render it properly? Firefox? I don't know that this is widely supported enough to use. We need to make sure that these paths show up rendered in a large set of renders (in real life, not just a "support more of the spec" type answer)
It's a valid concern. I think we'll be okay so long as they:
- at least treat svg:switch like svg:g - ignore tags in namespaces they don't understand
(obviously we should test this)
<!-- we use the Inkscape namespace since it's not standard yet -->
inkscape:vectorEffect requiredExtensions="http://www.inkscape.org/SVG/vectorEffect"
We use flowText that isn't part of the standard yet... I would rather just leave this in the SVG namespace. I'm so frustrated with the lack of a 1.2 spec that I'm willing to risk the incompatibility...
They are finally moving on 1.2 now, releasing it module-by-module rather than waiting interminably for the whole thing to spring fully-formed from the forehead of the working group. We're also a much bigger player in the SVG space than we used to be even a year ago; I am hoping to be able to take advantage of that influence. Given that, I'd rather build goodwill with the W3C by keeping their namespace clean.
I definitely don't want to see a repeat of the flowText disaster on either side.
Also, this provides an easy mechanism for stacking in the path effects.
Yeah, it's obviously functionality we'd like to have eventually, and vector effects certainly provide an already well-defined mechanism for doing just that. Much better than trying to hack in stacking later.
(I have no idea how this UI is going to work though... :) )
I think the UI will probably work something like the one for filter effects, which has essentially the same model for effect chaining (which my SoC student will hopefully come up with... :D).
-mental