Re: animate-elem-46-t.svg

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