Re: [geometry] Should DOMRect have a serializer

On Tue, 25 Nov 2014 15:32:38 +0100, Boris Zbarsky <bzbarsky@mit.edu> wrote:

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

Yes, please. It would help figuring out the details below.

I tried asking for use cases on Twitter but haven't got anything so far.  
https://twitter.com/zcorpan/status/539849995751804928

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

Yeah, true.

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

This is probably a bug.  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27490

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

No particular reason.

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

OK.

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

I wanted to include the minimum necessary I think, but it's not a problem  
to include 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.

OK. Always serializing 16 elements is simpler.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 3 December 2014 10:15:42 UTC