RE: agenda+ SVG 2 Features and Approach

I think my vote would be so predictable as to cause a vortex of entropy: let's do it right even if it takes four years!

Heck, how old is SVG1.2? Why not plan to plan for the future?

My list of personal favorites, out of the 79 new features (plus or minus 28) that I've already fussed about, it will take a while to organize into strategic four year increments. Can we

a) have a few weeks to think?
and
b) spew forth our impromptu thoughts while reserving rights to retract later on?

Assuming both a) and b) , here are some things that come to mind:

1. Form the intersection of superpath, vector effects and connectors, preserving basic topology of orientation. (Markup-based relations between DOM objects need to be known, whether in SVG or in HTML5 or both)
2. declarative drawing (including at least some of)
 a. replicate
 b. extensions of <path> that include classic turtle graphics, parentheses and iteration), and relative coordinates
3. extended gradients (including at least some of)
 a. replicate
 b. contours
 c. diffusion curves
4. Extensions of the timing module of svg <animate> to include the ability to draw upon functional input from multivariate sources (rather than just keysplines and keytimes --as with <replicate>), e.g.,  from multiple curvilinear 2D paths.
5. enhanced text support 
 a. to allow multiple alignment of text along multiple lines: base, top and middle
 b. to allow glyphs to be squished into convex polygons
6. extensive support for randomization (random attribute values, etc)
7. alternative transforms (mesh, warp, spherical, conic, Mercator)
8. enhanced browser consistency in basic SVG interface
 a. consistency of zoom and pan (give us a widget if you can't agree!)
 b. a drawing widget 
  Rationale: HTML (hyperTEXTmarkuplanguage) has <textarea>
   <textarea> comes armed with word-wrap, backspace/delete, newline/return, cursor insertion,        selection/replacement, copy/paste (&rich text attributes?)
  Donc/therefore: SVG (svGRAPHICS) should have <tablet>
   <tablet> could come armed with basic drawing tools (polygon, Bezier, select, delete, copy/paste
    Drag, resize, rotate) *
 c. layers control (as with Photoshop layers)
9. non rectilinear layout models -- (consider how often graffiti flows into rectangles)
10. magnetism/gravity that allows labels of geographic entities to draw their labels (is not difficult in today's computational environment since most of 2D physics avoids undecidability)
11. 2.5 dimensional effects 
 a. local z-index --if global z-index is computationally impractical (think knot theory and planar four regular graphs)
 b. <replicate>
 c. perspective transforms (I think 2.0 already has these)
 d. global z-index (I get the sense jwatt is doing this?)
12. modeling translucency as beyond transparency 
13. SMIL data feedback (as per STELLA circa 1986 on Macs -- see http://www.iseesystems.com/softwares/Education/StellaSoftware.aspx )
14. accessibility: no it's not really an afterthought! What does it mean for geometry to be accessible? Let's think about it!

Fourteen is a nice number, but of course, I might like some time to think about the subject.

regards
David

* note: in 2006 we would have called "<tablet>" "<canvas>", but Deneba owned a trademark on "Canvas" as drawing software and we were not so bold as Apple.

-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Doug Schepers
Sent: Wednesday, May 04, 2011 12:32 PM
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 02:29:07 UTC