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?
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.
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?