Is there a test suite/page for the will-change property in order to gauge vendor compliance?
Everything You Need to Know About the CSS will-change Property
41–50 of 64 posts
Re: Everything You Need to Know About the CSS will-change Property
#42Earlier quoted context omitted.
What would be an example of a non hacky way of hinting to the browser which properties are likely to change?
How about "look ahead"? If there are transition or keyframe properties related to variations of the selector, why not do this automatically? I understand the overhead, but from the standpoint of hackiness this would be the technology working as expected.
How could a browser "automatically" know what changes I'm going to make to the DOM in a dynamic web app? Having the browser try to guess what transitions will be needed in the near future based on "related" selectors sounds way more hacky than a straightforward property that declares it.
As the article notes, for all but trivial examples, these are likely to be added via Javascript. The static CSS file with ":hover" and ":active" was jsut an example.
Re: Everything You Need to Know About the CSS will-change Property
#43Should'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 transform…
Live profiling is not the panacea you seem to think it is. The purpose of this is to allow the browser to chose the optimal layout for an element before that layout is required. In other words, before any code you might live profile is actually run. That's the point.
Re: Everything You Need to Know About the CSS will-change Property
#44While 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
Re: Everything You Need to Know About the CSS will-change Property
#45Should'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 transform…
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.
Re: Everything You Need to Know About the CSS will-change Property
#46A 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-...
Re: Everything You Need to Know About the CSS will-change Property
#47Earlier 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.
I can’t think of another platform (in the sense of programming environment) which is being optimised to be read milliseconds before execution from a networking socket, with more code being loaded on-the-fly from remote servers. In C++, you have all your code at compile-time and even in Python/Ruby/Perl/Bash etc., it would be highly unusual for the shell to anticipate the equivalent of wget -O foo ${URL} && . foo.
Given the constraints, having to add some hints doesn’t seem all that bad to me.
Re: Everything You Need to Know About the CSS will-change Property
#48Should'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 transform…
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 the Blink team's initial "reference customers" within Google for this, and we were pretty adamant that if there's any jank at all between when the user taps on a link and when the transition starts firing, it was a no-go for us. We've had launches canceled because they added to user-perceived latency instead of subtracting from it.
Re: Everything You Need to Know About the CSS will-change Property
#49Should'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 transform…
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 actually mutating the CSS.
Re: Everything You Need to Know About the CSS will-change Property
#50Should'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 transform…
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?