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

[untog]

It is an unreasonable requirement in places, though. Before now I've made things like swipable elements that track the user's touch - i.e., you touch down, pull your finger left and the box follows you. That's not possible to do in pure CSS.

[Steuard]

Is there a way to make this a JS-only interface or property, then? Heck, the article made it sound like using it directly in stylesheets would often be a bad idea anyway.