
Everything You Need to Know About the CSS will-change Property - robin_reala
http://dev.opera.com/articles/css-will-change-property/
======
Steuard
I hadn't heard about this before; I'm clearly out of the loop these days. With
buy-in from smart people at Webkit and Mozilla, I've got to assume that it
really will be an improvement over the status quo.

But, boy, it feels awkward at first sight. To my eye, it's weird to see what
is essentially a low-level optimization instruction as part of CSS (which is
usually all about presentation rather than implementation). Also, the article
makes it clear that there are a _lot_ of ways that people could mistakenly use
this property in unhelpful ways. And I'm still not entirely clear on what they
mean by "It’s not possible to remove will-change if it is declared in the
style sheet": is this really a CSS property that can be turned on without
scripting but never turned off without it? That makes me uncomfortable.

So why isn't this a case where we just need browsers to get smarter? In the
same sense that an optimizing compiler can in most cases produce better
performance than a human writing machine code by hand realistically could,
can't we expect browsers to gradually get better and better at spotting these
rendering optimizations? (To take an example from the article, couldn't the
browser recognize that there's a transform rule for :active and automatically
enable something equivalent to will-change for :hover itself?)

~~~
bgirard
I made the original proposal for will-change on Mozilla' behalf. I agree with
your concerns, we've had them since 2010 and kept pushing back on proposing
this. But with HiDPI mobile and 4k desktop it's really difficult without it.

It is nearly impossible to predict changes that some page do in perfectly
reasonable ways, especially for changes triggered from Javascript. It's true
that in some cases a will-change can be inferred from the style sheet but
there are still too many changes triggered from JS events. You wont lose any
performance by not using will-change and we will continue improving how we
infer them. Once an element is declared as will-change the browser will be
able to weight the hint and the platform specific costs of various possible
optimization like layerizing the element and ignore it if it isn't suitable
for the device.

If we can't predict the change then we're left trying to be ready to change a
new element within one vsync interval to avoid any latency. This is fine if
you're dealing with a small element but large elements like a fullscreen CSS
page flip triggered from JS is going to be nearly impossible to perform
without a frame or more of latency.

In the case of HiDPI mobile you typically have 2 millions pixels (8 MB) to
deal with on a 1GB/s memory bus with a frame time of 16ms. That means that if
you touch 16 MB, or twice the size of the screen, then you have zero chance to
perform that change without introducing delays. And this is without even
considering the CPU/GPU cost require to perform the change. The situation may
also get tough on 4k desktop without a discrete GPU if you have 31MBs per
fullscreen surface on a 10GB/sec bus.

These are all theoretical throughput maximums. In practice on Android and
Firefox OS where a style change occurs on large and complex elements where
rasterization is difficult you can't use SIMD to rasterize the page at memory
bandwidth speeds, you instead are bottlenecked on rasterizing complicated
content. It's typical to see these complex change cause 100ms latency. Once
the rasterization is made then the animations can continue smoothly but you're
still left with animations skipping at the beginning.

~~~
Steuard
Thanks for the thorough reply: I appreciate it!

Was there any consideration of making this feature JS-only? From the linked
article (and some of the discussion here), it sounds like using this in an
actual stylesheet may not be easy to do well (and is often not recommended).
And from what you've said here, it's JS changes that are hardest to predict
from within the browser. So why expose this as a CSS feature rather than a JS
one?

~~~
bgirard
Using them in the CSS style sheet is perfectly reasonable. Here's how b2g/ffos
uses them carefully to make the most of low end hardware:
[http://mxr.mozilla.org/gaia/search?string=will-
change](http://mxr.mozilla.org/gaia/search?string=will-change)

Imagine you're writing something that does fullscreen page flips in a native
app vs. a web app. An example is the android homescreen vs the ffos homescreen
but I see web pages that often have a similar effect.

* In a native app you're going to have to decompose your page into texture that you will animate (your widget toolkit will likely make this easier).

* Without will-change you're going to hope that the rendering engine will infer your animations in a reasonable amount of time getting bad performance while you wait and hope that it doesn't fall off that optimization path.

* With will-change on the b2g homescreen we just have to add a one line change.

------
dmmalam
Should'nt this be something that the browser should auto-optimise with a smart
renderer?

In the example given with the element:hover and element:active, it would
trivial to parse all possible CSS transforms. Then live profiling of the page
would give data on the likelihood of particular transforms. The browser could
then optimise as necessary given hardware limitations and current resource
constraints. Even transforms added via javascript or onhover would be caught
via live profiling.

The given use case of stopping flickering when a layer is created should be
treated as a bug.

This feels hacky, and likely to be used erroneously or abused - at which point
browser will be forced to smartly ignore leaving us with yet more cruft.
Performance tuning is a fine art, and browser is in a better position to do it
vs your average web developer.

~~~
ender7
Style properties such as transforms can be changed at runtime by JavaScript
(and frequently are for things like dragging operations). There is no
practical way for the profiler to detect which styles of which elements your
JavaScript will attempt to modify.

~~~
Smudge
In such cases -- where it is JavaScript's responsibility to mutate the CSS at
runtime -- it seems like the 'will-change' property should also be
added/activated using JS.

However, most of the CSS transforms I write are pre-defined in the CSS and
activated by simply adding/removing classes using JS. This seems like
something the browser should be perfectly capable of predicting without my
help, since the JS isn't actually mutating the CSS.

~~~
ender7
This reduces to the same problem mentioned above (which is essentially the
halting problem). The browser has no way of predicting which elements you will
add or remove these classes from.

Automatic preparation would be possible for transforms/animations that are
applied in pseudo selectors such as :hover, but not in any other cases.

------
timothya
A lot of people are complaining about putting this into CSS, but I think that
people are forgetting that using null transform hacks[0] is already the status
quo for making animated elements more performant.

What this property does is lets us continue doing the same thing, but in a way
that the intent is clear ("I'm using this property to make the animation on
this element more performant" vs. "I want to add a transform that does
nothing"). Furthermore, it lets the browser decide if it wants to add any
optimization, and it can decide which sort of optimization is best.

While it would be nice if we didn't have to do this hinting at all, the fact
of the matter is that it's hard for the browser to predict what will happen on
the page in the future, and we're already having to do this (just in the
cryptic null transform way), so it's nice that the web platform is letting us
do it in a standardized way that communicates our intent clearly.

[0]: [http://aerotwist.com/blog/on-translate3d-and-layer-
creation-...](http://aerotwist.com/blog/on-translate3d-and-layer-creation-
hacks/)

------
untog
I feel like this is a great example of the... continuing OK-ness of the web as
a platform. It feels hacky, but it's considerably less hacky than using
unrelated CSS properties, so it's progress and I'm happy with that.

~~~
eli
What would be an example of a non hacky way of hinting to the browser which
properties are likely to change?

~~~
untog
In my dream scenario there's no need to do hinting at all. Most other
platforms don't require it. But I am living and working in the real world,
which has a significant legacy of web technology.

~~~
eli
The web doesn't _require_ it either--we've made it this far, after all. I bet
every platform has developers who wish they had simple tools to boost
performance.

~~~
resu_nimda
_The web doesn 't require it either--we've made it this far, after all._

That is a perfect encapsulation of the "OK-ness" he's talking about. Yeah, it
works just fine. Yeah, the web doesn't "require" a smart graphics processing
engine, it probably didn't "require" videos or the canvas or CSS transitions
at all. But "really good" modern platforms have these capabilities, and IMO
there's nothing wrong with wanting or trying to push the web to be as good a
platform as possible, and it _is_ frustrating (but understandable) that there
is so much legacy baggage "holding it back."

~~~
eli
I get that sentiment in general, but what does it have to do with a new
hinting feature? Would hinting look different without legacy baggage? Would it
not be needed? I don't see how it's possible to create an ideal browser that
is fast at everything and also memory efficient. And there are always
legitimate reasons to want to juice the most performance out of your pages.

------
gren
I'm a bit skeptical about this new property.

In this basic example,

    
    
        .element:hover {
    	will-change: transform;
        }
        .element:active {
    	transform: rotateY(180deg);
        }
    

it seems very predictable. I don't get why the browser couldn't guess (with
some heuristics) what to prepare.

Also I feel we will misuse this feature and tend to make the performance worth
than if the browser would detect what are the "will-change"s.

~~~
untog
Which works fine in a CSS-only environment. But a lot of the time these
properties are being set in JS, which is going to be very difficult to
predict.

~~~
troels
I generally try to not manipulate properties directly through javascript,
rather declaring a class for the purpose. Doesn't seem like an unreasonable
requirement for proper performance? (I mean, compared to having stuff like
`will-change`)

~~~
bryanlarsen
But you still use Javascript to apply the class to the element, right? So how
can the browser know that your Javascript might do that?

It seems to me to know that a rule along the lines of "might-add-class: foo;"
would get us back most of that separation of presentation and content.

------
ultimatedelman
While it may be functionally great, it just smells wrong to have a CSS
property that you're pretty much only supposed to set via JS that you're
_supposed to remove after you 've set it_.

------
brianzelip
Here's the W3C draft doc on the `will-change` module:
[http://dev.w3.org/csswg/css-will-change/](http://dev.w3.org/csswg/css-will-
change/)

~~~
mathias
The post links to it as well.

------
pothibo
I don't know why, but to me it feels like that will-change property should
have been associated to the HTML, not CSS.

    
    
        <section class="animatable" will-change='transition'></section>
    
        section.animatable:active {
         // someanimation
        }
    

The above makes more sense to me than the following:

    
    
        section.animatable {
          will-change: 'transition';
          &.animating {
            // Some animation
          }
        }

~~~
danabramov
I don't understand why people complain about this. It makes perfect sense:
when you change your CSS (maybe adding `opacity` to `transform: translate`),
you will notice this property and remember to update it. If it stays in your
HTML or JS, you (or whoever changes CSS later) won't keep it up-to-date and
the optimization hint will be wrong (which can hurt performance).

------
KyleLH
I haven't done much with CSS transformations, but I really like this change
and think it's a step in the right direction. So much of the web development
I've done has involved doing weird hacks to achieve the desired result, and I
think that making will-change a valid attribute will help make things more
clear. Hopefully this trent will continue.

------
jhherren
Putting performance optimization hints in my presentation code feels wrong. I
think I'd use a separate css file for will-change.

~~~
talmand
By what I'm reading you shouldn't have the property in a style sheet at all.
The author implies that every usage of the property requires resources that
are never released as long as the property is still active. The property in a
style sheet will mean that the resources are never released.

Thus, the suggestion to use the property through javascript so that it can be
applied and then removed. That just seems totally weird to me.

------
frik

      only WebKit and Firefox Nightly builds have implemented [it] 
      [...] There is also an intent to ship in Blink too.
    

(Opera is based on Chromium that uses the WebKit fork "Blink")

Offtopic: first time in years, I see the opera.com website. There was a lot of
useful information in their blog posts, when they still worked on their own
browser engine.

------
IgorPartola
The real question is when will mobile Safari, mobile Firefox, and mobile
Chrome support this?

------
wildpeaks
Small gotcha for people who have been keeping an eye on that from afar for a
while: make sure to notice the property is now called "will-change", not
"will-animate" anymore.

------
general_failure
While I understand the need for the property, it is absurd to put this in a
style sheet document :( oh well I have mostly given up on this doc/style/code
separation anyway

------
exo762
Mostly technical article about CSS opening with explanation of what CPU and
GPU are and where they are located. I'm very surprised that those two terms
even need explanation.

~~~
gpvos
Acceleration using the GPU is what will-change is all about.

Also, especially among web developers there are many people who barely know
what they are doing, so it's a good idea to comprehensively cover the context
(I know it helped me, since I'm mostly a back-end developer who does some
front-end on the side).

------
danatkinson
Is there a test suite/page for the will-change property in order to gauge
vendor compliance?

------
tempodox
I love this article. It is well written and it even has a date. Thanks :)

------
mattewilliams
TLDR; Everything I "need" to know? Doubt that

------
EGreg
Is it a commentary on the state of affairs that I was more impressed to see
this written by a Female Lebanese web developer than I was at the content?

