Re: animateTransform has no default value for 'type'

> Did you check, in which viewers this works?

You mean in which browsers this works? Defining attribute lists in the document type definition (DTD) is part of the XML standard, so this should work in all browsers. I can confirm FF, Op, Ch, Sa.

Since IE/Edge does not support SMIL animations, this specific example will not be animated in IE/Edge, but this is another problem, of course. (Poor souls who use this crappy software!)



> On Jun 11, 2017, at 17:41, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de> wrote:
> 
> Johannes Schoenke :
> 
> ...
> 
>> By the way, I realized that there is at least a simple way to set attributes 
>> globally by setting an attribute list in the DTD. The modified code example 
>> would then look like this:
>> 
>> 
>> <!DOCTYPE A [
>> <!ATTLIST animateTransform
>> attributeName CDATA 'transform'
>> type CDATA 'translate'
>> dur CDATA '7s'
>> repeatCount CDATA 'indefinite'>
>> ]>
> 
> ...
> 
> Did you check, in which viewers this works?
> At least to define entities to reuse some code is the usual approach in SVG 
> right from the beginning, there are even examples in the recommendations SVG 
> 1.0 and 1.1.
> 
> Note, that the CSS animation module is still no recommendation, it is in the 
> best interpretation experimental, but because the most current working draft 
> is from 2013, the idea is maybe already obsolete due to no progress in the 
> recommendation process ;-)
> We simply should forget about it, until there is some thought out 
> recommendation.
> And even then, CSS ist about styling and decoration, not relevant for content.
> If you have animated content, in practice there is only the declarative way 
> with SVG/SMIL animation (animateTransform ist SVG specific anyway).
> 
> For many works I simply use a script language PHP to generate SVG output due 
> to similar problems, that there are no efficient ways to provide expressions to 
> describe similar content fragments in an efficient way.
> Suggestions and drafts from different people to avoid blowing up source code of 
> SVG documents with redundant information were rejected early in the SVG 2.0 
> process - and even most accepted ideas and requirements for SVG 2.0 were never 
> realised or were removed again from the current draft.
> Not much chance to get something new unfortunately, W3C is effectively in agony
> and stagnation or even regression concerning the core formats for years now.
> 
> 
> Olaf
> 
> 
> 
> 
>

Received on Monday, 12 June 2017 03:03:56 UTC