- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Thu, 29 Apr 2010 17:38:56 +0200
- To: cyril.concolato@telecom-paristech.fr, www-svg@w3.org
Hi Cyril, Doug, well, especially many older parts of my test suite base on real existing use cases, I wanted to realise in 2005. Due to bugs I was forced to write those tests and find out, which workarounds work better. Unfortunately for many applications those workarounds have no good quality at the same file size compared to the optimal solutions. Either I never published those workarounds or these are large files or are of low visible quality and I stopped to try to get it better, because this was practically limited by bugs of viewers or by the file size of a qualitatively good workaround with a blown up source code. In some cases I did not event start to provide some applications, just because I knew already, that they will currently not work or only in one viewer. In some other cases it turned out, that the workarounds are beyond the capacities of some viewers with a less effective usage of the processor power. If bugs are not fixed or the features are simplified even more, I think, I would not have started to care about animation with SVG at all, because it would not have been attractive enough for most of my use cases. If this is the case for other authors (and most typically wait until major implementations of a format are really good enough), I think, the majority does not even have started to publish content of good quality in SVG due to these bugs. And the others remain in the low quality limitations or will never start to care about the format. Of course, there are some tests of pathological cases as well - we have to explore those to find out, what went wrong in the past - and several of them are already fixed in newer recommendations with the result of an increasing quality of the format itself. Obviously this does only change the test situation for the newer versions, not for the older. But once, the newer versions are implemented, authors can concentrate on them and do not have to care about pathological cases in older versions of the format anymore. If 'simplify the format' means, that authors have less or no options to realise, what they are interested in, I think, this is the wrong way. With this, the format will get soon boring and loses unique features to distinguish it from other arbitrary formats. If it is too simple, one can just use a video or some flash-file to get a similar simple effect. Why should authors chose the format, if it has no better options than others (they are maybe already familiar with?). And if I look on many files/applications I simplified already due to bugs and gaps in viewers - if this is the final solution of the problem, well, maybe better to provide java-applets and text alternatives ;o) And if simplification means, not to publish interesting applications at all - I think, this does not really help the audience, if those solutions remain on the local file system of authors, just because life is not always simple, unfortunately ;o) Cyril Concolato: > > I don't know exactly the full extent of your tests, it's been a long time > since I checked them. I guess that many of the differences between viewers > exist probably because they concern very specific features of the spec, > maybe sometimes pathological cases. Viewer implementors are probably not > fixing them because it's not worth the effort. They often ask the question > of how many users will benefit from this bug fix. From this point of view, > I'm not sure that the best choice is to incite them to test, debug and fix > their viewers. Another option could be to simplify the spec, deprecate the > parts that are not interoperably implemented and discourage authors to use > them. > > Cyril Doug Schepers: >Indeed, one of the goals of the FX TF (the new joint CSS-SVG Task Force) >in to define a simple common animation model underlying both CSS >animation and SVG animation, with different syntaxes but the same >functionality at the core. Obviously, CSS animation will also be able >to apply to SVG. CSS animations/transitions - with some improvements look nice for some decorative simple effects, however they do not compare to SMIL animation - and applied for example to text in XHTML or other text formats this will be typically sufficient. If one needs to visualise well defined effects, this will be often not sufficient. This is not necessarily a problem, if such applications never occur for XHTML+CSS, however, graphics is often used to illustrate some more advanced effects with other requirements. If this is not available due to permanent bugs in viewers or due to 'simplifications' of well considered methods, the result will be frustrating and disillusioning for authors with higher qualtiy requirements than just getting a cheap decorative effect, that works somehow. There is nothing wrong in having only in basic subset in CSS animation with the same functionality, just because for XHTML+CSS advanced functionalities like spline animations and animateMotion along a path will be typically not very important. And if authors need such advanced features, they can switch to SVG+SMIL animation. By the way, SMIL has a basic subset as well already, but CSS animation was never compatible with this, it was almost a reinvention of the wheel compared for example to timesheets ;o) Hopefully the adjustments with the joint CSS-SVG Task Force will result in a well defined model of 'events' for CSS animation, because I think, something like :hover, :focus and :active are not well defined concerning animation and timing. The event-value model in SVG+SMIL is clearly more useful, already for simple decorative effects ;o) On the other hand the CSS transitions are a nice idea, which should be cultivated for SVG+SMIL as well to provide some simple solutions for often complex problems from the authors point of view. But we did not manage to solve the related problem with to-animations for animateTransform for SVG tiny 1.2. Hopefully this will work better in the future in the interest of authors and users... Olaf
Received on Thursday, 29 April 2010 15:44:41 UTC