Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

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.

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.

Quad to rect conversions:
  WebQuad rect.toQuad();
  WebRect quad.boundingRect();

Would be nice to have a way to convert a WebRectList to a WebQuadList.

  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

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

Received on Thursday, 8 September 2011 19:02:13 UTC