Re: Interim strategies for no SMIL (and other?) support in IE9

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