Layer Hacking #

Developers have long used translateZ to promote elements to their own layers. It's a great way to isolate elements so painting has less impact, but it doesn't come without costs.

What you really want to do instead is to say to the browser "Hey, this element is going to change, so kind of bear that in mind when you paint it."

Just as well, then, that a new property is incoming: will-change.

Say hello to will-change #

With will-change, you get to declare your intention to the browser, letting it know what you plan to change about an element: its position, dimensions or scroll position to name just three. Instead of inferring things through other styles (ohai 3D transform), the browser can explicitly make provision for whatever it is you're planning to do.

There is relatively fine-grain control for detailing what exactly will be changing, and this is important. In the same way as with transitions, where in all likelihood you don't want to use a value of all, so here you will probably want to hint very clearly what is going to change. That way the browser gets to choose the correct optimizations under the hood beyond simply "make a layer for this element".

The web needs containment #

I recently wrote a post on how the web needs to provide a couple of things to enable the next generation of web apps and this property (it was called will-animate at that point) was one of them.

I'm super excited to see that this is landing in Firefox Nightly, and of course I've starred the Chromium bug for it (you might want to, too). If you want more detail on will-change you should read the spec.

Game on.

Update (2014-02-21) #

There's been a bit of chatter on Twitter. What caught my eye was Lea Verou saying that this is something that the browser should handle automatically.

Let me say up-front that I'm entirely sympathetic to this view, and historically browser vendors have handled everything automatically very well. But here's why I don't think this scales well:

• A browser can only infer what you intend to change visually by proxy. If you make a class to apply a transition on an element's - say - width, height, top and left that's all well and good, but then the browser doesn't know for sure that you're going to change any of those things until you add the class to an element. And even then adding a transition property does not equate to actually changing a transitional property's value. This applies equally to styles toggled through JavaScript or states, e.g. hover. You can't actively preempt it because then all candidate elements should by rights be optimized for that eventuality and it would kill performance.
• Many developers require the ability to make changes imperatively via JavaScript, not declaratively through CSS. For those who don't like JavaScript animation, the use-case is when you have dynamically- or user-generated content about which you can't reason, and therefore bake into CSS, ahead of time. As such the browser has no idea JavaScipt-based changes are coming until they are executed. It would be akin to the Halting Problem for the browser to try and figure out if you're definitely going to execute a particular piece code.
• Setting up graphics to render pages is not free. We get to author our stuff in CSS, and the browser has to do all the heavy lifting to accurately present the page to a user. Creating all the structures, handling painting and compositing (all the while ensuring everything remains correct) is not free. In fact it's computationally expensive and an engineering task, for sure, but it's a constraint of operating with graphics that is not unique to the web. We can either do that work on demand and hamstring runtime performance, or we can do it ahead of time and hopefully give our users the best possible experience.

Ultimately web apps are getting more complex and complicated, a point I made when I posted about how developers can benefit from learning Computer Science. More complicated and complex applications put a burden on authors, of course, but also on browsers. The best things happen when people work with technology, and, given the above points, I'd rather we had the finer-grain control to express to browsers what we really intend to do rather than leave them guessing.