On 2010-09-07 17:13, Joshua A. Andler wrote:
Yes, top posting is evil. :) It seems there are a number of new things, such as diffusion curves, gradient meshes, new curve types, hatching, and more which are being looked into for SVG 2.0. Previously, we've already run into an issue with someone creating a patch to do spiral (conical?) gradients in Inkscape that basically got the thumbs down for not being SVG compliant.
That's indeed an important issue. I am looking at fallbacks and trying to communicate with the W3C about this.
I think that we need to have a configure flag for diffusion curves and other proposed SVG 2.0 features (I seem to recall seeing someone bringing up the spiral gradients too as a thought, so maybe that patch could get integrated after the proposed config modification).
With a configure flag for these "proposed" SVG 2.0 features we can achieve the following. A) We can then figure out the best UI for an authoring tool of these features and not worry about that changing in the meantime. B) We won't run into the flowtext issue again since these features must manually be flagged at build time to be used at all. C) We don't risk breaking SVG compliance in Inkscape proper (aka normal builds) and can also show that these tools/features have use cases and have merit to be in SVG 2.0. D) We can help to figure out what the syntax should look like w/o being overly concerned with this changing over time (these features wouldn't really be for production, so backwards compatibility is far less of an issue). Thoughts?
I understand where you're coming from, but to me it doesn't feel quite right yet. What if standardization of SVG 2.0 takes another N years? We would then perhaps have several (advanced!) features in the code base that hardly ever get used (because you have to turn them on explicitly). Naturally this would come with all the usual maintenance nightmares of "dead" code. If you don't use it, you don't notice it's broken. And if people do use it a lot the whole point is gone.
Basically we WANT people to use this (and other) new feature(s), and perhaps even especially before they are standardized. But you're right we also do NOT want to run into trouble down the road when the standard is finalized. For now I hope some common sense, fallbacks and a lot of communication will help mitigate these problems, but I'd welcome any suggestions to further improve the situation.