W3C home > Mailing lists > Public > www-style@w3.org > November 2012

[CSSWG] Minutes TPAC Mon 2012-10-29 PM II: Animations, Transforms

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 13 Nov 2012 22:52:45 -0800
Message-ID: <50A33FBD.3070300@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

Animations
----------

   - Discussed snapshotting vs. dynamic modification of animation parameters.
   - RESOLVED: Change the animation properties to be dynamically changeable,
               details TBD.
   - RESOLVED: @keyframes can be dynamically changed
   - RESOLVED: Copy over the pseudo-element info from transition events to
               animation events.
   - RESOLVED: animation-name's length is authoritative.  Other animations
               properties are adjusted to its length.
   - RESOLVED: When you encounter duplicate animations names, last one wins.
   - RESOLVED: Make *animations* transition *all* properties. Unless otherwise
               specified, discrete properties take their starting values below
               50% timing function progress, and end values above 50% timing
               function progress.

Transforms
----------

   - RESOLVED: Accept Aryeh's proposal regarding transform parents,
               exact wording TBD.
                 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
   - Bug 15605 (w-parameter for perspective) needs review from implementers:
       https://www.w3.org/Bugs/Public/show_bug.cgi?id=15605
   - Discussed 2D interpolation methods for transitioning transforms.


====== Full minutes below ======

CSS Animations
--------------

   sylvaing: What do we do for TTA?  Something every week?
   plinss: If there are issues, our policy is to bring them up.  We just
           confirmed through prioritization that TTA is our top priorities,
           so they'll get interrupt priority.

   <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713
   sylvaing: This is about dynamic changes to animation properties or
             keyframes.
   sylvaing: Spec since the beginning requires animation property or
             keyframes to be snapshotted at the start of the animation.
   sylvaing: David and Simon agree that it should be more open to dynamic
             changes while it's running, such as changing the duration.
   sylvaing: We haven't defined in detail how that works.

   dbaron: I believe FF's model is that, at the first moment in which the
           animation-name appears in the animation list, we determine the
           start-time for the animation.
   dbaron: This is the start time at the end of the delay (I think).
   dbaron: As long as that animation name stays in the list of animations,
           that's the start time we use for the animation.
   dbaron: And we continue using that start time for all other things.
   dbaron: I think basically anything else can change.
   dbaron: So I *think* if you change the delay it has no effect, because
           we compute the "start" time as the end of the delay.
   dbaron: But I'd have to confirm.
   dbaron: Effectively, you just recompute all the parameters of the
           animation at every moment based on the current values.
   <ChrisL> all the parameters are recomputed at each tick in the animation
   dbaron: Exception is pausing.  When running->paused, record the time
           you paused.  Switch from paused->running, adjust the start time
           forward by the amount of time it was paused.
   plinss: if you change things while paused, it can put you in a different
           position?
   dbaron: Yes.  Change the animation-duration while it's paused, and it'll
           live-move you to the new position.
   dino: I don't like starting it at the end of the delay.
   dbaron: I agree - I probably should have made it record from the start
           of the delay instead, so it can take delay changes into account.

   dino: We snapshot right now, but the underlying engine supports modification.
   dino: We have all the infrastructure so we can expose it to JS.

   sylvaing: I'm okay with making the animation properties dynamic.
   sylvaing: We need some prose in the spec to be more explicit.
   sylvaing: For example, "animation-name: b, c, d;
                           animation-duration: 2s, 3s, 4s;",
             then I change to "animation-name: a, b, c, d;",
             does it restart b, c, d, or does it consider them as having
             never left the animation list?
   dbaron: b,c,d never left the list.
   sylvaing: Okay, we need that written down.
   dbaron: I wonder what Brian Birtle thinks about this, given his work.
   TabAtkins: Based on me working with him, I think this is in line with
              what he wants.

   dino: Further wrinkles.  What happens if your animation is almost done,
         you shrink its duration so it's already over?  Do you get an end
         event?
   TabAtkins: I think *not* delivering one would result in bad accidental bugs.

   dino: Okay, further answer. Animations with many iterations.  Just
         before the first iteration ends, you shrink the duration so that
         the entire animation is over.  Do you get tons of iteration
         events, one after the other?
   TabAtkins: I can be argued either way on whether to deliver iteration
              events that didn't "actually" pass.  I think it might be
              acceptable to have those inconsistent.
   dino: Okay.  So there are multiple things like this that need to be
         resolved and specified.
   sylvaing: Right - right now everything is simple, because they can't
             change.
   dino: We'll have to check every state transition - an animation that
         is done but filling (still technically running), but then has
         its duration changed so that it should still be running?
   dino: Need to work out the full state machine for all of this.
   plinss: (re: iteration events) maybe only deliver the last iteration,
           updating you to the current state.
   ChrisL: Scrubbing was one of the things that SMIL got wrong - time
           resolution was permanent, so if you scrubbed and then ran it,
           it would jump back to the time it had gotten itself to.
   dbaron: [draws a table of states on the whiteboard]
   <dbaron> columns: before / 1st iter / 2nd iter / 3rd iter / after
   <dbaron> rows: running / paused,
                  happens immediately / paused,
                  happens when unpaused
   dbaron: If we define what fires for every transition between these
           cells, is that sufficient?
   dino: Yes.
   dino: (But there may be another column or two on that graph.)

   sylvaing: Okay, so I think there's agreement to make these properties
             dynamic.
   <dbaron> And I think there's agreement that the recorded start is the
            start before the delay
   RESOLVED: Change the animation properties to be dynamically changeable,
             details TBD.
   ACTION sylvain to define what happens when animation properties are
                     changed dynamically.

   sylvaing: So, keyframes.
   sylvaing: Changing those on the fly while animation is running.
   sylvaing: The concept makes sense when the animation iterates - when
             the next interval takes the changes into account.
   sylvaing: If you have an animation that runs once, I dunno.
   dino: It sounds testable, sure, but internally it's actually kinda
         difficult - animation may be running on another thread, and
         there's a disconnect in processing times.
   TabAtkins: Conceptually, I don't see anything wrong with changing them
              mid-animation.
   glazou: I have a use-case.  A long-running webapp animation may have a
           large duration. If you change it, you don't want to wait for
           an entire iteration to go by.
   sylvaing: Are there any animation functions in @keyframes?
   TabAtkins: Only the timing function.
   glazou: I think that dynamic changes of animations will actually be a
           reasonably common case (editing is hard right now, but CSSOM
           will improve)
   sylvaing: So what about changes of keyframes during an iteration event,
             intending for the next iteration to use new values?
   TabAtkins: There may by a delay if you need to deliver the changes to a
              separate animation thread, but otherwise it should work fine.
   TabAtkins: I think we're doing work on our end that should make it
              automatically do a smooth transition over to the new values
              when it discovers that it's overshot and needs to change tracks.
   dino: But then we need to specify that.
   TabAtkins: We'll have non-interop a bit anyway, because of timing issues
              based on whether you do animation on a separate thread or not.
              I think we can leave it alone and spec after things have shaken
              out.
   RESOLVED: @keyframes can be dynamically changed
   <glazou> yay

   <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15846
   sylvaing: Next. Transition events report what pseudo-element of the
             element the transition is running against.
   sylvaing: We don't have it for animation events at the moment.
   dbaron: We should just copy it.
   RESOLVED: Copy over the pseudo-element info from transition events to
             animation events.
   * ChrisL imagines animating font-size on :first-line
   * SimonSapin is glad not to implement that

   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Nov/0020.html
   sylvaing: What happens when you have duplicate animation names in the
             animation-name property.
   sylvaing: Seems that last one wins.
   dbaron: I think we resolved that and I edited it already.

   dbaron: A similar thing is which animation property's length is the
           winner.  I propose that animation-name define the number of
           animations, and every other property gets padded/clipped to
           that length.
   dbaron: This matches what backgrounds/etc do.
   dbaron: I may have already edited this into the draft.
   RESOLVED: animation-name's length is authoritative.  Other animations
             properties are adjusted to its length.
   ACTION Sylvain to make sure that animation-name's length is definitive,
                     and edit it to be so otherwise.
   RESOLVED: When you encounter duplicate animations names, last one wins.

   <oyvind> that last resolution seems unclear
   <glazou> oyvind: explain ?
   <oyvind> current draft says that the last wins *at any particular point
            in time, for a particular property*
   <dbaron> http://dev.w3.org/csswg/css3-animations/#list-matching already
            has the first of those two resolutions edited in, actually
   <TabAtkins> oyvind, when assembling the set of property values that
               define the animation, the index of the last occurrence of
               the animation name is what is used.
   <dbaron> oyvind, oh, it's about what happens if the same animation-name
            is specified twice in the list
   <dbaron> oyvind, which duration, delay, timing-function, etc., does it use
   <glazou> oyvind: 'animation-name: foo foo"
   <dbaron> oyvind, the answer is that it's the last occurrence of that
            animation-name in the list
   <oyvind> dbaron, ok, I misunderstood somewhat

   <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14599
   <sylvaing> http://jsfiddle.net/leaverou/jwHva/2/
   sylvaing: In this example, if you remove border-style:solid, the animation
             stops working.
   <sylvaing> http://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html
   dbaron: I think I wrote a response for why this is crazy.
   TabAtkins: The reason why it's problematic is that border-style is not
              animatable.  Thus, since the default (pre-animation) value
              of border-style is none, the animation doesn't change it to
              solid.  And, since it's "none", the border-width computes to
              zero, and so no animation happens at all.
   leaverou: Authors find this super-confusing in my experience.

   dbaron: There's an even more subtle issue here.
   dbaron: Related to the processing model.
   dbaron: When animating from A to B, there's an idea that it overrides
           some of the properties, and only those.
   dbaron: So this animation actually overrides 13 properties. border-image,
           border-top-style, border-top-color, etc.
   dbaron: For each keyframe, you get a computed value from it, and then
           you animate the computed values between.
   dbaron: However, in some cases, for border-width, the computed value
           depends on border-style.
   dbaron: Which value are you using? The base value, or the value that
           the keyframe is overriding?

   dbaron: And this gets more confusing.
   dbaron: Say you have a 50% keyframe here with only a "border-width: 10px;"
           property.
   dbaron: What border-style is this resolved against?
   dbaron: Gecko currently resolves it against the base value.
   dbaron: (It also does this for the other keyframes.)
   dbaron: The spec's processing model just doesn't really care about the
           fact that computed values can depend on other computed values.
   dbaron: I think it should, but I doubt any browser really does it.
   dbaron: I think a testcase that covers only the issue I was talking about
           would be one that animates font-size and some length in ems.

   ChrisL: In SMIL anything can be animated.  It just switches halfway through.
   dbaron: halfway through the timing function (which makes step-start and
           step-end magically work)
   TabAtkins: Worst case, can we separate this out, so that non-animatable
              properties with constant value are still paid attention to
              and "animate".
   ChrisL: That sounds like doing 3/4 of the work and just stopping.
   glazou: We could also just say non-animatable properties freeze at their
           first keyframe value.

   dbaron: Regarding font-size and length in ems, make sure you test both
           when the two properties are in the same keyframe, and when they're
           not.
   <dbaron> ... and in different @keyframes on different elements.
   TabAtkins: So 3 cases of increasing complexity.

   <sylvaing> cool border transitions:
              http://thecodeplayer.com/walkthrough/simple-yet-amazing-css3-border-transition-effects

   glazou: So what about my "freeze at frame 0" idea?
   dbaron: I think that has a higher chance of web compat problems.
   dbaron: The problem with all of these is potential web compat.
   glazou: Can we seriously not do better than just making this work?
   <ChrisL> I'm arguing for fixing it now by defining animation of
            enumerated values
   ChrisL: Are you saying that people are relying on the behavior in that fiddle?
   dbaron: I don't know.
   dbaron: Webdevs often try things, find they don't work, and then don't
           remove them.
   ChrisL: So if we fix it, something might suddenly start working and
           break a page.
   dbaron: I suspect we could get away with making this change in animations.
   dbaron: I suspect not in transitions, because it defaults to "all".
   dbaron: I suspect that if we fix it, we're adding a minimum of 4 months
           to the spec.
   ChrisL: Yes, but that avoids 3+ years of us explaining why it's stupid.
   dino: I don't think many authors have hit this particular case.  Or they
         do and they screw around until it works.
   leaverou: I think this change's impact will be smaller than gradient
             angles flipping.  ^_^

   dino: I'd like to get some compat data on this first.
   TabAtkins: Can we put a time limit on this?
   dbaron: Do you know why Gecko doesn't allow you to style the color of
           the radio button dot?
   dbaron: Because hotmail.com styled all their radio buttons with
           "background-color: green; color: green;", presumably on the
           theory that only *one* of them would work.
   TabAtkins: Okay, so suggestion is this:  Allow all properties (except
              maybe animation properties) to be animatable.  Discrete
              properties swap their values halfway through the timing
              function (to match SMIL).
   <dbaron> (doesn't apply to transitions)
   dino: I don't object to putting this in the spec, but would then like
         time to investigate compat.
   * Bert thinks that leaves a small pb to decide at 50%:
               0% {border: 10px solid}
               50% {border-width: 5px}
             100% {border: 0px none}
          is the border already none at 50% or only at 50.00001% ?
   <dbaron> depending on whether timing function output is greater or
            less than 0.5
   leaverou: If you have cubic-bezier with out-of-range params, you can
             have it hit 50% multiple times.  What happens there?
   <dbaron> so it might swap more than once
   <dbaron> (though we don't think so)
   dbaron: It takes the first/last value depending on whether progress
           is currently above/below 50%, so it'll flip multiple times.
   <leaverou> example of timing function that reaches 50% multiple times:
              http://cubic-bezier.com/#0,1.8,1,-0.79
   RESOLVED: Make *animations* transition *all* properties. Unless otherwise
             specified, properties take their starting values below 50%
             timing function progress, and end values above 50% timing
             function progress.
   <dbaron> cubic-bezier(0.25, 3, 0.75, -2)
   <dbaron> (you can cross 50% more than once)

   <Zakim> Bert, you wanted to ask if we can now remove the Animatable
           line from table.propdef.
   dbaron: No, really it's about how to interpolate the property.
   <dbaron> we could maybe rename Animatable: to Interpolation:

   dbaron: Do we at least have an issue filed on the processing model
           stuff we're discussing?
   dbaron: How you compute the base values for the properties that we were
           discussing a moment ago?
   ACTION tab to test the processing model of animations where computed
                 values of animated properties depend on each other.

Transforms
----------

Scribe: fantasai
   <krit> 
https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
   <smfr> http://jsfiddle.net/fNxAQ/1/
   <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328
   smfr: We think that the only real substantive issue in the transforms
         spec is this bug
   smfr: which talks about the containing block terminology used in 3D
         transforms rendering part of the spec
   <smfr> http://jsfiddle.net/fNxAQ/3/
   smfr: and to illustrate that, jsfiddle that Ted just linked to,
         hopefully someone can project
   smfr: The issue here is related to 3D rendering contexts and
   smfr: how 3D transforms propagate across containing blocks,
   smfr: Is that jsfiddle on the screen?
   [yes]
   [fiddling with example]
   smfr: 2 containers here,
   smfr: border box with perspective
   smfr: Top intermediate div  with no style
   smfr: ... with rotate-y
   smfr: issue here is whether perspective on grandparent affects rendering
         of that transform
   smfr: i.e. whether the intermediate box flattens it
   smfr: i.e. whether the intermediate and the box are members of the
         same 3D context
   smfr: I believe in FF, intermediate box causes flattening to occur,
         b/c it's the containing block of the blue box
   smfr: in Webkit it doesn't
   smfr: FF more close to wording in current spec

   smfr: Transforms looks at containing block hierarchy
   smfr: in bottom example, container, then inside an image, and image
         has a block sibling
   smfr: image gets an anonymous block container
   smfr: in this case the containing block for the image is anonymous
   smfr: question here is whether that anon box prevents transform
   smfr: [... gecko]
   <krit> http://jsfiddle.net/fNxAQ/6/
   dbaron: Gecko doesn't actually create an anonymous box here
   [fantasai explains what gecko does for mixed block-and-inline content,
    and why it doesn't make that box]
   smfr: implementation doesn't matter much; but if you adhere to strict
         wording of spec, there's an anon box that's your containing block

   smfr: Webkit's implementation is falling out of some other things going on
   smfr: Detail is something like we're looking at ancestors that are
         transformed or that are positioned or that have other properties
         that create stacking contexts
   smfr: So it's not conforming to the spec, and not always predictable
   dbaron: You say you're looking for ancestors starting ...
   dbaron: starting from thing that has a 3D transform?
   smfr: Any of those things between that and the transform will cause
         flattening to occur
   smfr: so webkit won't flatten otherwise

   <smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4
   smfr: wording in spec is very tight, maybe need something in between
   smfr: Aryeh suggests defining a new type of container called transform
         parent, and then make a list of things that make something a
         transform parent
   smfr: [quotes]
   smfr: [...]
   smfr: Aryeh's suggestion.. A is closer to what authors expect, and
         B doesn't have anon containing block problem
   <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c0
   <dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16328#c4

   smfr: Just got browser shots from IE10
   smfr: Which is similar to FF behavior
   smfr: Opera shot didn't show any support for 3D transforms
   smfr: Question here is whether we try to cook up some wording similar
         to Aryeh's suggestion
   smfr: or what
   smfr: input from other implementers?
   [...]
   sylvaing: Our rendering in this case is may not be really related
   krit: Do we want to follow Webkit, or different approach?

   fantasai: Seems to me that webkit's behavior is closer to what authors
             want; wouldn't want everything to flatten all the time, right?
   dbaron: Authoring perspective, want it never to flatten, but problem
           is it's too expensive?
   smfr: Want it to flatten in certain cases
   dbaron: You'd want the default to be the other way around?
   smfr: when we were designing this transform property, did think it
         would be good to not flatten always, but didn't do that b/c
         thought it would be fairly significant change to CSS
   smfr: Web pages are typically flat, and having them not-flat would be
         strange
   smfr: That's why default style is to be flat
   smfr: Time authors use preserve3D is when they build up 3D hierarchies
         of objects they want to sit in the same perspective
   smfr: It's fairly unusual for someone to put perspective on document
         and expect the whole thing to be 3D
   smfr: Generally have islands of 3D
   smfr: So we expect authors to sprinkle around preserve3D between things
         with perspective and objects they want to show in 3D
   smfr: not too bad, usually only 1-3 levels of elements in between

   dbaron: Substantive implementation differences. If we pick a different
           rule, would it be more burdensome?
   smfr: I think a rule like Aryeh's it'd be a little work for us, but
         not too bad. Have to flatten a little more than we're doing
   smfr: The obvious flaw with using containing block is in the case where
         you have an anon containing block, there's no way author can
         style that to make it preserve3D
   dbaron: Other reason bz pointed out is that containing block is not an
           element, it's a rectangle
   smfr: didn't Anton fix some things wrt that?
   antonp: yep, but nothing published yet
   antonp: but could work around that, if that's what you want
   smfr: If no one has any more input, then action is on me to write up
         wording for spec ~ Aryeh's comment #4
   <dbaron> sounds good to me
   krit: Can we resolve on some kind of wording ?
   plinss: Do we have wording?
   dbaron: Simon was proposing to take an action to propose wording
   ACTION smfr: propose wording for 3D perpsective containing block thing
   RESOLVED: Accept Aryeh's proposal, exact wording TBD

   <krit> 
https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&product=CSS&component=Transforms&resolution=---&list_id=1271
   krit: Some other items on issues list
   krit: Did some wording on it, but needs review from implementers
   krit: Not necessarily an issue, but should be reviewed
   ACTION sylvain: look into bug 15605
   dbaron: I trust Aryeh on this
   dean: We're happy with this

   <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17017
   krit: Next issue is concern of dbaron's
   krit: we have some interpolation code, how you can interpolate between
         3D matrices
   krit: But don't say how to interpolate between 2D and 2D matrices
   krit: So, I looked a bit at source code from FF and Webkit
   krit: FF has ... like 2D interpolation, modified to work on 2D
   krit: Webkit operates on 3D all the time
   krit: We have 4x4 matrix
   krit: we transform everything to 3D first, then take 2D values from
         the resulting matrix
   dbaron: I had testcases; possible it's been fixed but;
   dbaorn: If you do 2D transform in webkit between certain positions,
           it'll do something like this [handwave] and then snap to that
           position
   <ChrisL> do you assume the three unused values are 0 0 1?
   <ChrisL> because they might not be if you had scaling in there,
   dbaron: If you transition between matrices where sign of determinant
           is different
   dbaron: The matrix algorithm will produce interpolation that will spin
           you around x or y axis, and webkit will then throw out the 3D
           part of that
   <dbaron> http://dbaron.org/css/test/2010/transition-negative-determinant
   dbaron: Chrome seems to get these right now, but it didn't used to
   <smfr> chrome and safari do different things with the bottom row
   dbaron: That said, bottom row is looking like it's doing something 3D
           to me
   dbaron: so I think Chromium is interpolating the bottom in 3D
   dbaron: Firefox is interpolating in 2D
   <smfr> in safari, middle row 2nd from right is weird
   [random discussion of these cases and what's happening in various
    browsers/versions]

   ChrisL: Promoting to 3D and then interpolating doesn't necessarily
           give you the wrong answer, just depends how you do it
   krit: Do we want to define an algorithm for this?
   krit: It seems to be hard in webkit atm
   dbaron: Seems we should say what happens, how you interpolate between
           these things
   krit: Are implementations willing to change?
   dean: FF must have extra code to handle this
   dbaron: We have separate paths for 2D vs 3D
   dean: What's 3D vs 2D?
   dbaron: The test for 2D is based on the components of the matrix
   dbaron: one other reason we want this code is... I don't think we support
           3D transforms in all cases... though maybe we do
   [...]
   dean: It could be that the 3D interpolation is ok for enough cases
   dean: and we're just seeing some bugs in webkit's implementation
   dean: would still like to know why chose to customize algorithm for 2D
   dbaron: he's in New Zealand...
   dean: I don't trust anyone from New Zealand

   dean: I accept the resolution.
   krit: Even if we have interpolation in 3D space, still need to specify
         how get 2D components for e.g. getComputedStyle
   krit: It's the main thing left
   krit: I'd like to have just one algorithm in the spec, not multiple
         algorithms. 3D is already complex enough
   plinss: Anyone take an action to do research and get back?
   krit: What do you expect as the result?
   dbaron: Are we interoperable on 3D interpolation, in general?
   <smfr> sounds like we need some test cases!
   krit: Webkit is mostly following the algorithm in the spec
   dean: Made an effort to match the algorithm from you, although we may
         have bugs
   [more discussion of browser versions]
   krit: They look different. That might be a bug

   dbaron: Looking at our code, looks like we're still doing quaternian
           thing for both 2D and 3D, just do a different decomposition
   dean: Is the decomposition for speed or aesthetics?
   dbaron: Think it's for aesthetics
   dbaron: we use a decomposition that never generates a perspective
   dbaron: sometimes the 3D comp will generate a negative 1 perspective
           instead of 1
   dbaron: that's what leads to weird zoom-in-zoom-out behavior
   ChrisL: That's not perspective, that's scale, right?
   dbaron: Or maybe it's [this other] component that's affected
   ChrisL: Looks like it's the scale factor
   dean: I think if you get anything other than 1 in 4,4, you're done
   dbaron: It's something where you can take a 2D matrix, run 3D decomp,
           and get a -1 instead of a 1 in some parts
   krit: Webkit always assumes 3D, even if given 2D
   krit: You could use algorithm from 3D transforms and do some weird
         stuff like setting 1 for perspective

   krit: at the moment it's undefined
   Options are
       1. Define 2D decompositing algorithm
       2. Leave it undefined
       3. Use 3D decomposing algorithm everywhere
   krit: Could also defer this issue to next level
   dean: Dunno. It is an interop issue.
   dean: If you query getComputedStyle halfway through a transition, would
         get different values on different browsers
   dbaron: Other thing is that algorithm could be tweaked so that the 3D
           algorithm will always work
   dbaron: I'd like to at least email Matt Woodrow and Tim and ask them
           why we're doing what we're doing
   ACTION dbaron: investigate motivations for gecko approach to 2D matrix
                  interpolation
   11:58  * RRSAgent records action 4

Meeting closed.

<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1871
<TabAtkins> dbaron ^^^
Received on Wednesday, 14 November 2012 06:53:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT