Re: [geometry] DOMQuad is weird

On Wed, Oct 19, 2016 at 12:00 PM, Simon Fraser <> wrote:

> On Oct 19, 2016, at 11:37 AM, Rik Cabanier <> wrote:
> On Tue, Oct 18, 2016 at 11:29 AM, Simon Fraser <> wrote:
>> DOMQuad seems like the odd one out of the Geometry interfaces. It doesn’t
>> have a ReadOnly variant, and, unlike DOMRect, its points are 3D DOMPoints
>> (with x,y,w,z). In the WebKit implementation, we never have a need to store
>> quads in 3D space; they only ever exist in the plane of an element. We do
>> have code that tracks an accumulated matrix along with a planar quad when
>> mapping through 3D rendering contexts, but the quads are only ever used
>> once you flatten into the plane of an element.
>> Also, I think [SameObject] readonly attribute DOMPoint cause unwanted
>> behavior for JS authors.
>> Consider:
>> var quad = DOMQuad.fromQuad({ p1:{ x:11, y:12 }, p2:{ x:22, y:23 }, p3:{
>> x:33, y:34 }, p4:{ x:44, y:45 } });
>> var firstPoint = quad.p1;
>> firstPoint.x = 9999;
>> if (quad.p1.x == 9999)
>>     console.log(“what the hey”); <— this happens
>> I think it’s very counterintuitive for JS authors to have the points be
>> “live” if you pass them to other parts of the code and then modify them.
> I don't understand why that would be counter-intuitive. Isn't this normal
> JavaScript behavior?
> As a naive JavaScript author, I would consider a point to be a primitive
> type that's copied by value.
> Dean points out that the primitive types are actually DOMPoint.x and
> DOMPoint.y, so what I wrote above is "expected" JS behavior.

I'm following. Are you agreeing that that having the live object is

> Having them be non-live would be "magic" because a DOMQuad is supposed to
> be a simple detached object.
> Maybe DOMQuad should be entirely read-only, or should return copies of
> points (getP1(), getP2() etc).

The spec calls out that you can change the value of the points:

The p1 attribute must return a DOMPoint
<> that represents p1
<> of the quadrilateral it
was invoked on. The author can modify the returned DOMPoint
<> object, which directly affects
the quadrilateral.

so it seems that this was intended behavior.

Is this creating implementation problems for you?

Received on Wednesday, 19 October 2016 19:38:18 UTC