Hi Patrick,

	You raise some very interesting points and questions.

	I'd like to add my 2c of opinion on the DOM in general
and the SVG versions of it just to give a bit of historical
perspective. Hopefully this will help to manage your expectations
about what is here now, and what can be realistically achieved
in the future.

	There are some comments inline below, after the initial
historical diatribe...

	When I joined the SVG WG in Jan 2002 there were no
implementations of SVG 1.0 Full. By no, I mean there was no
single implementation that implemented all of the spec. I
believe this is still the case today. There are some very
good implementations out there, but no-one has yet implemented
all of the spec. The implication of this, is that each
implementation implements a given subset of the spec. and
these subsets vary.

	The result of that is of course, that authors need to
generate content either targeted at a given implementation
or author to the lowest common denominator subset.

	The Full DOM itself falls into that category, not just
the SVG graphics features, and so we have a half-baked landscape
at the moment.

	Adobe's viewer was for many years the de facto engine that
authors used to test content, but it had it's own quirks and
more recent implementations are more correct at the expense of
breaking legacy content that exploited those quirks as well
as a lot of Adobe Illustrator content that generated output
that exercised features in the private Adobe namespace, and no
other viewer supports.

	SVG 1.1 was developed simply as a profiling mechanism
to allow chop and change pieces of SVG 1.0 Full to be used
for various profiles - Tiny, Basic. But after 1.1 was complete
the group developed a _lot_ of different features.

	2 of those features that made it into SVG 1.2 Tiny
are text wrapping and the micro-DOM. Why I mention text wrapping
is that it lives in the same boat as the micro-DOM, namely
the 2 features that the browser writers, specifically some of the
members of the WHATWG objected to feverishly. They were so
adamant that these features did not have a place in SVG that
a rather nasty denial of service attack was made against the
SVG Tiny 1.2 specification being completed that wasted an
inordinate amount of working group members time and in
the process made one wonder if the objections to the 1.2 Tiny
specification were intentionally malicious or just the
product of a misguided soul.

	That deliberate attack on SVG 1.2 Tiny was primarily
against (1) text-wrapping; and (2) micro-DOM.

	It is a fact that for many years the number 1 request
for SVG was a simple form of text wrapping. I personally
opposed it at the time, since it's not what I consider to
be sensible in a presentation language such as SVG but in
any case as good Working Group members we defined text wrapping
in arbitrary shapes and subset that to support just a single
rectangle for Tiny. That action triggered some second tier
browser implementers to abuse us at the time, despite us
working toward the provision of our number 1 requested

	So after that digression, we come to (2), the micro-DOM.
I have heard many people criticize this as unnecessary. But
some perspective of its origins and what it does is really
necessary. I'd also like to say that one of the most standards
compliant implementations of SVG in Opera does support the micro-DOM.

	The micro-DOM idea originated from Peter Sorotokin of
Adobe. He was one of the main developers of the Adobe viewer and
I worked with him at Adobe for a number of years after the last
release of the ASV6 technical preview on another project in
similar technology.

	Peter realised that the full DOM was a performance
disaster. The main issue he saw was that round tripping into
and out of strings with normal DOM method calls was hopelessly

	His original proposal for typed 'trait' methods would
avoid stringifying everything and make for a much more efficient
API to the DOM tree.

	It's pretty obvious that converting a floating point
value into a string to send it into ECMA-land, conversion from
string into a number in ECMA script, performing some numerical
calculation, re-stringifying the result, passing it back to
some DOM method, native code re-parsing the string to get
the result was a really dumb idea. The micro-DOM aims to
eliminate the vast bulk of conversions by making the native
types available through traits.

	With the current focus on high performance JS
engines such as V8, Squirrel Fish, Trace Monkey etc. it
seems the general web world realizes that JS performance
is really important for a decent web app experience.

	The micro-DOM effort had the same motivations
in mind yet predates the new breed of JS engines by
a number of years.

	In any case, it took 7 years to go from 1.1 to
having 1.2 Tiny ratified as a Recommendation. As such,
any for 2.0 or whatever is likely to have a
very long gestational period.

	If one were to sit down to implement SVG today,
using the existing 1.1 DOM and adding the 1.2 Tiny
micro-DOM is likely to give authors the most powerful
set of options to get performant web apps using SVG.
All of the micro-DOM in 1.2 Tiny should be implemented
and it's already on millions of mobile devices. However,
it is most likely that a carefully chosen subset of 1.1
Full DOM would likely cover all existing content as well
as provide enough for the transition between 1.1 Full
and 2.0 Full. I suspect a number of 1.1 DOM methods
may fall into the deprecated basket, given a lack
of both implementations and content using them.

	Phew, sorry for the diatribe. More inline...

--Original Message--:
>Hi folks,
>I was reading up on the WG's SVG DOM proposal ( 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).

There is general agreement that the Full DOM is heavy handed. But it
does have some very nice features as well (e.g. getting an x, y
co-ordinate at a given length along a path - that would be impossible
in plain script).

>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.

Yes. You may also want to take a look at Adobe's Mars. That is a
'PDF represented as SVG' specification that maps 1:1 with your
document use case and limits the SVG permissible.

>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.

Yes, and these sort of applications can be greatly enhanced through the DOM.
For example, pulling TV guide data from a server and inserting the data into
the current view via script is a good use case.

>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. 

Not just the web developer community. Entire next generation user
experiences such as IPTV, mobile widgets, etc. are all based on
web technologies and use SVG as a core part of their design. OMA
have also based their rich media environment (RME) on SVG Tiny 1.2.

This application area, "rich" apps whether in a browser or jumping
out of the browser like Silverlight, AIR, Mozilla PRISM, Opera
widgets, etc. seems to benefit the most from SVG and a good DOM.

>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.

This is a pain point.

The old chicken and egg problem. There is an incredible amount of
capability built into SVG, especially around SMIL that is not
supported by a single authoring tool. I don't know what the
solution for that is, but certainly there is a lack of decent
SVG authoring applications that exploit all the facilities available
in the language.

BTW, integration of SMIL with HTML and SVG if done well can
give an amazing amount of flexibility. Internet Explorer since
version 5.5 supports the HTML+SMIL profile, yet very few people
seem aware of that. My collaborators tell me it's a very
good SMIL implementation too, but I can't say I've seen
a lot of content that uses it.

>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  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)

I'd agree with that.

>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".

There was an effort from Corel a few years back to provide pre-authored widgets
in SVG and the tool would create web apps as output. So, these obviously
need some SVGDOM support for the tool.

However, how much of the SVGDOM is useful is really the question.

>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.

I don't have a strong opinion on this, others probably do.

>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.

I believe that surveying web devleopers to see what they want is a
good starting point. Like when we listened and put in text wrapping
and got crucified by the non-believers. It's the users that matter
not the implementers!

As for 2d flow layout, gasp is the right word. Everyone can see the
need, but defining a solution that satisifies all the players without
a huge blood bath seems difficult at best:-)

>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?"

Well I think I just out did you on length - nothing is off topic,
those are all good questions and points.

The bottom line though, is that over the years there have been
more critics of the SVG WGs decisions than there have been

Typical reactions go along the lines of "I mailed the WG about
feature <x> and nothing was done, so they suck and in fact
standards suck". Nothing could be farther from the truth,
the fact is that the working group is just that, a working
group - and they _work_. In fact the majority have day jobs
and that day job means representing their company on the
working group, write code, etc. Feature <x> was probably
discussed at length after the email was received and no-one
on the group had spare time to take up someone else's issue.

The only way to have features put into SVG or any other W3C
spec is to participate in the group, attend teleconferences,
face to face meetings and back your cause. No existing member
will ever find time to write up someone elses proposal no
matter how good it is, yet the outsiders never seem to take
that into consideration.

One has to do the work, or the work will never get done.

Thanks for reading this far, I'll stop now before I
offend too many people:-)


>-Patrick Dengler
>Senior Program Manager

Received on Wednesday, 18 November 2009 03:28:37 UTC