Re: [cssom] Element size/positioning information

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.

~TJ

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