Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

A bit late to the party, sorry.

On Aug 28, 2013, at 4:43 pm, Robert O'Callahan <robert@ocallahan.org> wrote:

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

Agreed. I have a minor preference for a DOM prefix but don't feel strongly.

> 
> 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 dislike the syntactical decoration of passing dictionaries that name the parameters, like
"node.getBoxQuads({relativeTo:otherNode})" 

since it's rarely (ever?) used elsewhere, and just just more to remember when typing (like like the
microsyntax that's used in gradients, I find it very hard to remember what the extra terms are,
and where to put them).

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

I don't see why you'd want to convert relative to a specific box in the source or target. We should just state that the
origin of the coordinate space for an element is the top left of its border box, and let authors do the math inside the
element. Thinking about different source/target boxes makes this much more complex than it needs to be,
and transforms never affect the relationship of the boxes within an element.

We could possibly create a convenience function to move a point between boxes within a node.

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

I'd also prefer not to do that for performance reasons. We should have to do quad math (mapping 4 points)
when just mapping a single point would do.

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

Simon