[core] Remove opinionated will-change usage

[joshwooding]

• I have followed (at least) the PR section of the contributing guide.

Closes #10831

Affects the following components:

• Slider
• ToggleButton
• CircularProgress
• Fade
• LinearProgress
• TabIndicator
• Zoom

I'm not sure what component prefix should be added to the title but, I didn't list all the components to improve the readability

[eps1lon]

Important: will-change is intended to be used as a last resort, in order to try to deal with existing performance problems. It should not be used to anticipate performance problems.
-- will-change | MDN

It's probably safe to say that this property should only be used at the application level and not component level i.e. application authors should add this not library authors.

Maybe add a recommendation to the docs if users experience performance issues?

[eps1lon]

Argos picked up some very small diffs on the shadow of the speed dial it seems. Visual regressions might be due to

Be aware, that will-change may actually influence the visual appearance of elements, when used with property values, that create a stacking context (e.g. will-change: opacity), as the stacking context is created up front.
-- will-change | MDN

[joshwooding]

Maybe add a recommendation to the docs if users experience performance issues?

I mentioned this to @oliviertassinari, maybe there should be an Optimization section under Guides?

[oliviertassinari]

I have resolved the conflict. The will change thing is such a broad topic that I'm unsure it's our role to evangelize it. I try to think of a place where people could find it. Maybe if we had a performance guide documentation page?

[eps1lon]

So how do we determine when to use it? "Opinionated" is to vague IMO. I thought we simply remove every usage.

[oliviertassinari]

So far, we use it for all the continuously running animations. Does it sound correct?

[eps1lon]

What does "continuously running" entail? will-change got removed in Slider too which would fit that description.

[oliviertassinari]

Maybe we should remove it everywhere then?

[eps1lon]

I think so too after reading that documentation page. It's a "last resort" and should not be applied prematurely. I would hope that a single component hits 60fps anyway which is why application authors need to benchmark their ui not library authors a single component WRT to will-change.

[joshwooding]

Slider only has transformations when active, The indeterminate progress components have animations that continuously loop

[Pajn]

Running animations are promoted to a layer automatically and thus does not need will-change. Will-change is, as it's name implies for things that are not currently changing but is about to so that the animation doesn't have to start with a costly layer promotion.

[oliviertassinari]

@joshwooding What do you think of removing all the will-change occurrences?

For the slider, we could apply a will-change ahead of time, based on the hover state. But it's quite an advanced logic. Does it worth the bundle size overhead?

[joshwooding]

@oliviertassinari I'm fine with that, users can add them back in if necessary, I was thinking the same for the slider but it's hard to tell if it will make a difference without a benchmark

update