On Wed, Dec 4, 2013 at 8:57 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > I understand what you've said, but it seems a little abstract to me. > > Can we just defer the introduction of "will-animate:positioning" until we > have a more concrete use-case for it, and a stronger argument that > alternatives such as automatic inference for that use-case are not tenable? > We can easily add it later if we need it. > I think the use case is situations like [1], where the actual animation is on the green box, but layerizing the blue boxes (which are effectively being moved) using the translateZ hack gives a roughly 10X speed up in paint time for Blink (specifically, paint time goes from roughly 1.5ms/frame to 0.15ms/frame on my Linux desktop). Authors will of course want to take advantage of this sort of speed up, and we should give them a way to do so without resorting to hacks like translateZ and without having to hackily apply a "will-animate: top" (say) to the blue boxes, since we're trying to discourage hacks and encourage authors to use will-animate honestly. So I think the spec needs to address the "right" thing for authors to do here. I don't think we want the spec to require that UAs perform inference on will-animate values (unless there's a strong argument that this can be done efficiently in general -- I'll leave this part of the discussion to others, since I'm not familiar enough with the complexity of layout to usefully contribute), so perhaps a way forward is to split off the notion of inferred changes from actual changes, into something like "will-effectively-animate" with allowed values "positioning" and "size". Since "will-effectively-animate" would be a pure hint, UAs that figure out how to do inference efficiently could ignore it altogether without any ill effects, and it could easily be killed-off in the future if we wanted to. [1] http://jsfiddle.net/ZQx45/14/Received on Thursday, 5 December 2013 17:10:11 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC