W3C home > Mailing lists > Public > www-style@w3.org > November 2011

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

From: Yehuda Katz <wycats@gmail.com>
Date: Fri, 25 Nov 2011 19:46:53 -0800
Message-ID: <CAMFeDTX4+s8EW7Cv63_8Uc-H7K3g963SK_yHqZgA1CyO5iPKGA@mail.gmail.com>
To: robert@ocallahan.org
Cc: www-style <www-style@w3.org>
It seems like it might be useful to provide both transformed and
untransformed values (through different APIs), as there are valid use-cases
for both. Personally, I usually want the transformed value, but I
occasionally want the untransformed value.

Yehuda Katz
(ph) 718.877.1325

On Thu, Nov 24, 2011 at 4:12 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> The spec needs to make clear that getClientRects() returns rectangles that
> include the effect of transforms on ancestor elements. In particular each
> box rectangle is transformed by the ancestor transforms and then we take
> the viewport axis-aligned bounding-box of the result. Existing content
> requires this and it's more useful than not taking transforms into account.
> Gecko will change to have this behavior and other browsers already do.
> 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.) 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.
> 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]
Received on Saturday, 26 November 2011 03:47:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:07 UTC