Re: SVG DOM.next

Hi Patrick,

Welcome! It's great to see you posting to the list. Thanks for sending in your
thoughts and questions.

I'd certainly agree with you and others that significant parts of the SVG DOM
are a lot heavier than they should be, especially given what we know now, and
given the invention of WebIDL. I'd rather avoid versioning if we can help it though.

I'm glad to hear that you're comfortable with our current direction for
SVG.next. I presume you're specifically referring to the proposal to use WebIDL
to radically simplify the DOM interfaces? (Of course there will be a fair bit
more to SVG 2.0 than than.) As far as the details go, it's early days yet, and I
think we can do a lot more, but certainly the direction is to try to
significantly simplify things for content authors while fixing DOM bugs and
adding sorely missing DOM functionality.

As far as tools go, I'm not too concerned about SVG DOM changes. I'm more
concerned about existing content out on the Web, and authors that may be using
the existing SVG DOM. Authors are a lot less likely to go back and fix content
they've created than tool users or tool extension/plugin authors are to update
their tools/code of course.

You talk about presentation attributes and cleaner separation between style and
SVG, but I'm not sure exactly what problem you see in this specific instance.
It's also maybe worth noting that HTML has the same sort of thing - ie the
"color" attribute can map to the "color" CSS property with specificity zero.
Certainly there are other CSS integration issues though, and the CSSValue and
SVGColor one was unfortunate. The proper course of action for implementers would
be to follow the SVG WG's decision, and hopefully take part in making that decision.

Regarding separation of concerns, I think we (SVG WG) should focus on content
facing API, and let tools do what they want. Happily I don't think there's a
conflict in practice though.

I think SMIL is fairly well decoupled from SVG on a conceptual level, but I'd be
interested to hear of specific coupling issues you see in the spec and
suggestions on how you might like it changed.

At this stage of SVG 2.0 we are very open to suggestions to "move SVG in a
direction more towards Web developers". The better we can address the needs of
content authors and make their lives easier, the, uh, better. :-)

Finally, don't worry too much about protocol when posting to the list. We're a
fairly relaxed bunch, and if anyone has any issues I'd hope they'll make polite
suggestions rather than anything else. Being concise, clear, focused and polite
is always good (not sure I met all those in this message, but it's good to aim). :-)

Again, good to hear from you, and I hope to hear more from you and others from
Microsoft in the future.

Jonathan Watt
Software Developer
Mozilla Corporation


On 2009-11-12 4:00 PM, Patrick Dengler wrote:
> 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 Monday, 16 November 2009 17:15:25 UTC