- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Sat, 19 Jan 2008 21:04:03 +0100
- To: "~:'' ????????????" <j.chetwynd@btinternet.com>, www-svg@w3.org
> Olaf, > > regarding my test, or http://olaf.kilu.de/svgtest/beginkey01.svg > they don't wfm with Opera 9.5 on OS X, please confirm what key > strokes and which system it works for you... Ok - you already found it yourself - but would have been no surprise, if the key combinations would have depended on the operating system ;o) > > with http://peepo.co.uk/temp/accumulate.svg > did you try what happens if you wait 5 seconds, view animation, then > click on box? Yes, I played around with it with several combinations. I still think, the behaviour of Opera 9.50 beta is correct here. Such animations, if restarted, cannot build on a previous run of the same animation element. It cumulates only in the same run or is additive relative to the static underlying value and other animations - new begin instance - new luck, completely starting from the beginning, forget about previous begin instances for the same animation element. > there's obviously a wide range of possible different mutations if one > also includes accessKey and even more UA results. No - I think this sample has a well defined behaviour, which can be derived from SMIL completely. > but is there a clear means to distinguish what is specified and what > is a bug. > > I guess not, but... Yes, but not completely trivial to find and to grap together in SMIL (and the old SMIL animation recommendations contains several minor bugs, inconsistencies and curious samples, therefore sometimes one has to derive the correct interpretation already reading SMIL2/3 to understand the old SMIL animation recommendation still relevant for SVG 1.1 ;o) Anyway, I think, for your example there are no general problems in the specifications, this is more a problem to understand, how begin and end time lists work and about understanding accumulative and additive behaviour. And your sample contains already about four challenges for implementors: - by animation - begin list value with mixed types - accumuate - accessKey And if there is more than one bug for these four features in the implementation it is not easy to understand anymore, what currently happens in a wrong implementation. Often with only one bug and a simple example one can derive what exactly was implemented wrong or what the programmer did not understand or did not read, but with two or three bugs for one example it often gets really hard to identify, what went wrong in detail. Therefore I often use simple tests first to get familiar with bugs for each feature. If they are fixed in an implementation, I try to combine more features just to see, if there might be more problems ;o)
Received on Saturday, 19 January 2008 20:08:30 UTC