- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Tue, 27 Apr 2010 11:31:42 +0200
- To: www-svg@w3.org
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