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

Doug Schepers: 
>So, the question remains... how to best manage the transition?

When I started with SVG back in 2004, ASV did not even work on my linux
computer. What I have seen was often somehow surprising compared
to the recommendations ;o)
Some months later I managed to see some SVGs on KSVG+Konqueror, 
Amaya, ASV and Opera 8 - and soon I realised, that none of them 
really did, what was written in my files (often containing animation)
according to the recommendations.
Therefore I started to write a systematic test suite for animation
(meanwhile more than 1300 tests) and it turned out, that really none 
of them has a good support for many of the tested issues. 
Meanwhile there was a lot of progress especially with Opera 9/9.50 and
I added Batik/Squiggle and webKit to my test ensemble as well - but
still the statistical results show, that authors cannot rely on the
capabilities of these viewers in several cases. And because they 
typically have different bugs and gaps, there is no simple way for authors
to get predictable behaviour for all of them in many cases.
Currently for some simple documents one can look into the results
of those systematic test suites to get an impression, what can be
already used - and of course one can add a list of viewers (with
versions), the document should be presented correctly.  
For authors this situation is frustrating - and because for some
viewers there seems to be some stagnation and no big progress
over the years/versions the situation does not really converge to
a point, where an author can really believe, that a document
will be presented as specified in the recommendations.

Therefore I think, it is not a question of transition of documents
from one viewer to another. It is a question of testing, reporting
and fixing bugs and  gaps in all viewers. In some cases the document
can be simplified with some workarounds to get a proper presentation
in several viewers, but only by following results from systematic tests.
And often such simplifications are semantically less rich than the
intended version. Finally authors should write proper and semantically
rich documents, not 'optimised' or 'pessimised' for this or that viewer.
They should not have to care about bugs and gaps, this is the task
of testers and implementors. Following this, for proper documents
no transition is required. Of course, many documents are not really
bug free and proper written. To improve this is the task for authors,
but not to align docments to a specific version of a specific viewer ;o)

And of course, there is still one generic option for authors. SVG has
powerful accessibility features. And of course the usage of a faulty
viewer is a question of accessibility as well, not just personal attributes.
Authors should always add a good text alternative to their SVG files.
With this, everyone can check, whether the presentation of the
used viewer is meaningful or not ;o)
Even if the viewer does not provide access to text alternatives,
in doubt they are available looking directly into the source code.


Olaf

Received on Tuesday, 27 April 2010 10:02:29 UTC