- From: Antoine Quint <ml@graougraou.com>
- Date: Mon, 17 Jan 2005 09:01:40 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-svg@w3.org
- Message-Id: <053393D2-685E-11D9-BB78-000393D124C4@graougraou.com>
Hi Björn, On 13 janv. 2005, at 16:27, Bjoern Hoehrmann wrote: > according to section 3.6 of SVG 1.2 the animate element's target is the > first my:p element. If the xlink:href attribute is removed, the target > would be the last my:p element. This does not seem to make much sense, > it seems that the xlink:href attribute is abused here and one needs to > change the semantics of the custom fragment to change the behavior, > e.g. > by using a different value for xlink:href or by removing the attribute > alltogether. The behavior described in section 3.6 is consistent with the animations work in SVG in general. Given that, I think it is important to match this functionality in sXBL integration within SVG with regards to custom animation elements. > It further seems that implementations are not required to expose the > animated value of attributes on custom elements, which means one cannot > write script code that considers new animated values which means that > animating attributes on custom elements would have little effect in > practise. In fact, implementations are required to expose animated values of attributes on custom elements via traits. There is a <traitDef/> element to specify the datatype of attributes on a custom element, a complete set of APIs to access the attributes, and trait mutation events to be notify of changes. In my opinion all the pieces are in place for providing custom animation facilities in SVG+sXBL. Antoine -- Antoine Quint <aq@fuchsia-design.com> W3C Invited Expert (SVG and CDF) SVG Consulting and Outsourcing http://svg.org/user/uid:2/diary
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 17 January 2005 08:02:55 UTC