W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: [geometry] Dictionary argument for DOMQuad constructor

From: Simon Pieters <simonp@opera.com>
Date: Fri, 27 Mar 2015 11:17:04 +0100
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: "public-fx@w3.org" <public-fx@w3.org>, "Domenic Denicola" <d@domenic.me>, "Boris Zbarsky" <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <op.xv5iuqr5idj3kv@simons-mbp>
On Thu, 26 Mar 2015 22:10:08 +0100, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Fri, Mar 27, 2015 at 10:02 AM, Simon Pieters <simonp@opera.com> wrote:
>> It is useful to be able to use a straight JS object as a rect. I think  
>> it
>> would be good for Web developers to consistently support dictionary  
>> types
>> instead of supporting them in some places but require an object of the
>> proper interface in other places.
> Hmm. If we apply that consistency strictly, then we're not going to use
> interface types as parameters anywhere, correct?


> I'm not sure we should do that. It makes overloading impossible unless we
> make large changes to WebIDL.

The spec currently only uses overloading in the constructors, and the  
proposal here is to remove the overloading in favor of static methods.

> It also has performance implications: passing
> a DOMRectReadOnly as a DOMRectInit parameter naively requires unpacking  
> to
> a JS object and then repacking to a DOMRectInit. We could optimize that  
> but
> it's a significant amount of work that nobody's done yet AFAIK.

This applies equally to DOMPointInit, right?

> On Thu, 26 Mar 2015 21:13:04 +0100, Robert O'Callahan  
> <robert@ocallahan.org>
>> wrote:
>>  And FWIW we implemented that because it's what the spec used to say:
>>> http://www.w3.org/TR/2014/WD-geometry-1-20140522/#DOMQuad
>> Yes. That's why I ask if you're OK with the proposed change. :-)
> I'll go along with it if everyone decides it's the right thing to do. I'm
> not convinced yet.


At least Dirk and Tab have said that they also find the inconsistency  
being confusing/bad.

It seems this API is not being widely used yet.

The current state of the spec is broken (not valid WebIDL). How about I  
try to fix it to be more like what I think is more consistent, which in  
some cases is not compatible with what is implemented in Gecko, so we can  
compare it with the previous version of the spec? I can add an issue to  
the spec saying that the old version is implemented in Gecko and the new  
version is experimental and might not stick.

Simon Pieters
Opera Software
Received on Friday, 27 March 2015 10:17:34 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 March 2015 10:17:36 UTC