RE: agenda+ SVG 2 Features and Approach

Doug,

I'll vote for (2).

I just reviewed the options with my product manager, and we feel that non-scaling line strokes are the long pole in our tent.  Our use case is technical drawings (aircraft maintenance manuals), in which the visible width of the stroke (and stroke pattern) shouldn't change when zoomed in order to show in finer detail the specifics of the drawing while maintaining the contextualized meaning of the stroke pattern, color and width.

Connectors -- which I take to mean stroke endpoints that anchor to path elements -- are a very nice to have, but lower priority in the technical publication viewing realm.  Authoring can fix this to an extent by being careful about how they construct the SVG.

Those two (or maybe just the first one), will bring SVG to parity with CGM for most technical publications use cases.  Combined with the existing SVG features, and integration with existing JS engines has the opportunity to be a disruptive force in the space.

Thanks,
 ~ Paul

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Doug Schepers
Sent: Wednesday, May 04, 2011 10: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 Wednesday, 4 May 2011 19:40:42 UTC