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

Re: [cssom] Element size/positioning information

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 18 Apr 2011 11:04:38 -0700
Message-ID: <BANLkTimhJ1yjYo11NxZD-URbWH7ucOTzsQ@mail.gmail.com>
To: robert@ocallahan.org
Cc: Simon Fraser <smfr@me.com>, www-style list <www-style@w3.org>
On Sun, Apr 17, 2011 at 9:40 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Wed, Apr 13, 2011 at 10:01 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>> Element.getRects(<part>)
>> - returns an array of boxes, one for each "layout box thing" generated
>> by the element, corresponding to the chosen part.  Each box is an
>> object exposing top/right/bottom/left/width/height properties, with
>> the positions relative to the viewport's top/left.
>> Element.getRect()
>>  - returns the bounding box of all the layout boxes (untransformed) as
>> an object exposing top/right/bottom/left/width/height relative to the
>> viewport's top/left.
> Is this intended to be the same as getBoundingClientRect() today?

Yes, if there's no relativeTo parameter.

>> I'm not sure what's supposed to happen for transformed elements with
>> multiple layout box things.  Right now, webkit won't transform inline
>> elements, and a box broken across columns does something silly.  We
>> may or may need need a getQuads().
> Even if transforms don't apply to an inline element, you can still transform
> a block and then request the quads for an inline element inside that block
> and expect something reasonable.

Ooh, good point.  We'll definitely need getQuads(<part>), then.

>> * The 'relativeTo' parameter.  It doesn't seem sensical to return a
>> rectangle showing the displacement of one rectangle relative to
>> another rectangle; at minimum, the exposed values would mean quite
>> different things than in the normal case.  Simon agrees with me that
>> this might not be necessary, given that it's pretty simple to just get
>> the position of both boxes and subtract their top/left.  If we do want
>> it, it should be done through an additional function.
> That's true for rectangles, but you've eliminated it for quads too, and your
> argument doesn't work for quads and general 2D or 3D transforms.
> AFAIK getQuads(relativeTo, part) is the most general API, and we'd better
> have it because all other APIs lose information.

So, what precisely do you see the numbers being relative to?  In the
viewport case,it's the top-left corner of the viewport.  For arbitrary
elements, though, should it always be the top-left?  Of which box?
What about transformed elements?

> Note that returning
> coordinates relative to the viewport is not just inconvenient, it's lossy if
> you're working in a DOM subtree of a container with a non-invertible
> transform (e.g. a scale by 0).

I hadn't considered non-invertible transforms.  Excellent point.

Received on Monday, 18 April 2011 18:05:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC