Hi all,
As has been noted by Alexandre, the first public draft of SVG 2.0 has been released:
http://www.w3.org/TR/2012/WD-SVG2-20120828/
While this is a very early draft and will be unstable for some time, I don't think it is too early to make plans on how Inkscape will handle incorporating new SVG feature. SVG 2.0 will bring many things that will benefit Inkscape. Here are just a few:
Mesh Gradients New blend modes New ways to specify color (CSS3 Color) Named colors Markers inheriting stroke color Hash lines Variable stroke placement (inside/outside path) Fill over stroke 3D transforms
Before I make a proposal, I will review the status of the SVG in general. As many of you know, SVG as a standard almost died when Adobe bought Flash. (Adobe was the main driver behind SVG at the beginning.) The SVG Working Group (WG), which once had more members than the CSS WG, shrunk to just a handful of active participants. With SVG now being a core component of HTML5 and with SVG being added to IE 9 and the decision by Adobe to stop development work on Flash, interest in SVG has grown. New members have joined the WG over the past year. (The group is still smaller than the CSS WG which limits the speed that the SVG 2 specification is developed as well as what can be added.) In addition to renewed interest in SVG proper, there is interest in adapting many SVG features for more general use on the Web. Many parts of the SVG specification are being ripped out and made into stand-alone specifications shared with the CSS WG. These include Transforms, Blend modes, Filters, and Colors. These sections are maturing fast and experiencing rapid adoption by browser vendors. You can already use HSL colors (from CSS3 Colors) inside SVG in current versions of all major browsers. Transformations should be usable soon. In summary, SVG is moving forward and doing so rather quickly.
How should Inkscape handle new features?
First of all, as Josh has stated, we don't want a repeat of the flowtext fiasco where Inkscape implemented a feature that ended up not being added to the SVG specification. We should only enable stable features in our official releases. One indication of stability is the implementation of a new feature by one or more browser vendors without using a vendor specific prefix. HSL color is one example of this.
We should encourage new features in unstable releases. It is important to the SVG specification development that there are working examples, even if only partially implemented, as it demonstrates a user desire for the feature and it gives the WG a chance to test and experiment with it.
Second we should be backwards compatible with SVG 1.1 when feasible. By backwards compatible, I mean being able to read and write SVG 1.1 files. Some things are relatively simple to handle. HSL colors can be easily converted to RGB colors. Others like mesh gradients may require using a PNG.
What I propose, is that as new features become stable, we modify the internal Inkscape code to use them while at the same time adding an option to export to SVG 1.1. In many cases, this will have the side benefit of simplifying our code. For example, matching marker color to stroke color now requires some rather complex code to create new copies of a marker for each different colored path as well as monitor changes to stroke and fill color.
What do others think?
Tav