> On Jun 8, 2018, at 1:11 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > In your animation code example, having the offsetParent code in the setter > makes the animation *way* less efficient. There is a an extra forced reflow > for every assignment of the new value. > > I don't understand this point. Can you provide more detail? I would imagine > animations are going to cause reflows. If there is a way to do animations > without resulting in a reflow that would be great.
The point is that there is a forced reflow. There will definitely be a reflow when the browser draws the animation change, but the offsetParent code forces the browser to calculate an extra reflow during the code execution prior to setting the x value. This has two problems: 1. There is two reflows per cycle instead of one. If the animation sets both x and y values, there will be three reflows (the first two forced) instead of one. 2. The first reflow is forced to happen during javascript execution rather than when the browser decides it’s the optimum time to do so. > >> I think you are saying there is a bug in the current code, but it somehow >> involves offsetParent changing. Can you explain what causes offsetParent to >> change? > > If/when the parent (or grandparent or great-grandparent, etc.) element > position changes from static to some other value, the offsetParent will > change. > > Again, how important/prevalent is such a scenario? It’s hard to say, but one such scenario sparked this discussion. I think that avoiding lifecycle issues is pretty important.
