Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Thu, Sep 8, 2011 at 12:01 PM, Simon Fraser <smfr@me.com> wrote:

> On Sep 7, 2011, at 6:56 PM, Robert O'Callahan wrote:
>
> > On Thu, Sep 8, 2011 at 4:47 AM, Simon Fraser <smfr@me.com> wrote:
> > I think this would be useful, but we should expose point mapping in the
> same way that we expose rect/quad mapping.
> >
> > Sure, OK. Something like element.mapPointTo(relativeTo, x, y)?
>
> Sure. With all these new point/quad methods, maybe we should bite the
> bullet and have a WebPoint class with x, y members. Then WebQuad can have 4
> WebPoints.
>

Yes! <bikeshed>Did you pick WebPoint instead of Point due to compat fears?
Point, Rect and Quad seem a lot nicer without the Web prefix.</bikeshed>


> The poorly-named ClientRect should become WebRect.
>
> >
> > Having a variety of functions for the content, padding and margin rects
> seems like overkill; I would prefer one or two "bottleneck" quad mapping
> functions with helper methods to get the various boxes for a given element.
> >
> > I'm not quite sure what you mean. Can you suggest something?
>
> The basic pieces seem to be:
>
> 1. Get an element's padding, content, border and margin boxes relative to
> its own border-box, as rects.
> 2. Convert a rect to a quad.
> 3. Map arbitrary point from one element to another.
> 4. Map arbitrary quad from one element to another (mapping 4 points)
>
> We should make sure each of these steps is available to web developers,
> possibly with the addition of convenience wrappers.
>
> That suggests:
>
>  const CONTENT_BOX;
>  const PADDING_BOX;
>  const BORDER_BOX;
>  const MARGIN_BOX;
>  WebRectList element.localBoxes(boxType); // relative to border-box of
> first box.
>

Could we eschew methods altogether and have:
WebRectList element.contentBox;
WebRectList element.paddingBox;
WebRectList element.borderBox;
WebRectList element.marginBox;

WebRectList also implements WebRect where the point, width and height values
are for the bounding box. This is nice because the common case is that you
care about the bounding box but we also don't need a whole separate set of
methods/properties.

Quad to rect conversions:
>  WebQuad rect.toQuad();
>  WebRect quad.boundingRect();
>
> Would be nice to have a way to convert a WebRectList to a WebQuadList.
>

I agree. We should have toQuad and boundingRect on WebRectList and
WebQuadList as well.


>  WebPoint element.mapPoint(WebPoint, [relativeTo])  // point is border-box
> relative on both ends.
>  WebQuad element.mapQuad(WebQuad, [relativeTo]) // quads are border-box
> relative on both eneds
>  WebQuadList element.mapQuads(WebQuadList, [relativeTo]) // ditto
>

What values does relativeTo take in this context?

Can mapPoint/mapQuad be members of WebRect/WebQuad/WebRectList/WebQuadList
instead? That way, if you want a mapping other than the border-box you can
do something like the following:
node1.contentBox.mapPoint(node2.marginBox);

And if we add a point property to MouseEvent, then you can do:
node1.borderBox.mapPoint(event.point);


> Another issue that you have to deal with when mapping quads is that 3d
> transforms can result in quads with points at infinity. You have to do
> something sensible with these.
>
> >
> > In addition to the split boxes issue, we also have to settle on a
> coordinate system for split inlines (I believe David Baron suggested that
> the top  left of the first box could be considered to be the origin).
> >
> > Not quite sure what you mean here either. I think my suggestion is
> well-defined for inlines.
>
> Now I read your email again, I agree (you said "relative to the top-left of
> the border-box of the first CSS box of the element relativeTo").
>
> Simon
>
>
>
>