- From: Alex Danilo <alex@abbra.com>
- Date: Wed, 18 Nov 2009 14:27:55 +1100
- To: "www-svg@w3.org" <www-svg@w3.org>
- Cc: Patrick Dengler <patd@microsoft.com>
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 feature. 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 inefficient. 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 DOM.next 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 (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). 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 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) 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 contributors. 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:-) Alex >-Patrick Dengler >Senior Program Manager >Microsoft > > > > >
Received on Wednesday, 18 November 2009 03:28:37 UTC