Re: SVG DOM.next

Hi Alex,

nice writeup, always interesting to read a bit of the SVG WG history, a  
few more comments inline below. Mail shortened a bit for enhanced  
readability.

On Wed, 18 Nov 2009 04:27:55 +0100, Alex Danilo <alex@abbra.com> wrote:

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

Opera 10 supports a majority of the uDOM yes. The parts we chose not to  
implement have significant overlap with existing deployed technologies,  
e.g XMLHttpRequest and Window timer functionality (for the related  
concepts in uDOM see  
http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGGlobal).

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

This is a good thing, especially for the attributes/properties that the  
1.1 DOM didn't expose easily - the CSSValue-based interfaces +  
SVGStylable.getPresentationAttribute made accessing presentation  
attributes much harder than it should be.

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

Depends on what you mean by static documents, but sure SMIL and script  
operations (using SVG DOM or any other DOM spec(s)) are things that I  
would consider "not static". CSS on the other hand makes plenty of sense  
for static documents too, e.g for applying the same styles to many  
elements -> more compact svg files -> potentially faster rendering.

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

That's partly dealt with in SVG Tiny 1.2, I'm sure you're familiar with  
'lacuna values'[1]? We have a bit of work left for SVG.next to define the  
things that are not part of SVGT12 but which are part of SVG 1.1 Full.  
It's a valid question, and yes SVG should clearly specify what the lacuna  
values are for all attributes going forward. I don't understand why  
removing references to CSS would be particularly useful though.

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

The SVGStylable.getPresentationAttribute method and everything it returns,  
well... there's hardly any use of that that I know of. The uDOM methods  
for accessing presentation attributes are much easier to use, and return  
more sensible types of objects.

It may be that the interfaces that deal with CSSValue should be deprecated  
in the SVG spec too.

Cheers
/Erik

[1] http://www.w3.org/TR/SVGTiny12/intro.html#TermLacunaValue

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 18 November 2009 21:32:16 UTC