fwiw, I don't like that property: What nobody tells you about "will-change"

Anselm Hannemann said on March 18, 2016

It might be interesting to add that Microsoft Edge has no intent to implement the property because it does not need it.

@Thierry: Well, the same applies for using translate3d() or translateZ()—both also force browsers to render this in a different stacking context/on the GPU. I don’t see why this is a bad thing as if you’re going to use this property you have the intent to have it rendered on the GPU. Of course you need to test this but it is something a developer should do anyways when forcing an element to render differently.

Peter said on March 23, 2016

In my research, and with Paul Irish's blessing - will-change is a no brainer on position fixed elements, but should be used sparsely on other elements. I wrote about it and linked to two great articles explaining the details.

Jonathan Snook said on March 23, 2016

@Peter: If it's a no-brainer on fixed positioned elements, I have to wonder why the browser doesn't automatically try to optimize this. I think the goes to Anselm's comment that Edge won't implement it because it's not needed. I suspect will-change is something that won't ever really gain much traction. Much like we no longer really need to optimize CSS selectors. (If we ever really did.)

David Storey said on March 27, 2016

@anselm: the translate3d hack is another good example of something people use as gospel, but is just a work around for WebKit/Blink constraints (not hardware accelerating 2d transforms). It never benefitted Opera (actually broke Opera for a time as it supported 2d but not 3d transforms) , and IE/Edge don't need it to put it on the GPU.

Markus Stange said on March 27, 2016

I agree that browsers should automatically optimize position: fixed. It's really unfortunate that Chrome doesn't do it, and that as a result will-change: transform is now mostly used to work around that particular shortcoming. I believe the reason they don't optimize it is that they lose subpixel text anti-aliasing if they create a layer for the fixed element, and they interpret will-change: transform as an indication that the author doesn't require subpixel AA in that particular element.
I work on Firefox and we've spent a great amount of effort to ensure that layerization does not affect text rendering. We layerize position: fixed and background-attachment: fixed by default. Moreover, we encourage people to only use will-change to hint at changes that the browser can't know ahead of time unless it reads the site's JS code and predicts what's going to happen.

Microsoft's position is surprising to me. will-change allows more optimizations than just hardware acceleration. Firefox on Windows uses hardware acceleration for all rendering, too, but it still benefits from will-change: transform if you're going to start a transform CSS animation on an element, because once the animation starts it doesn't have to create a new buffer for the animated element - it can just annotate the existing buffer for the element with the animation properties and have the animation run on the compositor thread.

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.