Re: Proposal: will-animate property

On Dec 3, 2013, at 2:47 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Tue, Dec 3, 2013 at 12:21 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Dec 2, 2013, at 9:33 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> 
> > That's true for a property like 'buffered-rendering' that appears to force a particular implementation. But 'will-animate' is the right level of abstraction to give the implementation the information it needs to make the right decision. If the decision is "we don't need to do anything special to handle animation of this property", that's fine.
> 
> I think you are missing the important part of the proposal (with your addition). It is not a hint anymore. It changes behavior and limits the implementation on the decision if it follows the hint or doesn’t.
> 
> Creating a stacking context can't be a problem for any implementation: many properties already do it, and we keep adding more to that list. That is the only correctness-affecting behavior change.

So far we elaborated when a property needs to create a stacking context and when it doesn’t. To say one property more that creates a stacking context or less doesn’t matter seems shortsighted.

> 
> Without the creation of a stacking context, I would be a bit less concerned, even though I still fear that it can not be used in an interoperable way. Implementations *are* different. The proposal would require a certain way of implementation so that all user agents can benefit of it in the same way which is simply not the case today.
> 
> Are you saying that "will-animate:transform" is somehow worse than using "transform:translateZ(1px)" to indicate the same thing, i.e. what people do today?

>From the functionality it is not worse. From the signal to authors it might be. See comments at the end.

> 
> This can be seen on noticeable differences on scrolling, one reason why this property was suggested in the first place. You will end up with “Works best on Chrome” or “works best on iPad” on web sites very quickly depending where the property is more attractive for authors which again probably depends on market share (or where the authors makes most money). I am pretty opposed to a property that deliberately causes a wider diversity. This is not the task of CSS.
> 
> Currently authors are taught specific hacks to trigger browser heuristics to get the performance characteristics they need. I think will-animate will improve that situation, and I fail to see how it could hurt.
> 
> It might help if you presented more specific scenarios that you're concerned about.

I already did. To summarize:

- We already have different implementations of the compositor in browsers
- Scrolling (one gainer) is implemented differently in browsers
- teaching authors browser specifics that they rely on later -> improvements on compositor and heuristics get harder
- performance benefits are different depending on the platform may lead to things like * { will-animate: all; }
- buffered rendering for animated transforms and filters might not be true for all time (see NVPath)

My personal guess is that implementations will work on the last point more in the next 2-3 years. Creating a stacking context would harm more at that time.

Greetings,
Dirk

> 
> Rob
> -- 
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w

Received on Tuesday, 3 December 2013 08:48:32 UTC