On Fri, Dec 6, 2013 at 6:09 AM, Ali Juma <ajuma@chromium.org> wrote: > On Wed, Dec 4, 2013 at 8:57 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > >> I understand what you've said, but it seems a little abstract to me. >> >> Can we just defer the introduction of "will-animate:positioning" until we >> have a more concrete use-case for it, and a stronger argument that >> alternatives such as automatic inference for that use-case are not tenable? >> We can easily add it later if we need it. >> > > I think the use case is situations like [1], where the actual animation is > on the green box, but layerizing the blue boxes (which are effectively > being moved) using the translateZ hack gives a roughly 10X speed up in > paint time for Blink (specifically, paint time goes from roughly > 1.5ms/frame to 0.15ms/frame on my Linux desktop). > This is too low-level to be a use-case. A use-case is the effect an author is trying to achieve. There may be valid alternative solutions such as changing the markup. So I think the spec needs to address the "right" thing for authors to do > here. I don't think we want the spec to require that UAs perform inference > on will-animate values (unless there's a strong argument that this can be > done efficiently in general -- I'll leave this part of the discussion to > others, since I'm not familiar enough with the complexity of layout to > usefully contribute), > When introducing the a new feature, there is a burden of proof (for a low standard of "proof" :-) ) that it can't be done automatically, not the other way around. 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 Thursday, 5 December 2013 19:18:57 UTC