Re: SVG DOM.next

Hi, Patrick-

Thanks for sharing your thoughts.  We have been looking at the issue of 
the SVG DOM for a while, as you mention, so any specific feedback you 
have would be great.

We talked a good bit about this at today's telcon, and one of the 
outcomes of that is that I will start a new wiki page where we will list 
those DOM interfaces, methods, and attributes that are known to have 
issues, and which may be fixed or even dropped in SVG 2.0.  Hopefully we 
can get enough author and implementer feedback to make this a meaningful 
exercise.

If we can get everyone on the same page going forward, we would have a 
lot of latitude in how much we can change.  I'd be interested to hear 
from everyone in the SVG community what parts of SVG's DOM are 
indispensable, and which parts could safely be changed or removed for 
the sake of ease of implementation and optimization (performance, speed, 
etc.).

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


Patrick Dengler wrote (on 11/12/09 10:00 AM):
> 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 21:46:19 UTC