Re: [css3-transforms] Effect of CSS transforms on scrollable areas

> On Thu, May 31, 2012 at 11:31 AM, Robert O'Callahan
> <robert@ocallahan.org>wrote:
> 
> > In all major browsers, transforms normally affect the scrollable area 
> > of a scrollable container. However, during an animation or 
> > transition, Webkit treats the transform as having the value it had 
> > the last time it wasn't animated/transitioned:
> > http://people.mozilla.org/~roc/test_transform_scrollable_area.html
> > Presumably this is a performance optimization related to asynchronous
> > compositing.
> >
> > I think browsers should behave consistently here. Should we spec the
> > Webkit behavior? I guess that would be something like
> > "Transforms affect the scrollable overflow area as expected, unless
> > they're subject to a CSS animation or transition in which case they
> > affect the scrollable overflow area as if they had their values from 
> > before they were subject to an animation/transition."
> >
> 
> Actually, Webkit's behavior is more complicated than this. Event
> dispatching can (at least in some cases) cause different behavior.
> 
> I've updated the testcase. Now if you hover over the animated element
> while
> it's animating, you can observe changes to the result of
> getBoundingClientRect during the animation. Curiously, changes to the
> scrollbar state are still not reflected until the end of the animation.
> 
> I don't think we should spec the details of that mess. However, I don't
> know what to do instead.

I believe what Opera and Firefox do here is what the user would expect. Why shouldn't the scrollable area be affected by an animation? Imagine the animated object being completely outside of the scrollable container for a longer animation and you're not able to scroll to it. Wouldn't that be annoying?

Sebastian
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Received on Thursday, 31 May 2012 04:52:51 UTC