Re: SVG 2 FPWD published (animateColor)

Brian Birtles:

...
>That's my primary concern with animateColor. The other being that I 
>think the existence of animateColor unnecessarily complicates the Web 
>platform for authors.

That would have been a good argument in the last century, when the
first SMIL animation appeared and maybe later, when the fist draft for
SVG 1.0 appeared, but now we have it. And it is used by authors for
basically two reasons for ten years:
a) It works
b) Because its name is animateColor, it is obvious  to use it to animate 
colours, even if you do not look into details to discover, that animate can 
do this as well, implicating the additional complexities of unfortunately
overloaded properties like stroke and fill. Examples in tutorials show, that
animateColor is used to animate colours (surprise!), by copy and paste
you get it into authors documents.

Therefore ok, in theory it would have not been necessary to introduce
it in SMIL animation and SVG 1.0, but now we have it in practice - and not 
to implement it now for SVG 1.1 documents only means to patronise, 
frustrate and unsettle authors and users - users will never know, whether 
a Gecko viewer can display an animated SVG as other viewer can, that 
have animation implemented. If they really want to be sure, they better will
use a more advanced viewer (of course not perfect either, but without 
intentional gaps).
Obviously not all authors of SVG documents are experienced
script authors as well, bored and just waiting for a chance to write yet
another simple script to work around some new nonsense of a new viewer, 
as Robert Longson seems to assume, therefore they are not very motivated to 
modify already existing content to hide the private idiosyncrasy of Gecko 
programmers, especially if they cannot run a script on the server, the
documents are for years - therefore surely animateColor will not only
disappear, just because a few people at Mozilla don't like it. 
A clean theoretical concept is ok - before there is a first recommendation
for a format and before authors created already millions of documents
fitting to the recommendations.
This is slightly different from the situation with HTML - authors and 
implementors created a lot of nonsense not fitting to the recommendations,
therefore there is a lot of nonsense around - in this case it is basically the
problem of implementors and authors to clean up, not the task for a W3C
group to write a tag soup parser recommendation (ooops - they do it for
years already without a clean concept, but with needless features, structures
and elements duplicating functionality, just because stupid authors use those 
elements and structures and some implementors implemented them in the past
without any concept ...)

>By not implementing animateColor in Gecko (and at a time when neither 
>WebKit not IE did either) the hope was to strongly discourage the use of 
>this syntax so it needn't clutter the Web platform going forward.

As far as I know, MSIE does not manage to do animation in SVG at all,
yet another  idiosyncrasy of another organisation/company to patronise, 
frustrate and unsettle authors and users.
WebKit - at least the versions I have on Linux I checked the last two years
have major problems already to display SVG documents at all (some are
searching for a plugin, others have problems with decoding ;o) 
Therefore both are of not much relevance talking about animation in SVG,
according to my tests, the probability of a correct display of an animated
SVG can be considered to be approximately 0.
For Opera and SVG tiny it is about 55% (version 10.x) or 53% (version 12.x),
for Gecko it is about 43% (version 8) or 39% (version 12) - and Gecko could
be better than Opera without a few intentional gaps.
Batik/Squiggle about 34%, adobe plugin about 37% - ironically they are
still more reliable for SVG display than Gecko, because the bugs and 
gaps they have are more attributes not so often used or behaviour in some
critical situations, one can typically avoid, similar to Opera. 
Gecko has in many cases a better and more careful implementation of several 
of these critical features, but because some essential and basic things are
blocked intentionally, it is not of much practical use infortunately, 
currently wasted time to care lovingly about all these details, if core 
features are blocked.  

>It's not about effort since implementing animateColor in Gecko is 
>probably only a couple of hours' work. As has been pointed out before, 
>not implementing features is often much harder.[2]

I think, this is irony - even in this list is was broadly discussed, that at 
least for SVG documents it is very important to be able to have the option
to use SVG fonts. At least this allows authors to use accessible text
in SVG documents. Because SVG fonts are not available in some viewers,
currently, if design matters, authors have the tendency to convert text to
arbitrary paths to get predictable text presentations, with the result, that 
the text is not readable anymore in the alternative text presentation. 
Not to implement SVG fonts finally means a sabotage of accessibility 
features of SVG - ok, most authors don't care about accessibility in 
graphics anyway, but such strategies ensure, that this will never 
change.
To call this 'altruistic' as mentioned in the article is simply zynical.
The article gives the impression of a 'power-obsessed' author living
in a delusion of evangelising the rest of the world - people have their
own brain to think - at least this is a premise of our modern societies.

>Regarding SVG 2, personally, I've rarely encountered animateColor. It 
>has never been supported in Gecko or IE so I don't imagine there is a 
>lot of content on the public Web (test suites aside) that depends on it. 

Gecko and MSIE are late candidates as interpreters of SVG (Gecko for
animated SVG, static files often worked for some years better of course).
There is a decade of authors concerning only about the adobe plugin
and for browsers maybe Opera, if animation matters.
One can imagine, that for a lot of content containing animation authors 
never cared about Gecko or MSIE, because it did/does not work anyway
in these viewers, therefore they simply assumed, when they created their
documents, that interested users will simply not use such viewers with
low capabilities for the interpretation of SVG - if gaps are too large or
too different in different viewers, there is no way to work around all gaps,
especially around those of unknown viewers at the time, the document
is created.

Olaf

Received on Friday, 31 August 2012 09:56:24 UTC