W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: Discussion of File API at TPAC in Lyon

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 12 Nov 2010 17:58:29 -0800
Message-ID: <AANLkTinMhw=zAATq5OkkGT_5Y=bjXmJBVrr0hi=0cciB@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Adrian Bateman <adrianba@microsoft.com>, Arun Ranganathan <aranganathan@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Fri, Nov 12, 2010 at 5:54 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Nov 12, 2010 at 5:18 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Fri, Nov 12, 2010 at 3:47 PM, Jonas Sicking <jonas@sicking.cc> 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.

Received on Saturday, 13 November 2010 01:59:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC