- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Tue, 07 May 2013 11:09:43 +0900
- To: public-fx@w3.org
- CC: Steve Block <steveblock@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
(2013/05/06 13:27), Steve Block wrote:
> Hi guys. Sorry I missed the meeting last week. A few comments ...
>
>> Also, since there's no array shortcut (unlike Option 1), we can safely allow
>> multiple properties. This makes the following possible:
>>
>> keyframeEffect.setFrames([{ left: '50px', top: '50px' }, { left: '100px',
>> top: '100px' }]);
>>
>> ...
>>
>> Note that to set a per-value composite operation you have to use the full
>> syntax.
>>
>> e.g.
>>
>> keyframeEffect.setFrames(
>> [ { values: [ { property: 'left', value: '50px', composite: 'add' } ] },
>> { values: [ { property: 'left', value: '0' } ] } ]
>> );
> How about we allow the value property to be a space-separated pair, eg
> '50px add'? I think we could then do away with Keyframe and always use
> KeyframeShortcut ...
>
> keyframeEffect.setFrames(
> [ { offset: 0.1, left: '50px add', top: '100px replace' },
> { left: '0'} ]
> );
That certainly looks simpler. A few things I'm not sure about:
* Dropping Keyframe would mean there is no interface for non-Javascript
bindings (since KeyframeShortcut is defined in a Javascript-specific
manner). I'm not sure how big a deal that is.
* 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.
* Iterating over the values of a keyframe returned by the API is
somewhat more complex: you have to iterate over the properties of the
object and be careful to ignore any 'offset' properties as opposed to
simply iterating over the 'values' array.
>> ➙ With regards to the offset property, we prefer option (b)
> I think I'd vote for (c): use 'keyframeOffset' to avoid the problem,
> but I don't feel strongly and am happy with (b).
Ok, I'll add an issue about that when I update that part of the spec.
>> ACTION: Steve to write design doc for media integration
> On it
Great, thanks Steve!
Brian
Received on Tuesday, 7 May 2013 02:10:14 UTC