
On Thu, 27 Apr 2006 11:55:49 -0400, "bulia byak" <buliabyak@...400...> wrote:
On 4/27/06, MenTaLguY <mental@...3...> wrote:
I need to check, but if I remember correctly some of the original SVG filter and vector effect proposals used flat attributes as you propose, but obviously they decided not to do that. Our path effects have similar design considerations, so I'd rather not repeat old mistakes.
This is entirely different, as you yourself note below. Filters _do_ use flat attributes on the paths themselves, it's only that these attributes refer to something external (which may or may not be hierarchical).
Hmm, no, what I meant by flat attributes is representing a non-trivial structure as a flat string. With SVG filters, the only thing that goes in the style attribute is a single uri reference. There's no non-trivial structure there (i.e. a list of nodes with named or positional parameters).
And speaking of W3C example, I think as an implementor you should agree that their filters system is a huge burden. It's flexible? Perhaps (though they still don't allow new effects apart from those defined in the spec, as far as I can see). But if _in addition_ to that flexibility they would allow to simply add "gaussian-blur:5;" to style, without any hrefs or defs, I would have written a support for this in a couple days.
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.
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.
So, be careful what you wish for. The SVG filters are nearly as simple as you can reasonably get if you want to include more than just gaussian blur.
Without this simple alternative, filters remain unimplemented for years, and now we have to declare them a SoC project in the hope to get them finally working. See the difference?
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. Given what we do, shouldn't adding a new element or a new CSS property be easy?
With a saner architecture, the SVG filters specification would actually be something like the path of least resistance. If you just wanted to implement gaussian blur to start with, it should have been be easy enough to implement just enough to handle a <filter> element with a single <feGaussianBlur> child and ignore the rest.
It's not, of course. Just adding a new SPObject subclass that doesn't do anything takes 40 or 50 lines of code, and dealing with anything in SPStyle is just exruciatingly painful.
IMO it's a case of overengineering, and given the general fragility of our XML tree, it's much more trouble than it's worth.
Fragility? Howso?
Did you notice how much trouble was caused by adding RDF metadata?
True. Though was almost all SPObject and RDF code bugs, not XML tree.
As far as the XML tree things are concerned, I'm also not really sure what validity checks we can or should have on our XML at that level ; past a certain point we have to trust that other code which is responsible for knowing about more specific constraints (like the RDF code) will do the right thing. Emitting non-namespaced names is actually valid, from an XML standpoint.
(I recall we had once had a bug with missing xmlns: declarations entirely, but that was no less than a bug in the XML code itself.)
-mental