Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Sep 6, 2011, at 6:13 PM, Robert O'Callahan wrote:

> Reviving this old thread...
> 
> What do people think about the following as the most general API?
> 
> "element.getQuads(relativeTo)" returns a QuadList which is a list of Quads. Each Quad contains floats x0,y0,x1,y1,x2,y2,x3,y3, where each value is in CSS pixels relative to the top-left of the border-box of the first CSS box of the element relativeTo. If relativeTo has no CSS boxes or is somehow incomparable to the element (e.g., in a different window), return a zero-length list. Similar to getClientRects, there would be one quad per CSS border-box for the element, in content order.
> 
> Add element.getContentQuads(relativeTo), element.getPaddingQuads(relativeTo), and element.getMarginQuads(relativeTo) to return the other kinds of boxes.
> 
> We could add getBoundingRect(relativeTo), getBoundingContentRect(relativeTo), getBoundingPaddingRect(relativeTo), and getBoundingMarginRect(relativeTo), returning ClientRect, if that's helpful. Or we could add getBoundingQuad variants.
> 
> We could make relativeTo optional and default to the viewport, if that's helpful.
> 
> Things you can't do with this API:
> -- Get values relative to the content-box, padding-box or margin-box of relativeTo. You can call relativeTo.get*Quads(relativeTo) to get offsets for relativeTo's first box and then easily do the math.
> -- Get values relative to any box of relativeTo other than the first box. Working around that is hard given the possibility that boxes for the same element might have different ancestor transforms (which is true with CSS Regions I think). But I'm not sure if there's any need for such information. To fix, we would need a way to refer to a particular box of an element, and I have no idea how authors would want to do that.

I think this would be useful, but we should expose point mapping in the same way that we expose rect/quad mapping.

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.

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

Simon

Received on Wednesday, 7 September 2011 16:48:24 UTC