4 ms·
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 th
by troels 12y ago
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.
- bgirard 12y agoWhat 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.
- dmmalam 12y agoThe 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.