Re: [cssom-view] Correction and clarification for the coordinate systems of getClientRect/getBoundingClientRect

Thanks for the feedback.

On Thu, Dec 1, 2011 at 2:25 PM, Gavin Kistner <phrogz@me.com> wrote:

> From: Robert O'Callahan <robert@ocallahan.org> on Fri, 25 Nov 2011
> 13:12:06 +1300
> > The spec needs to make clear that getClientRects() returns rectangles
> that
> > include the effect of transforms on ancestor elements. […]
> > The spec currently says to treat an SVG <foreignObject> as establishing a
> > new viewport. Gecko does this, but Opera and Webkit don't.
> (getClientRects
> > etc seems to not work inside foreignObject at all in IE9.)
>
> As described in this Webkit bug that I filed[1] the spec already makes it
> clear (I believe) that the `foreignElement` is the viewport relative to
> which the coordinates should be returned. The behavior in Gecko is per the
> spec, and Webkit and Opera are wrong (with respect to the spec).
>

Indeed. Your comment only applies to the second paragraph of my message
though, not the paragraph you're quoting here.


> However, as seen here[4] it is rather trivial for one to account for the
> transformation of the foreignElement, bringing the coordinates into global
> SVG space.
>
> Further (as shown when viewing [4] in Webkit) information is lost if the
> coordinates are provided in the global space instead of the foreignElement
> viewport's space _if the foreignElement is transformed other than
> translation_. That page has a detection and workaround for the Webkit
> behavior, transforming the points from global space back to the
> foreignElement space. When gBCR returns a page-aligned bounding box for the
> rotated and skewed foreignElement, I can no longer find the exact corners
> of the HTML element as I can with Firefox.
>

Correct again.

However, what we really need is a new API that transforms points in one
element's coordinate space to points in any other element's coordinate
space, because the problem you mention occurs with transformed HTML
elements as well as SVG, and there's no such workaround for HTML. So I
think we should create that API for your use-case, and simplify the
behavior of getBoundingClientRect and make it interoperable by doing as I
suggested.

Rob
-- 
"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
1:8-10]