Re: [cssom] Element size/positioning information

Okay, so let's summarize the rect/quad part of the discussion.

There are five boxes an author may be interested in measuring:

1. content box (+/- scrollbars)
2. padding box (+/- scrollbars)
3. border box
4. margin box
5. "scrollable area" box (like content box, but potentially larger)

Then, there are several variants on each:

a. multiple boxes for inlines, elements split across pages, etc.
b. bounding box of the multiple boxes
c. transformed quad(s?)
d. bounding box of the transformed quad(s)

For each of these (except c), we want the width/height, the
top/right/bottom/left in the viewport, and possibly a t/r/b/l offset
relative to a box of another element.  For c we just want the four
points of the quad, probably relative to the viewport, though possibly
relative to a box of another element.

This is a lot of possible combinations, probably too many to name in a
good, short form.  I rather like Andrew's approach of having a small
number of named functions which return the proper values based on
arguments.

If we take that approach, I like something like this:

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.

Element.getQuad()
 - returns a quad for the visual (post-transformed) box (maybe
bounding box) as an object exposing x0/y0/x1/y1/x2/y2/x3/y3, with
x0/y0 being the point corresponding with the top-left corner of the
original box, and the rest going clockwise around (this matches normal
CSS corner ordering).  The points are relative to the viewport's
top/left.

Where <part> is:

'margin': margin box (with something intelligent about collapsed margins)
'padding': padding box
'content': content box
'inner': content box, minus the effect of scrollbars
'scroll': scrollable area


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


Things I've Omitted:

* The 'edge' parameter from Andrew's API, because it seems unnecessary
- we can just return all six values at the same time; if you calculate
one, the rest are basically free.

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

* Bounding box of the transformed quad.  I'm not certain this is
useful; I just included it for completeness in the previous list.  In
the (presumably?) rare cases you need it, it's pretty simple to
generate yourself - 'left' and 'right' are the min/max x values from
the quad, 'top' and 'bottom' are the min and max y values, and width
and height are calculable from the sides.

~TJ

Received on Tuesday, 12 April 2011 22:31:41 UTC