Position:fixed in the Translate element

Recently wrote the layout of wonderful flowers encountered a wonderful problem, want to give a parent element plus translate3d to achieve GPU acceleration, found that after adding tranlate3d, fixed positioning of the self-element is not relative to viewport, and the other is relative to the translate3d of the parent element.

Check the definition of fixed, according to the standard positioning is indeed relative to viewport
-https://www.w3.org/TR/css-position-3/#fixed-pos

Fixed positioning is similar to absolute positioning. The only difference is a and a fixed positioned box, the containing block is established by the viewport.

Then checked the fixed and translate, found the answer
-TRANSFOMR will have a cascading context and a containing block (containing block), which will become the containing block of the fixed positioned child element.
-Https://www.w3.org/TR/css-transforms-1/#transform-rendering

For elements whose layout are governed by the CSS box model, any value other than none for the transform results in the CRE Ation of both a stacking context and a containing block. The object acts as a containing block for the fixed positioned descendants.
-and then a issue.

Is this effect on position:fixed necessary? If So, need to go into
More detail here for why fixed positioned objects should does this,
i.e., that's it ' s much harder to implement otherwise. See Bug 16328.

The final curve to the national salvation, with Will-change to achieve the new layer acceleration, but the use of Will-change also pay attention to

Using 3D transform to turn on hardware acceleration, this method is actually a hack means, each hack behind have a variety of thrilling pits. Will-change is a more consistent approach to human logic. This property is intended to tell the browser what the element will change, so that the browser can prepare for optimization in advance, just like the run-up before takeoff.

The document suggestion is to control the Will-change through JS, if the Will-change is resident on an element, such as a line in a CSS file. ele {will-change:transform;}, then the browser will always be "alert", that is to say, The browser will always allocate resources to this element. Therefore, it is better to dynamically control this property, to ensure that the browser resources are not wasted, especially in the CPU GPU processing power and memory tight mobile devices. When the animation is finished, change the Will-change property value back to auto and release the resource.

As mentioned above, when the animation ends, the value of the Will-change is updated to auto, which can be used to pinch the time by JS. But now, to throw a question that should have been asked a long time ago: To change at the end, to be changed at the beginning, when to add this attribute. Can not be animated half of the execution, only add this property. To give the browser enough time to respond before the animation occurs. The author of this article mentions a scenario where if an element is animated when it hover, it is necessary to add will-change to the element when its parent element is hover;

PS, about startup GPU acceleration can be poked http://blog.csdn.net/u010552788/article/details/52186108, although written rarely rubbed, you can continue to poke references 233333