Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On 5/19/11 12:29 AM, Andrew Dupont wrote:
> I'm answering this first because it's most important: knowing _exactly where the element is on the screen_

I assume you mean "in the viewport" or "relative to the viewport"?  The 
actual physical screen position doesn't seem relevant to the use cases 
you cite.

>But you could argue the same thing about getBoundingClientRect() itself

Actually, you couldn't; in browsers that do sub-pixel layout 
getBoundingClientRect() returns information that is simply not available 
via any APIS that existed before that.

But I agree that forcing people (even just library authors) to do 
transform computations by hand is not where we want to be.

> The other major issue is whether there will be an API that reaches through both CSS transforms and CSS transitions/animations. Right now, WebKit's version of getBoundingClientRect() does this; I can (e.g.) animate `scale(2.0) translate(0, 0)` to `scale(2.0) translate(-500px, 0)`, call getBoundingClientRect() every 0.1s during the animation, and watch the value change in accordance with what I'm seeing on the screen.

CSS transitions/animations are just style.  Any API that takes 
transforms into account at all had better take them into account. 
Certainly getBoundingClientRect takes them into account in Gecko, like 
any other styles.

> Border box, if we're being most consistent with existing APIs.

Fwiw, I think jquery exposes APIs for both the border box and the 
content box right now.  I agree that getBoundingClientRect() exposes the 
border box; this actually causes pain when people actually want to 
measure how much space the kids of an element have.

-Boris

Received on Thursday, 19 May 2011 05:03:47 UTC