Re: Discussion of File API at TPAC in Lyon

On Fri, Nov 12, 2010 at 5:58 PM, Tab Atkins Jr. <> wrote:
> On Fri, Nov 12, 2010 at 5:54 PM, Jonas Sicking <> wrote:
>> On Fri, Nov 12, 2010 at 5:18 PM, Tab Atkins Jr. <> wrote:
>>> On Fri, Nov 12, 2010 at 3:47 PM, Jonas Sicking <> wrote:
>>>> Maybe using a global object is better since we don't really want these
>>>> functions to appear on documents created using XMLHttpRequest,
>>>> DOMParser, etc.
>>>> Quick, someone suggest a name, whoever comes up with one first wins a
>>>> beer for next TPAC :)
>>> I think that whoever suggested URL already wins that beer.  ^_^
>> I guess me and Anne will have to split it then, since he proposed
>> using the URL constructor, and I said that I didn't like using the
>> constructor but suggested putting the functions on the URL interface
>> object. Though it's quite possible that someone beat me to that
>> proposal, in which case they better speak up or loose a beer forever
>> :-)
>> The downside of using URL though is that both Firefox and IE, and I
>> think Chrome too, seems to be ready to ship
>> createObjectURL/revokeObjectURL very soon, much sooner than the URL
>> object will be fully specified. That means that if we set up the URL
>> interface object for createObjectURL/revokeObjectURL, then it'll be
>> harder to feature detect support for the "real" URL object.
> Only marginally.  There'll be properties on URL that can be
> existence-tested for in the future.

Just to make implications clear to everyone. It means that you'll have
to feature detect URL by doing:

if (URL && "protocol" in URL.prototype)

you can't do

if (URL && URL.prototype.protocol)

since that will call the protocol getter with a "this" object set to
something other than a real URL instance and thus throw.

Alternatively, if all implementations are careful to not make URL a
constructor for now, the test will be

if (URL && URL.prototype)

If everyone is fine with this then I am too.

/ Jonas

Received on Saturday, 13 November 2010 02:10:44 UTC