- From: Simon Pieters <simonp@opera.com>
- Date: Tue, 19 Jan 2016 09:58:35 +0100
- To: public-fx@w3.org, "Boris Zbarsky" <bzbarsky@mit.edu>
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