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

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).


> At least for the
> purposes of getClientRects/getBoundingClientRect, I think the spec should
> change to have <foreignObject> not establish a viewport. Geometry changes
> induced by SVG should be included in the transforms accounted for in my
> previous paragraph.


I understand the convenience of this. When the foreignElement's viewport is aligned with the enclosing viewport, having gBCR behave like Webkit does currently makes it easy to align elements from the outer viewport with those on the inner viewport. My first attempt[2] at locating HTML-in-SVG only worked in Webkit because I was assuming (and relying on) the current/broken behavior. I even filed an erroneous bug against Gecko for it.[3]

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.

In short, I oppose this proposal. If implemented, information and capabilities currently available to the user (via the spec and Gecko's behavior) would be removed.

I would endorse a proposal that provided an alternate method or flag that performed as Webkit does currently. For the more common unrotated/unskewed case, it would be more convenient to use a new method than to:
* Find the foreignElement ancestor.
* Get the transform between this and the owning viewport element.
* Transform each of the four points.
* Repeat as necessary until you get to the root viewport. (Usually only once, but properly an arbitrary number of times in the generic case.)

[1] https://bugs.webkit.org/show_bug.cgi?id=71819
[2] http://phrogz.net/svg/html_location_in_svg_in_html.xhtml
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=700477
[4] http://phrogz.net/svg/html_location_in_svg_2.svg

Received on Thursday, 1 December 2011 01:26:19 UTC