Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Thu, Aug 29, 2013 at 10:52 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> Your naming is inconsistent.  Merging with the other linked thread, we
> have "CSSRect", "Quad", and "DOMPoint".  You seem to have renamed the
> last one to "CSSPoint" in this email, which helps, but I'm still left
> wondering why it's not "CSSQuad".  (I kinda liked DOM as the prefix
> for all of them, on the assumption that these things'll be useful for
> more than just CSS.  Maybe we could divorce it further from "where
> it's specced" notions and call them LayoutPoint/Rect/Quad?  I'd like a
> name that doesn't have much friction with using these in a 3d geometry
> library.)
>

We also need to consider the Matrix work:
https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html

I think if we're going to use any prefix, we should use the same prefix for
Point, Rect, Quad and Matrix. I'm afraid to arrogate those names as-is.
Either DOM or CSS would work for me. Blink has already got an
implementation of CSSMatrix so I think we may as well go with the "CSS"
prefix. Yes, it's useful for more than just CSS, but that doesn't bother me.

The signatures of the convert* methods here and in the other linked
> thread constantly confuse me.  Perhaps a better naming scheme in the
> IDL would help, like "sourceNode" and "sourceQuad"?  Also, the name
> suggests a "quad, node" ordering, but the actual signature is the
> opposite.
>

I can't see how "Node sourceNode" is more helpful than "Node from". But I
agree about the ordering.

I don't understand why getBoxQuads lets you specify which box of the
> node you want, but the convert* methods don't.  It seems equally
> useful/necessary there - if you pulled a quad off of the padding box
> of something, manipulated it, and then want to convert it into another
> coordinate space, you have to ensure that the conversion knows it's
> relative to the padding box.
>

We could add an optional parameters dictionary to those methods with a
BoxType attribute for that.

So
dictionary ConvertCoordinateOptions {
  attribute BoxType fromBox; // defaults to "border"
  attribute BoxType toBox; // defaults to "border"
};
partial interface Node {
  CSSPoint convertPointFromNode(CSSPoint point, Node from, optional
ConvertCoordinateOptions options);
  CSSQuad convertRectFromNode(CSSRect rect, Node from, optional
ConvertCoordinateOptions options);
  CSSQuad convertQuadFromNode(CSSQuad quad, Node from, optional
ConvertCoordinateOptions options);
};
?

fromBox would be ignored for non-Element 'from' Nodes, and toBox would be
ignored for non-Element 'this' nodes.

Maybe we could unify the three convert* methods under a slightly more
> generic name (convertCoordsFromNode?) and just making the
> quad/rect/point arg a union?  That would mean that it has to return a
> union of quad and point, but I think that's just clumsy in WebIDL, not
> in real life.  (It would also make it easier to extend into handling
> Tris, if we ever find a need to do so, but this isn't an important
> thing.)
>

That means the relationship between the input type and the result type is
lost from WebIDL. I'd prefer not to do that. It may cause confusion about
what is returned, especially since convertRectFromNode doesn't return the
same type as its parameter.

Could we make Rect a subtype of Quad?  It would make it easier to
> write generic code that handles quads - it's annoying that right now
> if we have a mix of Rects and Quads I'd need to discriminate them in
> my code, or would have to manually convert the former into the latter.
>

Yes, good idea. That shouldn't be a problem.

The QuadList interface is terrible. :/  We have better ways to do this
> in WebIDL now - make it an [ArrayClass].  (Maybe we can change
> ClientRectList as well?)
>

Sure.

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