Re: [geometry] Should DOMRect have a serializer

On Fri, 15 Jan 2016 17:42:18 +0100, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 12/3/14 5:16 AM, Simon Pieters wrote:
>> 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.
>
> To close the loop on this, I never got a response from said people.  :(

OK. I've added serializers to the spec now:

https://github.com/w3c/fxtf-drafts/commit/75c3961700dcd8c8dde1d4fa16dba3fd1b717e17

As far as I can tell from reading WebIDL, it is only necessary to specify  
a serializer on the base interface, since toJSON is defined on the  
prototype. Let me know if I misunderstood this.


On Wed, 03 Dec 2014 11:16:34 +0100, Simon Pieters <simonp@opera.com> wrote:

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

Should be supersets except for DOMMatrixReadOnly which is an array instead  
(see below).


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

Included all attributes.

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

Included all attributes.

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

Since bounds is now a method, it's not included.

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

Went with this for now. I don't remember now why I thought an array made  
sense; it can be used for constructing a new matrix but it can't be passed  
in directly to e.g. multiplySelf(). Should I change DOMMatrixReadOnly's  
serializer to an object?

-- 
Simon Pieters
Opera Software

Received on Tuesday, 19 January 2016 08:59:08 UTC