[css-animation~transitions][css-transforms] combining specs (was Re: [CSSWG] Minutes)

On 23/06/2011 3:46 AM, fantasai wrote:


> ChrisL: My recollection was to have that on the agenda this week
> plinss: What are the contentious issues here?
> ChrisL: For Transitions wasn't clear, did CSSWG want to keep that as a
> separate spec
> ChrisL: So whether to jointly develop that
> sylvaing: Could also argue that we need to talk about that for 2D and
> 3D Transforms
> sylvaing: They use same properties. Would be weird to move one to CR
> while other is behind
> plinss: I'm confused about your questions, Chris.
> ChrisL: Question is to have Transitions and Animations both worked on
> by the FXTF
> dbaron: Why?
> ChrisL: They apply both to SVG and to HTML
> ChrisL: Needs to be clear how that works
> dbaron: That could be said about most modules in CSS
> ChrisL: That's true, but in this case, but in this case we have animation
> model in CSS and not clear that same model is being used in SVG
> ChrisL: More potential conflicts
> ChrisL: No call for CSS Fonts to be developed in TF, since it's clear how
> they apply.
> ChrisL: And box model stuff doesn't apply to SVG
> ChrisL: So not everything needs to be jointly developed. Just certain
> things need to be.


(This is some brief feedback)


Transitions and Animations:

I believe that Transitions and Animations should be jointly develop and 
be part of the same spec. Here are some reasons.

1. The interaction with scripting.

2. One author that I am aware of (me) has used them
    together when doing animation. This has somewhat
    depended on if I have used scripting in such
    animation but I do based this opinion on minimal
    experimentation (with one exception 'A' see below).

3. Both Transitions and Animations work somewhat similar
    (with one exception 'B' see below) with events such a
    :hover :active, media queries and scripting.



2D and 3D Transforms:

I believe that 2D and 3D Transforms should be jointly develop and be 
part of the same spec. Here are some reasons.


1. What Sylvain said, (it) "would be weird to move one
    to CR while (the) other is (left) behind."

2. I see it as repetition for the spec authors to have
    to repeat particular aspects that are have the same
    principle in both specs. This includes but is not
    limited to BFC, painting order, z-index.


I do think it is a mistake to see SVG animation and CSS animation in the 
same way. I have no experience in SVG animation but I presume that if is 
is possible to swap painting order with SVG animation then this is only 
affecting the painting order. CSS animation is very different since you 
can move 3D constructs via rotation of the X and Y axises (also X axis 
with certain situations) and have two 3D constructs visually move in 
virtual 3D space in front and behind each other.


A. Some animation works differently if scripting is
    used instead of keyframes. I have not created a
    proper test case but it is apparent with this
    test [1] which I can not reproduce via keyframes.

B. Some transitions between property values happen
    instantaneously with :hover :active, media queries
    where with animations using keyframes, this is not
    the case.



[1] http://css-class.com/test/css/3/transforms/perspective-basics.htm

(With the top left example (with transform: rotateX(-45deg) 
rotateY(45deg), if you select '200' (for perspective) and 'TL' (for 
transform-origin) the box transitions to such an extent that you are 
seeing the back of the box. This can not be done with keyframes and I 
don't understand why this is the case)



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Thursday, 23 June 2011 00:28:03 UTC