A brief update on the status of various things related to CSS animaitons (which I described to a bunch of folks when we met in Paris last week).
There are two major areas of work related to animations: (1) getting OMT Animation turned on on all platforms with OMT compositing. It's currently turned on only on B2G; Mac also has OMT compositing turned on. (Maybe Metro and/or Android has it as well; I've forgotten.) I think the main thing we want to fix here is getting more coverage of the animation control logic in OMT animations, i.e., what is tested by test_animations.html, and fixing any bugs resulting (which should include that the CSS cascade for animations is incorrect). (2) implementing recent updates to the CSS transitions spec that I'm currently in the process of editing into the spec They're actually more connected to each other than they sound, for the following reason. The updates to the spec define behavior of starting transitions, on which there was no interoperability and also no implementations could both describe their behavior and liked that behavior enough to propose it for standardization (given that all had heard significant problems with it). The goal of these updates is to make interoperable some of the more interesting cases of starting transitions, such as cases where transitions might start on both an ancestor and a descendant at the same time. They're also closely tied to updates for how cascading of transitions and animations should work. The spec updates require two pieces of interesting code: (1) one of these pieces of code we already have for use in a codepath used only by OMT Animations. This is what we call the miniflush code, which updates style data to current animation data while leaving out-of-date (i.e., unchanged) data for all non-animation aspects. OMT Animations needs this for detecting the correct style change for a transition that is interrupted (and potentially reversed) by another style change. The new spec text will also need it more generally for describing how transitions start; this mechanism will replace the temporal distinction between "style without animations" and "style with animations" (see nsPresContext::IsProcessingAnimationStyleChange) and allow us to completely remove that distinction. (2) the other piece of code we'll need is a mechanism to implement the new cascading rules, which includes the idea that the presence of CSS animations (lower in the cascade) on an element+property disables any CSS transitions (higher in the cascade) for that element+property. (This rule resolves what would otherwise have been requirements that A > B, B > C, and C > A, in the cascade.) This in turn may be rather similar code to what's needed to fix the one major bug in OMT Animations that I know about (their cascading) and that should be turned up by getting better test coverage. This in turn makes the spec updates related to enabling OMT Animations. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: Digital signature
_______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
