Re: SVG 2 FPWD published (wallclock, animatecolor)

Robert Longson:

>19.2.8
>Is wallclock timing staying?

At least in Batik/Squiggle it works for the begin attribute.
And if you look around for clocks, they are quite popular
(one should assume, that everyone with a computer has enough
clocks, but still authors provide a lot of clocks).
Currently, because a lot of viewers have an implementation gap here, 
most of them either depend on server sided scripts
to get a proper time or depend on ecma-script (and do therefore
not work, if script interpretation is not available) - or both (AJAX).
A declarative method to start a clock therefore is a good and
important feature - more viewers should interprete this correctly
and we will see much more declarative SVG clocks in static
documents around, that really work in an efficient way ... 

Maybe it would be useful to add some informative text with
some ideas, how to get the wallclock time for implementors,
obviously they need some help to get it, to have some progress
here - because Batik/Squiggle does the job, it should be possible
to get some information, how to implement this
(implementations could use the local clock of the computer of the
user of it there is a network connection even better they can use
information from an ntp server, if the user allows this.
Especially presice time information form an ntp server can really
provide more information than usual clocks currently do - for example
a viewer could synchronise with an ntp-server once a day in case,
it gets documents with wallclock values - and the information of such
a wallclock will be often more precise than what people have on their
one computer - and suddenly such clocks provided by authors really get
useful).

>19.2.15
>animateColor was deprecated in SVG 1.1 shouldn't it be removed from SVG 2?

This depreciation was added in the second edition of SVG 1.1.
I think anyway, a second edition is the wrong place to depreciate
something. And one has to take into account, that animateColor works
in viewers with serious efforts to interprete animation in SVG properly, 
why to remove something, that works without problems for about 10 years?
There is a requirement for SVG2 to be backward compatible.

If one follows the discussion on Mozilla/Firefox, why this element
is still ignored, one can see that such depreciation makes people
insecure and lead to wrong decisions, with the result, that such
programs are not interoperable and complicate the work of authors.
They have to note, that such programs are not advanced enough
to interprete their content and have to suggest interested users to use
more advanced programs, this is annoying and a waste of time both for 
authors and users and only a result of these absurd depreciation 
discussions about features, that already work pretty good in many viewers.

The only problem that appears with animateColor is some complication,
I think introduced in SVG tiny 1.2 to allow no color representing values 
like 'none'. Obviously this complicates implementations of animateColor
to a similar complexity as color animation with the element animate -
finally not very clever to do that, because many implementations 
currently do not manage to interprete correctly mixed values lists with 
colors and none colors for animate anyway. 


Olaf

Received on Thursday, 30 August 2012 10:05:04 UTC