Re: [cssom] Element size/positioning information

>
>
>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Tuesday, April 12, 2011 3:01 PM
>To: robert@ocallahan.org
>Cc: Simon Fraser ; www-style list
>Subject: 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.

Just in case:

For that purposes I have these:

var (y,h) = element.rowY();
var (x,w) = element.columnY();

Each layout manager is responsible for implementation of these methods.
E.g. flow:text (default LM of <p>) will report line boxes.
flow:"template" - reports rows/columns happens to be there.
flow:table - the same thing.

(flow:text and flow:table LM's are not exposed directly but
determined while handling flow:deafult + display:... pair)

>
>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 motivation is to reduce pressure on heap manager. When used
these methods are called frequently - they should return as compact object
as possible. So if you you need just position [xy-tuple] it should be just 
it.

In my case is not an issue though. TIScript used in Sciter has
multi-returns so you can write:

var (x,y,w,h) = el.box(#rectw);

multiple values will be passes using stack rather than GCable heap,
but that is another story indeed. (By the way is there any discussion
on W3C about JavaScript destiny? Similar to www-styles or html5 ...
Or this part is not a W3C business? If not then actually why?)

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

Say you have a scrollable container with some child in it.
How you would get position of that child relative to the content
origin of the container?

In my case this:

var (x,y,w,h) = child.box(#rectw, #border, #parent);

will give you position of the element inside the container content.

var (x,y) = child.box(#position, #border, #view);
var (px,py) = child.parent.box(#position, #border, #view);

Delta of the above will give you relative position of the child
with respect of container scroll position.

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

I think it should be separate methods like

   elem.transform(point): point
   elem.inverseTransform(point): point

to do 2D transformations defined on element as you will definitely need it 
for
other cases.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Wednesday, 13 April 2011 02:43:35 UTC