RE: agenda+ SVG 2 Features and Approach

I'm really glad you asked this question Doug.  Folks have presented a lot of great ideas for improvements for SVG on this thread. 

I believe that SVG is a key component for the Web.  I have not been quiet about that.  I also believe that we are not tightly integrated enough with HTML and Web developer patterns to make that a reality.  I still see where people are embracing <canvas> over SVG where they shouldn't. I, like several folks here, have been writing papers and educating developers on when and how to distinguish between the best use cases for different vector graphics (http://msdn.microsoft.com/en-us/library/gg193983(v=VS.85).aspx); (the supporting blog post http://blogs.msdn.com/b/ie/archive/2011/04/22/thoughts-on-when-to-use-canvas-and-svg.aspx continues to get me more and more positive comments and requests from the community).

My big concern is that if SVG does not get adopted by Web Developers in the near term, SVG will be relegated to a vector graphic documents interchange format.  This is why I have been consistent in my message to establish core scenarios with the Working Groups, proposing modularizing specifications, and front loading efforts on integrating technologies that cross boundaries.

http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0114.html

http://www.w3.org/Graphics/SVG/WG/wiki/images/6/64/SVGCSSTPAC.pdf

http://www.w3.org/2010/11/TPAC/HTMLnext.pdf


The impediments to wide spread SVG adoption are (in order) 

 Integration
 Performance
 Education

Our responsibilities as a working group should be rooted in solving the first two problems, and then tangentially solving the last.  Ideas on how to improve core SVG mean very little for the web if very few use them.   We must establish and agree upon our priorities. 

My recommendation is that we focus on a short, modularized "SVG 2.0=integration" specification, which should include how to, at the specification level, provide a declarative and programmatic path for high performing vector graphics that apply to key scenarios.  I thought we had agreed on this.

I look forward to comments.

-Patrick Dengler



-----Original Message-----
From: Doug Schepers [mailto:schepers@w3.org] 
Sent: Wednesday, May 04, 2011 9:32 AM
To: www-svg
Subject: agenda+ SVG 2 Features and Approach

Hi, folks-

While we've talked about how we will be putting SVG 2 together, we have not talked much about precisely what SVG 2 will consist of.

We know that we plan to tighten up and clarify everything that was in SVG 1.1, clean up features such as namespace requirements, <use> and markers and shadow trees, improve the DOM, and generally make the model more consistent and easier to implement, and more clearly integratable with HTML.  We know also that we will continue on our progress towards adding SVG features to CSS, such as gradients, transforms, declarative animation, filters, and so on.  For all of this, we know that we will be adding a more comprehensive test suite for better interoperability.

But beyond that, it would probably be good for us to define a clear scope for what other features, unique to SVG, will be added.

I can see 3 likely approaches:

1) We simply make do with improving what we have already, and what we will work on with the CSS WG, with an aim to complete it in the next 1 to 1.5 years;

2) We add a modest set of high-value new features, based on identified need and public feedback, with an aim of 1.5 to 2 years;

3) We take a more ambitious approach and revise the language considerably (though with backwards compatibility in mind), and add several new major features (again, based on identified use cases), aiming to finish in 2 to 3 years.

Obviously, my favorite approach is (2), with the aim of showing clear signs of SVG progress to the community, and having a clear goal to work towards so we can better gauge our progress.


With any of these, we will likely continue to add features in a modular approach, probably concurrently with the development of the main spec.

For (2) and (3), we will need to decide on a list of must-have new features, and another list of nice-to-haves.  Obviously, this list will change a bit over time, but we should have at least a concrete goal.

As an example, on my personal list of must-have is parameters, non-scaling strokes, improved text-flow to arbitrary shapes, and new gradients; my nice-to-haves include connectors and skeleton-frames, and variable stroke width.


I'd like to start this conversation in earnest with the SVG WG, and with the larger community.  What approach does everyone else advocate, and what new features should have which priority?

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Received on Thursday, 5 May 2011 16:14:06 UTC