- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Tue, 8 Jun 2010 18:05:51 +0200
- To: www-svg@w3.org, dholbert@mozilla.com
Daniel Holbert : > On 06/08/2010 04:06 AM, Dr. Olaf Hoffmann wrote: > > If you want to get it right for the full profile, > > I think, it is a good result to interprete already the > > tiny subset properly. And this test belongs to > > the tiny subset. > > I don't think I agree on your assertion here regarding this test, but it > actually doesn't particularly matter, because the specs don't actually > differ from each other on this point. Both specs contain this exact > language about attributeType (emphasis added by me): > > Specifies the namespace in which the target attribute > **and its associated values** are defined.[1] > > So when we have attributeType="CSS"[2], then the animated values are > expected to be "defined" in the CSS "namespace"[3]. Put another way: the > animation values need to be valid for the CSS property that we're > animating. And "30" and "12" (from the testcase in question) simply don't > satisfy that requirement. > > I don't see how one can come to any other conclusion from the above-quoted > language. > > ~Daniel > > [1] Sources for spec quotes: > http://www.w3.org/TR/SVG11/animate.html#TargetAttributes > http://www.w3.org/TR/SVGTiny12/animate.html#TargetAttributes > [2] (or "auto" in cases where "auto" is treated like "CSS", as is the case > for 'font-size' in animate-elem-46-t.svg) > [3] (Note that I'm intentionally using precisely the same words as in the > quote from the specs above, here.) Well, if you want to use 'namespace' as typically used, CSS has none at all (would have been a good idea to have one to be able to use a prefix instead of this nasty attribute). And SVG has another namespace than 'XML', it is 'http://www.w3.org/2000/svg'. This indicates already, that the meaning of 'namespace' here is slightly different, it is derived from SMIL. If one has a look into the SMIL recommendation, this is used as a synomym for a language or for a type of different structure or notation or abstraction level. For different namespaces indeed it is mentioned as well to use a prefix. For example one has to do it to animate href from XLink in SVG. According to SMIL (or what finally survived the review process for SMIL animation) is, that attributeType="CSS" means roughly to animate the property and attributeType="XML" means to animate the attribute with the name given in the attributeName. If there is a specific namespace deviating from the current of the animation element, use a prefix notation. If some construct has no namespace (like CSS), one cannot use a prefix to indicate, that this construct was intended to be animated and not a construct within the current namespaces of the animation element. Because the interpretation of attributeType and the relation to the sandwich model of SMIL was not clear in the SVG group, when I was an invited expert in this group, I had a discussion about this with the SYMM group (see there mailing list, discussions about SMIL3). attributeType does not indicate, that people from the CSS group or the XML group have to define these properties, this is possible too for the SVG group or others, defining specific properties or attributes. What remains is, that SVG defines properties (if you like the wording: in the CSS namespace), presentation attributes and attributes. And it defines for the full profile, that for lengths the units are optional, for the tiny profile that no unit have to be used at all (except for the attributes width and height of svg). In the styling section of the SVG recommendations it is noted, that some properties are shared between SVG and CSS. Therefore they are not exclusively defined by CSS, if applied to SVG. This is noted in the styling chapter: "SVG shares many of its styling properties with CSS [CSS2] and XSL [XSL]. Except for any additional SVG-specific rules explicitly mentioned in this specification, the normative definition of properties that are shared with CSS and XSL is the definition of the property from the CSS2 specification [CSS2]." http://www.w3.org/TR/SVG11/styling.html#SVGStylingProperties That units are optional or not allowed under some circumstances is such an exception, explicitly mentioned in the SVG specifications. http://www.w3.org/TR/SVG11/types.html#DataTypeLength Following the definition of font-size, a viewer has always to convert a value with a unit into one without anyway, not the other way round: "If a <length> is provided with one of the unit identifiers (e.g., 12pt or 10%), then the SVG user agent converts the <length> into a corresponding value in the current user coordinate system by applying the rules described in Units. Except for any additional information provided in this specification, the normative definition of the property is in [ CSS2-font-size]." http://www.w3.org/TR/SVG11/text.html#FontSizeProperty This simplifies somehow the animation of something like values="10cm;1in;300px;200pt;300mm;10em;8pc;30ex;80%" if an author is crazy enough to note this instead of only using units in width and height of svg - however nice idea for a test in my own test suite ;o) Due to gaps/bugs/problems in some viewers, even the usage of units in width and height of svg is problematic for authors in real live apart from test samples. Once I tried to adjust the size of some SVG in XHTML with width="40em" height="40em", but I could never publish this due to bugs in viewers. Olaf
Received on Wednesday, 9 June 2010 08:03:56 UTC