Bye Bye Layer Hacks, Hello will-change
Have you ever used the translateZ hack to create a new compositor layer? Most developers have. Now there is an incoming property that's going to change how we tell the browser what we're trying to achieve. And that, in my opinion, is almost invariably a good thing.
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:
Heyaaaaa declarative wonderment
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.
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 is adequate today:
- 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.