Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything You Need to Know About the CSS will-change Property

dev.opera.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Everything You Need to Know About the CSS will-change Property

#51

Post by ender7 »

Smudge wrote: post #49
ender7 wrote: post #45

Earlier quoted context omitted.

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.

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 actu…

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.

Re: Everything You Need to Know About the CSS will-change Property

#53

Post by 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.animatable:active {
     // someanimation
    }
The above makes more sense to me than the following:

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

Re: Everything You Need to Know About the CSS will-change Property

#54

Post by 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.

Re: Everything You Need to Know About the CSS will-change Property

#55

Post by nostrademons »

dmmalam wrote: post #50
nostrademons wrote: post #48

Earlier quoted context omitted.

Live profiling wouldn't work for social reasons. When a frontend engineer demos to his executive, or a startup CEO displays a MVP to a prospective customer, they usually get a link on a cold browser, and if the transition is janky, they're like "Nope, don't want." So every frontend engineer worth his salt will continue to use the null transform hack to keep things smooth even on the initial transition. I was one of t…

But couldn't you apply the same argument to many things which cause an initial slowdown (and possibly janking), such as static assets (which won't be cached and may need DNS resolved) and JS which will be interpreted until it is jitted. Also the cpu caches will still be cold. Why is this different?

Savvy web-developers employ techniques to eliminate those sources of jank as well, eg. static assets are base-64 encoded as data: URLs and inserted via inline JS after the page layout has loaded (note: this technique may not be necessary under SPDY), and JS is late-loaded via the defer attribute with clicks captured and replayed once the JS to service them is available. This is the reason for the jsaction library that Google recently open-sourced.

The reason it's different from cold CPU caches is that all these sources of jank can cause a user or potential customer to say "Nope, I want a native app that loads instantly." You should care about sources of latency that are perceptible to the user, not ones that are invisible. We ran a number of tests and found that the time required to render a texture to GPU VRAM was user-perceptible on mobile devices.

Re: Everything You Need to Know About the CSS will-change Property

#57

Post by pcwalton »

untog wrote: post #4
eli wrote: post #3

Earlier quoted context omitted.

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

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.

iOS definitely has such a thing via Core Animation layers.

Re: Everything You Need to Know About the CSS will-change Property

#58

Post by dmmalam »

bgirard wrote: post #40
troels wrote: post #19

Earlier quoted context omitted.

My thoughts as well. This is an implementation optimisation - It seems wrong to put this kind of stuff into user space. Especially as it seems like something that should be possible to solve with a smarter rendering engine.

What will-change optimization is used under the covers is an implementation detail. Declaring what types of changes you want optimized is something best suited for the page developer. Letting the rendering engine infer and prepare for changes you want to make is something engines already do. It works but only so well.

The problem isn't technical, this is a perfectly fine solution to the question of how to remove a certain class of jank. It's adding more stuff to the already bloated web specs, having them supported forever and then the mental load of wondering what browsers will actually do given that's it's an implementation detail.

I can easily see this leading to more unintended hacks as for example WebKit may be less aggressive than say blink in weighting the hints, and so web developers will then add back the 3d transform hacks in addition to will-change.

The target audience is also web developers many of which are inexperienced and I guarantee that even given all the warnings someone will apply it blindly to *. Hence any production implementation would have to have heuristics to catch abuse; again more complexity that will have to exist forever.

While I'm willing to give the to the benefit of doubt - these guys are super smart and it's got broad support - it just feels so heavyweight to actually change the spec for what seems like a relatively niche problem that can be mostly mitigated. Also by the time it's supported everywhere (ios9?) mobiles will be 2-4x faster.

Re: Everything You Need to Know About the CSS will-change Property

#60

Post by danabramov »

pothibo wrote: post #53

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.animatable:active { // someanimation } The above makes more sense to me than the following: section.animatable { will-change: 'transition'; &.animating { // Some animation } }

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).
Post reply on HN