Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Wed, Aug 28, 2013 at 4:43 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> 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.

Note that Dirk's the maintainer of that code, and he's planning to
rename the interface, I think to TransformMatrix.  That prefix isn't
good for point/rect/quad, though.

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

On first glance, I had no clue what the relation was between the
passed node and quad, and what the quad was getting transformed to.
Linking the two args by name in the IDL makes it clearer that they're
interpreted together, and the "source" prefix makes it clearer that
there's an implicit "destination" node (what it's called on) and quad
(what's returned).

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

Yeah, that works.

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

Yeah, I'm not stuck on this.  This is fine.

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

Cool.

~TJ

Received on Thursday, 29 August 2013 00:13:32 UTC