SVG DOM.next

Hi folks,

I was reading up on the WG's SVG DOM proposal (http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API) as well as much as I can regarding recent discussion this WG has had about the future of SVG.  I've only looked at SVG since March, so please forgive any ignorance :)

It seems to me that it is generally agreed that the SVGDOM is heavy handed (?) and moving things forward while keeping things backward compatible is a challenge (though versioning might be the right answer here as folks have recommended).

A few key use cases that I have been thinking around when analyzing the details of SVG include:

1. Documents -> The use of SVG to draw static, graphically rich documents with high fidelity.  For this use case, it appears to me that the set of SVG elements provided are great, and improvements that have been mentioned for SVG 2.0 only make them better. I don't see any primary use cases of CSS, SMIL or the SVGDOM here.

2. SVG "applications" -> Much like Tiny 1.2 uses SVG for user interaction, there is clearly a great use case for SVG (in some cases combined with HTML) to create interoperable "applets".  For great user experiences including "skinning" or "theming", as well as indicators such as "triggers" or "cues", a developer would want both CSS and SMIL.

3. Richer "web apps" -> I'm trying to be careful here not to step into any specific overused terms, but what I am referencing here is those experiences that are surfaced through a browser, tethered to a server, which benefit from the intrinsic graphic capabilities that SVG provides, which is absent in HTML today.  Obviously this work is a great ongoing discussion. I've referred to this scenarios as WSVG, and believe that the same capabilities that are desired for scenario #2, are desirable here, with the additional caveat that these are (IMHO) going to be the predominant use of SVG going forward, and are going to be brought to our users via existing "web developer" community.  

4. Tooling -> For creating SVG specific content (i.e. not exported documents from CAD or other diagramming software), tool vendors *may* want the SVGDOM as is (with the latest improvements from 2nd edition), as the best method to deliver this scenario.

When I shrink my little brain around the above scenarios, I have the following questions (with my own gratuitously injected answers)

1. Is the WG's current direction correct for SVG.next?  Yes.  While the SVGDOM is sophisticated (and some may say complicated) the primary target developer audience for SVG.Next are "web developers" which are comfortable and confident with using DOML2/3 interfaces.  And while the SVG types are a little more sophisticated in some cases (paths, coordinates), the trade-off between having to manage these in something like jscript vs. learning N number of different SVG specific interfaces seems worth it.  AND, following that thought, these interfaces that the WG has proposed should be adopted by the folks working on DOML3, with the possible addition of list interfaces. (Anecdotally, most who I have spoken to, even on significantly large production projects for SVG are not using the SVGDOM)

2. What then for tooling? Well, for tooling, if the SVGDOM is necessary (love to hear if it is) perhaps there is a separate module for "DOM for Tooling".

3. Ok smarty pants, then what about "skinning"? I think that the usage of CSS for setting "presentation" properties has been a great move.  But I wonder if a cleaner separation between style and SVG should be made.  HTML is for all intents and purposes separate and distinct from CSS.  Shouldn't SVG just declare the attributes as required or not, and define behaviors when not required, and remove significant references to CSS from the SVG specification? (I know there have been threads on this one).  As an example, the close tie between CSS and SVG, and the DOM WG's obsoletion of CSSValue, and SVGColor deriving from CSSValue puts an implementer in a difficult position of choosing to either follow the DOM spec OR follow the SVG spec.

4. If you would consider moving SVG in a direction more towards "Web developers" what else would you consider? I have always believed in clean separation of concerns.  In addition to separating a "programmable" DOM from a "toolable" DOM, as well as divorcing CSS a little more from SVG, shouldn't SMIL be separated as isn't SMIL interesting for HTML? (I do believe there has been a lot of chatter on this one as well). And lastly (gasp), 2d flow layout.

It's really impressive to watch the direction of SVG, and as well see SVG's "coming of age".  I appreciate any response, as well as your patience with me if I have violated any rules of conduct including "off topic", "too broad", "too long", "not enough substance" or "WTF?"

-Patrick Dengler
Senior Program Manager
Microsoft

Received on Thursday, 12 November 2009 17:24:58 UTC