- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 10 Mar 2006 14:48:46 +0100
- To: Chris Lilley <chris@w3.org>
- Cc: "Andrew Emmons" <aemmons@opentext.com>, www-svg@w3.org
* Chris Lilley wrote: >The attributeType is purely to allow disambiguation in the case of a >name clash between a property and an attribute. Yes, to identify the target, which has a type with an associated base type and an associated domain. SMIL 2.1 discusses this in detail and requires that values are valid for the domain of the target. I agree that the copied and pasted bits in the draft under discussion are not clear about a number of details relevant here, but thankfully it is pointed out that the normative definitions can be found in SMIL 2.1. >It does not allow in unusual syntax for attribute values, as you seem to >believe. I agree that the confused references to attributes in SMIL Animation and all the specifications that copied text from it is unfortunate. Clearly, when attributeType="CSS", the target of the animation is a property, not an attribute. So all the things you say about attributes are irrelevant. I'm not really sure what's so hard to understand about the fact that for attributeType="CSS" all processing is defined in terms of DOM APIs and style sheets. >Wrong. It would indeed be allowed for a CSS property, if that CSS >property took scientific notation. Yes, but since "scientific notation" is specifically prohibited for all CSS properties defined in the family of SVG and CSS specifications, that is not really relevant. I can see no evidence in SMIL 2.1 that e.g. <svg:... xml:id="t" ...> <set attributeType="CSS" attributeName="font-size" to="1e2" ... </svg:...> would be different from ... document.getOverrideStyle(t, '').setProperty('font-size', '1e2', ''); ... which, 1e2 beeing an invalid value, cannot have an effect. You seem to think the process is rather ... document.getOverrideStyle(t, '') .setProperty('font-size', SomeMagicFunction('1e2'), ''); ... You've so far failed to cite where SMIL 2.1 defines SomeMagicFunction. In the light of this, you might want to argue that it is not clear whether to="red!important" maps to which of d.getOverrideStyle(t, '').setProperty('fill', 'red!important', ''); d.getOverrideStyle(t, '').setProperty('fill', 'red', '!important'); or what the result would be in case of the former; I agree that it's not clear, and as a result SVG implementations do not interoperate, hence this issue. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Received on Friday, 10 March 2006 13:54:38 UTC