Re: [geometry] Should DOMRect have a serializer

On 11/25/14, 5:09 AM, Simon Pieters wrote:
> What are the use cases for JSON stringifying geometry objects?

Logging?  All I know is people are reporting bugs about the behavior 
being surprising when the stringify them.  I can ask why they're 
stringifying if that would be useful.

> It seems to me the returned object should have the same shape as the
> *Init dictionaries, so you can use it in the constructors that accept them.

You mean a superset of the shape, right?  Having more properties than 
the init dictionary contains is not a problem.

That said, the current state of the *Init dictionaries in the spec is a 
bit weird.  You can't construct a DOMRect from a DOMRectInit, but you 
can construct a DOMQuad from a DOMRectInit?

> For DOMRect, the first-class properties are x, y, width, height, so { x,
> y, width, height }.

Is there an actual reason to exclude top/right/bottom/left?

> For DOMPoint, we could either always serialize { x, y, w, z } or only
> serialize { x, y } when w = 0 and z = 1.

I think the former is a lot simpler, fwiw.

> For DOMQuad I guess it would just serialize as { p1, p2, p3, p4 }
> (without bounds).

Why without bounds?

> For DOMMatrix, I guess it makes sense to serialize an array with the
> elements. We could either always serialize all of them or only serialize
> 6 elements when is2D returns true.

Yeah, I'm not sure what's best here.

-Boris

Received on Tuesday, 25 November 2014 14:33:09 UTC