All values is what you get for APIs like getBoundingCluentRect and others too. It depends on the context which values are useful in certain situations. Sure, an author could compute those her/himself but it adds convenience. Is there a specific reason why you think we should not return those?
Greetings
Dirk
Sent from my iPhone
On Oct 17, 2016, at 5:11 AM, Simon Fraser <smfr@me.com<mailto:smfr@me.com>> wrote:
On Oct 16, 2016, at 12:04 PM, Rik Cabanier <cabanier@gmail.com<mailto:cabanier@gmail.com>> wrote:
On Sun, Oct 16, 2016 at 11:14 AM, Boris Zbarsky <bzbarsky@mit.edu<mailto:bzbarsky@mit.edu>> wrote:
On 10/16/16 12:46 PM, Rik Cabanier wrote:
Looking at
https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0014.html, it
looks like a WebIDL requirement.
Boris, SimonP, can you comment on this?
WebIDL provides a convenient syntax for the common case for serializers.
It _does_ allow you do define a totally custom serializer, like so:
serializer;
and then defining its behavior in prose however you want.
But note that the serializer syntax is in flux because it's overcomplicated already; see <https://github.com/heycam/webidl/issues/188>. That said, we should leave some way of specifying a completely custom serializer, but I see no reason it shouldn't just be the declaration of a method named toJSON which you then define in prose as usual to return whatever you want to return.
Since this feature is still being developed, maybe it shouldn't be implemented yet and we should be removed from the spec (or put at risk, moved to level 2, etc).
I think you can say serializer = { x, y, width, height } to get the desired behavior.
Simon
Received on Wednesday, 19 October 2016 05:07:29 UTC