What nobody tells you about "will-change"

This article was first published on (04-05-2015).

TL;DR: do not use will-change until all modern browsers are onboard with it (unless you know what you’re doing).

What is will-change?

[will-change] allows an author to inform the UA (User Agent) ahead of time of what kinds of changes they are likely to make to an element. This allows the UA to optimize how they handle the element ahead of time, performing potentially-expensive work preparing for an animation before the animation actually begins.

Unfortunately, this property does a lot more than "informing the UA"; it may also change stacking contexts or create containing blocks all by itself.

Why should you care?

Using will-change sends us back to the old IE days. Back then, we built pages and then had to check how they looked in IE 6 (or 7, or 8) before applying the necessary fixes. With will-change the pattern is the same. Anytime you use it, you need to check will-change-challenged browsers to see if things look right or not.

A simple example

This example shows 2 boxes sharing the same position (x/y).

Their markup:

<div class="box box1"></div>
<div class="box box2"></div>

Their styling:

.box {
.box1 {
.box2 {

Their rendering:

Browsers that support will-change shows the orange box on top, browsers that don’t show the green box on top.

This is related to stacking context but I could have chosen to show issues involving containing blocks as will-change messes with that as well.

For what it’s worth

I think Internet Explorer is right dragging its feet; because this property looks like a big hack — it reminds me of DX filters for which we had to give elements a layout which in turn created block-formatting contexts in IE and IE only. People were using filters not knowing about that side-effect, not knowing that many times filters were the culprit for layout discrepencies between browsers.

In short, it comes down to the cost of layer hacks versus preventing browser inconsistencies. Pick your poison.