W3C home > Mailing lists > Public > www-svg@w3.org > February 2004

Re: Snapshot draft of SVG 1.2 released

From: Peter Sorotokin <psorotok@adobe.com>
Date: Thu, 26 Feb 2004 22:07:49 -0800
To: Cameron McCormack <cam-www-svg@aka.mcc.id.au>, www-svg@w3.org
Message-id: <5.2.0.9.2.20040226215714.02bb7e58@mailsj-v1.corp.adobe.com>

At 11:12 AM 2/27/2004 +1100, Cameron McCormack wrote:

>Hi Chris.
>
>Chris Lilley:
> > http://www.w3.org/TR/2004/WD-SVG12-20040226
>
>Some feedback:
>
>17.3 Typed access to attribute values
>
>A unified way of getting the "traits" of SVG objects is a good idea.
>Do you feel though that the optimisation of attribute/property names
>down to indexes or "trait accessors" is worth it for performance?  I get
>the impression that for users of this feature, code might look like it
>is using an extra level of indirection, forcing the author to do
>optimisations on the client side rather than in the implementation
>itself.  Though I realise that this would make things easier for the
>implementation (not having to parse attribute names all the time), I
>think the general goal should be to make things easier for the users.

It will get some performance, but strings are disliked by many mobile
implementors. Some actually even prefer integers - do you think it would
be a good idea? (Both from implementation and authoring perspective)


>Also, are you sure you want to allow events listeners to be added for
>trait mutations, especially when animation is involved?  I had got the
>impression that SMIL animation in SVG was considered continuous and as
>such it wasn't possible to have some script run on every single
>animation tick.

It certainly is possible; it just will run with different frequency on 
different
machines.



>4.1.5 The transformer element
>
>"The transformer element is likely to be removed from the next draft of
>SVG 1.2, due to the high burden on implementation and the difficulty in
>optimization."
>
>A shame. :-(

Basically if we add declarative syntax, it has to figure out the dependencies
and re-run "as needed". This dependency calculator is fairly hard to do
for arbitrary XSLT (and it is not a part of standard XSLT libraries); it is 
a bit
easier for just XPath, but it is still hard and there is resistance to 
doing XPath
without XSLT. Another problem is that if both script and XSLT are modifying
the shadow tree they step on each other's toes. What do you think?
Your experience seems to be very relevant here.


>Will you still be considering it for SVG 2.0 (or whatever the next SVG
>will be)?
>
>
>Response to feedback would be welcomed.  Though you elicit feedback to
>these drafts, I noticed last time that hardly any responses from the WG
>were made to the feedback given by many people.

Ah, that was before I subscribed to that list -- just kidding.

Peter


>Cameron
>
>--
>Cameron McCormack
>|  Web: http://mcc.id.au/
>|  ICQ: 26955922
Received on Friday, 27 February 2004 01:09:19 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:26 GMT