Re: [geometry] DOMRectReadOnly serializer

# Boris Zbarsky (8 months ago)

On 10/16/16 12:46 PM, Rik Cabanier wrote:

Looking at 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](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.

Contact us to advertise here
# Rik Cabanier (8 months ago)

On Sun, Oct 16, 2016 at 11:14 AM, Boris Zbarsky bzbarsky@mit.edu wrote:

On 10/16/16 12:46 PM, Rik Cabanier wrote:

Looking at 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](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).

# Simon Fraser (8 months ago)

On Oct 16, 2016, at 12:04 PM, Rik Cabanier 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 lists.w3.org/Archives/Public/public-fx/2016JanMar/0014.html, [https://lists.w3.org/Archives/Public/public-fx/2016JanMar/0014.html](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 <heycam/webidl#188, [https://github.com/heycam/webidl/issues/188](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

# Dirk Schulze (8 months ago)

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 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](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

# Simon Fraser (7 months ago)

On Oct 18, 2016, at 10:06 PM, Dirk Schulze dschulze@adobe.com wrote:

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?

Yes. left, right, top, bottom can be derived from x, y, width, height. If you serialize all of them, you have redundant data with the possibility of inconsistency.

Simon

Want more features?

Request early access to our private beta of readable email premium.