Re: [CSSOM] Revisiting transforms and getBoundingClientRect()

On Thu, Sep 19, 2013 at 8:30 AM, Simon Fraser <smfr@me.com> wrote:
> On Aug 28, 2013, at 4:43 pm, Robert O'Callahan <robert@ocallahan.org> wrote:
>>> 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).

Dictionaries as named arguments is used in some parts of the platform
now.  Other languages with named arguments show the usability of named
arguments to be quite nice (though since you're primarily a C++
programmer, I understand your reluctance).

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

Making authors do that math (requiring them to use gCS() and the like)
kinda defeats the point of these APIs, which is convenient conversion
between coordinate spaces.

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

I'm fine with roc's objection, but I don't understand yours, Simon.
My suggestion wouldn't have changed any of the return values; no quad
math when you're asking for a point.

~TJ

Received on Thursday, 19 September 2013 20:35:32 UTC