Re: Dropping angle-bracket syntax for animation

Hi Doug,

On 8/8/11 3:09 PM, "Doug Schepers" <schepers@w3.org> wrote:

>Hi, Vincent-
>
>Vincent Hardy wrote (on 8/8/11 5:43 PM):
>>
>> On 8/5/11 5:23 PM, "Dean Jackson"<dino@apple.com>  wrote:
>>
>>>[trimming the cc list]
>>>
>>>On 04/08/2011, at 8:03 AM, Vincent Hardy wrote:
>>>
>>>>>  I suppose if we get agreement on that, then we can see what the
>>>>>  difference in functionality between SVG and (extended) CSS
>>>>>Animations
>>>>>  is, which will help us determine which of the three broad directions
>>>>>  Brian outlined we should head towards.
>>>>
>>>>  Since we have an action (ACTION-48 - Write up use-cases and priority
>>>>list
>>>>  of features to be added to css animations [on Dean Jackson - due
>>>>  2011-08-02]), I think that means we had agreement during the meeting
>>>>on
>>>>  that direction.
>>>
>>>That's my understanding too. I think we can start from the excellent
>>>wiki
>>>page that Brian authored. At least, that's what I planned to do.
>>
>> Thanks for confirming.
>>
>>>
>>>
>>>At the risk of reigniting the thread that had finally died down, I do
>>>not
>>>think we should drop the SMIL syntax from SVG (I believe I argued
>>>similarly months ago when it came up here). I do understand Microsoft's
>>>hesitation to implement a feature that people are not requesting. The
>>>people on this list unfortunately don't count as regular users, and CSS
>>>animations are already more widespread, so it makes sense to somewhat
>>>prioritize effort in that direction.
>>
>>> From a tool perspective, SMIL is easy to
>>>manipulate/transform/round-trip
>> than CSS animations are because there is an easy structure to
>>manipulate.
>> This said, it has some short comings that Brian's summary highlight,
>>most
>> importantly the ability to target multiple elements and
>> attributes/properties.
>
>This doesn't have to be an inherent limitation of SMIL syntax.  Back in
>2004, I proposed a way to reuse declarative animations:
>
>  http://svg-whiz.com/BAM/#section3
>
>SVG already has an architecture geared toward reuse of resources, from
>paint servers (like gradients) to graphics features (like filters,
>clipping paths, masks, and so on) to graphics themselves (like <use>,
>markers, etc.).  Reusing animations seems very natural to me.

Sorry I was not clear. What I meant to say was that there were things that
needed to be improved in SMIL if we wanted to make that the (or one of
the) solution(s). I did not mean to say it could not be improved/appended.

I actually think the things I mentioned can be addressed in SMIL without
too much effort.

Cheers,
Vincent

Received on Monday, 8 August 2011 23:50:43 UTC