On Tue, 25 Nov 2014 15:32:38 +0100, Boris Zbarsky <[email protected]> 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
