W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2012

Re: In WebIDL, should having a .prototype on interface objects be optional?

From: Rick Waldron <waldron.rick@gmail.com>
Date: Fri, 28 Sep 2012 16:23:51 -0700
Message-ID: <CAHfnhfo=gJFVC6mz-9XVt=puSr=DDniSKq8FPWDDgJ3ydjz2JQ@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: Travis Leithead <travis.leithead@microsoft.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>, public-webapps <public-webapps@w3.org>
On Fri, Sep 28, 2012 at 4:14 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> Travis Leithead:
>> I guess you'd check for URL.href then? Or try { new URL("/test"); } catch
>> (ex) { console.log("not supported"); }
> I agree with Travis, you should be checking the particular features you
> want to use, rather than checking the existence of the prototype as a proxy
> for that test.
> If URL.prototype was required to exist, you could just do ("href" in
> URL.prototype).  Since it currently doesn't, you could do ("href" in
> (URL.prototype || {})).

I'm interested in knowing more about what would throw. If URL is not a
constructor function, it will throw, but if it is what aspect of the above
would be "not supported". I ask because currently Chrome's URL (webkitURL)
can construct, but it constructs a fairly useless instance and throws
nothing (new webkitURL("/test");)

Thanks in advance

Received on Friday, 28 September 2012 23:24:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:07 UTC