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

11–20 of 64 posts

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

#11

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

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

#12

Post by gibbitz »

eli wrote: post #3
untog wrote: post #2

I feel like this is a great example of the... continuing OK-ness of the web as a platform. It feels hacky, but it's considerably less hacky than using unrelated CSS properties, so it's progress and I'm happy with that.

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.

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

#13

Post by Steuard »

I hadn't heard about this before; I'm clearly out of the loop these days. With buy-in from smart people at Webkit and Mozilla, I've got to assume that it really will be an improvement over the status quo.

But, boy, it feels awkward at first sight. To my eye, it's weird to see what is essentially a low-level optimization instruction as part of CSS (which is usually all about presentation rather than implementation). Also, the article makes it clear that there are a lot of ways that people could mistakenly use this property in unhelpful ways. And I'm still not entirely clear on what they mean by "It’s not possible to remove will-change if it is declared in the style sheet": is this really a CSS property that can be turned on without scripting but never turned off without it? That makes me uncomfortable.

So why isn't this a case where we just need browsers to get smarter? In the same sense that an optimizing compiler can in most cases produce better performance than a human writing machine code by hand realistically could, can't we expect browsers to gradually get better and better at spotting these rendering optimizations? (To take an example from the article, couldn't the browser recognize that there's a transform rule for :active and automatically enable something equivalent to will-change for :hover itself?)

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

#15

Post by untog »

gren wrote: post #11

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.

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.

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

#16

Post by dmmalam »

Should'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 transforms added via javascript or onhover would be caught via live profiling.

The given use case of stopping flickering when a layer is created should be treated as a bug.

This feels hacky, and likely to be used erroneously or abused - at which point browser will be forced to smartly ignore leaving us with yet more cruft. Performance tuning is a fine art, and browser is in a better position to do it vs your average web developer.

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

#17

Post by Pxtl »

dmmalam wrote: post #16

Should'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…

I would hope that the browser would parse all CSS transforms and then use this particular attribute just for Javascript-based transforms.

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

#19

Post by troels »

dmmalam wrote: post #16

Should'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…

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.

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

#20

Post by troels »

untog wrote: post #15
gren wrote: post #11

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.

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.

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