Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

[Reviving old thread]

On Fri, Sep 9, 2011 at 7:01 AM, Simon Fraser <smfr@me.com> wrote:

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

Splitting the pieces up this way has a problem: with CSS Regions (or CSS
Overflow), it's possible for a CSS transform to apply to one box of an
element, but not another --- when one fragment flows into a container that
has a CSS transform, and another fragment flows into a different container
with no transform. In such a case, step 1 is lossy :-(.

Therefore I think we need to offer a way to get the boxes as a list of
quads. In that case, I think we may as well offer coordinate-space
conversion in the same call.

Part 3 has been more recently addressed:
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0099.html

So here's my proposal:

Rename ClientRect to CSSRect.

[Constructor(CSSPoint, CSSPoint, CSSPoint, CSSPoint),
 Constructor(ClientRect)]
interface Quad {
  readonly attribute CSSPoint p1; // 2D only (z,w not present)
  readonly attribute CSSPoint p2;
  readonly attribute CSSPoint p3;
  readonly attribute CSSPoint p4;
  readonly attribute CSSRect bounds;
};

[Constructor(sequence<Quad>)]
interface QuadList {
  readonly attribute unsigned long length;
  getter Quad item(unsigned long index);
  readonly attribute CSSRect bounds;
};

enum BoxType { "margin", "border", "padding", "content" };
dictionary BoxQuadOptions {
  attribute BoxType box; // defaults to "border"
  attribute Node relativeTo; // defaults to viewport
};

partial interface Node {
  QuadList getBoxQuads(BoxQuadOptions options);
  Quad convertQuadFromNode(Node from, Quad quad);
  Quad convertRectFromNode(Node from, CSSRect rect);
};

Edge cases handled as in
http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0099.htmland
following thread.

I've proposed packing getBoxQuads parameters into a dictionary. Separate
getMarginBoxQuads etc methods, each with an optional "Node relativeTo"
parameter, would work too, but I think would be less easily extended in the
future. I also think that in this case naming the "relativeTo" parameter is
a good thing (e.g. "node.getBoxQuads({relativeTo:otherNode})" seems easier
to read than "node.getBoxQuads(otherNode)").

Any thoughts?

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*