On 4/27/06, MenTaLguY <mental@...3...> wrote:
It would have made the full specification harder to implement (and larger, and more complex). Remember that for every facility you define, you also have to carefully define the ways in which it interacts with all other related facilities.
Overall, with all things in place, it's indeed more complex. But it has a big advantage: it can be implemented incrementally. We can start by using only built-in effects (much simpler than adding anything in defs) and see how it goes. _Only_ if and when there's a convincing need for something more complex or more decoupled from Inkscape itself, we can add the defs thing.
It won't break anything which worked before. To be extra sure, we can prefix all the built-in functions with inkscape:, or even make them full URNs, guaranteed unique.
Personally, I'm almost sure that the defs thing will never be needed. But I don't want to bet on that. Instead I propose a start-simple approach which will be easy to extend if really necessary.
There are also subtle issues with the particular approaach -- CSS properties aren't ordered except for overriding/inheritance, so if there were more than one filter type available via CSS, there'd be no well-defined way to stack them.
Sure, but we (unlike CSS) don't need to have filters in multiple attrs of one element, and within one attribute, the ordering is obvious.
That has a lot less to do with complexity of the SVG standard and more with the severe crappiness of our own codebase, which makes the things that should be easy hard.
Yes, but this does not change my argument. We still have the same crappy codebase. But I want path effects NOW, I will not agree to wait 2 years as I did with SVG filters.
With a saner architecture, the SVG filters specification would actually be something like the path of least resistance.
I'm not so sure of that. Maybe I'm spoiled by our crappy codebase, but at this time I really abhor the "something which refers something else out there" design. In my view it's fundamentally broken, and our ugly "vacuum defs" command is a monument to that brokenness. Again, I'm exaggerating for the sake of the argument, but you get the idea :)
True. Though was almost all SPObject and RDF code bugs, not XML tree.
Right. But again, this does not invalidate my argument. We still have to deal with the same SPObject and the rest of the code. You won't believe how many crashes I fixed caused simply by the the fact that Adobe SVG files have lots of empty lines and these lines end up as empty text nodes in our tree.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org