W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2013

Re: [web-anim] Web Animations minutes, 1 / 2 May 2013

From: Shane Stephens <shans@google.com>
Date: Tue, 7 May 2013 13:56:52 +1000
Message-ID: <CAGTfzwSMWHS8fAa77higXDoLRr6EJazV0J9u1iLXHrZsdm3EXA@mail.gmail.com>
To: Brian Birtles <bbirtles@mozilla.com>
Cc: Steve Block <steveblock@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>
Hi Brian,

That seems quite sensible. I particularly like the fact that it maps neatly
to CSS.

Cheers,
    -Shane


On Tue, May 7, 2013 at 1:28 PM, Brian Birtles <bbirtles@mozilla.com> wrote:

> (2013/05/07 11:49), Tab Atkins Jr. wrote:
>
>> On Mon, May 6, 2013 at 7:09 PM, Brian Birtles <bbirtles@mozilla.com>
>> wrote:
>>
>>> * Authors may expect the same syntax is available in their CSS keyframes
>>> (i.e. '50px add'). We'd need feedback from the CSS WG that they are ok
>>> with
>>> this syntax even if they don't add it immediately. This may be
>>> problematic
>>> since it requires changes to parsing. I *think* Tab said this wouldn't
>>> fly
>>> but that may have been with regards to the previous '+50px' proposal.
>>> Tab?
>>>
>>> * Reading or writing the composition mode of a value would require string
>>> parsing.
>>>
>>
>> Yeah, I'm against the change for this reason.  The property value
>> should be just a property value; intermixing in more syntax makes it
>> harder to work with for both implementors and JS-wielding authors in
>> return for a small terseness gain.
>>
>> If we want to make the compositing op optional, then this *definitely*
>> won't fly, as "add" or "replace" might very well be valid components
>> of a property value, so we can't tell whether the comp-op was omitted
>> or not without ambiguity.
>>
>
> Thanks Tab for the quick feedback.
>
> Steve, a further idea occurred to me: make the composition operation a
> property of the keyframe.
>
> The reasons for this are two:
>
> 1) It would mean you could specify the composition operation using the
> shortcut interface by treating 'composite' specially just like we do for
> 'offset'.
>
> 2) It makes mapping to CSS easier. Since we can't change what goes on the
> RHS of a style declaration in a keyframe rule I think it would be difficult
> to expose per-value composition operations there. However, per-keyframe
> composition operations should be easy:
>
>   @keyframes abc {
>     50% {
>       left: 50px;
>       animation-composite: add;
>     }
>     ...
>   }
>
> If you really wanted to have, at offset 0.7, a value for 'left' that is
> additive and a value for 'top' that is absolute, then you could achieve
> that by putting two keyframes at offset 0.7 with different composition
> operations. We already have rules for dealing with keyframes at the same
> offset.
>
> What do you think?
>
> Brian
>
>
Received on Tuesday, 7 May 2013 03:57:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:45 UTC