Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Sep 8, 2011, at 4:41 pm, Ojan Vafai wrote:

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

Agreed, but the risk of name conflicts seems high.

>  
> 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;

These don't make it obvious that the box is relative to the element's own borderBox, not the viewport. I think a web developer, reading "element.paddingBox", would assume that it's a page- or viewport-relative rect.

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

True.

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

Seems reasonable.

>  
>  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?

That's the optional target element into whose coordinate space you're mapping. If omitted, you're mapping to the viewport (or page?).

> 
> 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);

No, because if you have a bare WebRect, you don't have the context of the element which it came from, so mapping to some other element makes no sense. And points/rects/quads don't get mapped between rects, they get mapped between elements.

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

What coordinate system is event.point in? Client coords? This reveals an issue; how to map from client coordinates into the space of an element. We'd need window.mapClientPointToElement(element), with rect and quad versions.

It's also a bit odd that omitting the target element element.mapPoint() maps into client coords. It would be more logical to assume that the implicit target is the document, and therefore to map into document coordinates.

Simon