- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Tue, 25 Nov 2014 09:32:38 -0500
- To: Simon Pieters <simonp@opera.com>, public-fx@w3.org
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