On 10/18/10 9:34 PM, Garrett Smith wrote:
\.item\(\d+\s*\)\s*===\s*null lang:javascript
Doesn't catch cases when the argument to item is not a numeric constant,
most simply.
-Boris
On 10/18/10, Boris Zbarsky wrote:
> On 10/18/10 8:51 PM, Erik Arvidsson wrote:
>> When DOM was first spec'ed the collection interfaces all had some kind
>> of item method. These methods sometimes return like null[1] and
>> sometimes other values such as an empty string [2]. The JavaScript
>> bindi
On 10/18/10 8:51 PM, Erik Arvidsson wrote:
When DOM was first spec'ed the collection interfaces all had some kind
of item method. These methods sometimes return like null[1] and
sometimes other values such as an empty string [2]. The JavaScript
bindings for these allows us to use indexed getters
On 10/18/10 8:30 PM, Jonas Sicking wrote:
On Mon, Oct 18, 2010 at 5:17 PM, Michael Nordman wrote:
Chrome currently has this as...
DOMString createBlobURL(in Blob blob);
void revokeBlobURL(in DOMString blobURL);
... no prefix... on both Window and WorkerContext.
An important a
On Oct 18, 2010, at 6:11 PM, Cameron McCormack wrote:
> Erik Arvidsson:
>> The problem is that trying to get a non existing property in JS should
>> return undefined. Not null and not an empty string. I understand that
>> the spec used null since Java does not have undefined. Since we are
>> tryi
Erik Arvidsson:
> The problem is that trying to get a non existing property in JS should
> return undefined. Not null and not an empty string. I understand that
> the spec used null since Java does not have undefined. Since we are
> trying to realign these specs with the web it would make sense to
When DOM was first spec'ed the collection interfaces all had some kind
of item method. These methods sometimes return like null[1] and
sometimes other values such as an empty string [2]. The JavaScript
bindings for these allows us to use indexed getters instead of calling
the item method.
The prob
On Mon, Oct 18, 2010 at 5:17 PM, Michael Nordman wrote:
> Chrome currently has this as...
> DOMString createBlobURL(in Blob blob);
> void revokeBlobURL(in DOMString blobURL);
> ... no prefix... on both Window and WorkerContext.
> An important aspect of placing these interfaces on t
Chrome currently has this as...
DOMString createBlobURL(in Blob blob);
void revokeBlobURL(in DOMString blobURL);
... no prefix... on both Window and WorkerContext.
An important aspect of placing these interfaces on the Window and
WorkerContext was to scope the lifetime of the manuf
On Mon, Oct 18, 2010 at 12:37 PM, Arun Ranganathan wrote:
> On 10/12/10 2:24 PM, Eric Uhrhane wrote:
>>
>> On Tue, Oct 12, 2010 at 11:18 AM, Arun Ranganathan
>> wrote:
>>>
>>> On 10/12/10 2:12 PM, Eric Uhrhane wrote:
Arun:
On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathan
>
On 10/12/10 2:24 PM, Eric Uhrhane wrote:
On Tue, Oct 12, 2010 at 11:18 AM, Arun Ranganathan wrote:
On 10/12/10 2:12 PM, Eric Uhrhane wrote:
Arun:
On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathan
wrote:
WebApps WG,
There have been some updates to the File API.
http://dev.w3.org/200
On 10/18/10 12:16 PM, Anne van Kesteren wrote:
On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking
wrote:
I would be ok with moz prefixing, though it would be nice to try to
find a solution pretty quickly if all this is is a discussion about
finding an appropriate name for this function.
Well,
On Mon, Oct 18, 2010 at 9:44 AM, Anne van Kesteren wrote:
> On Mon, 18 Oct 2010 18:32:35 +0200, Jonas Sicking wrote:
>>
>> What would the revoking API look like? Or are you saying that there
>> would be no way to get a string representation of the URL and instead
>> things like img.src should acc
I support this.
On Mon, Oct 18, 2010 at 7:03 AM, Arthur Barstow wrote:
>
> Arun and Jonas would like to publish a new Working Draft of the File API
> spec and this is Call for Consensus to do so:
>
> http://dev.w3.org/2006/webapi/FileAPI/
>
> As with all of our CfCs, positive response is prefer
On Mon, 18 Oct 2010 18:32:35 +0200, Jonas Sicking wrote:
What would the revoking API look like? Or are you saying that there
would be no way to get a string representation of the URL and instead
things like img.src should accept URL objects in addition to strings?
I am not sure what the use ca
On Mon, Oct 18, 2010 at 9:16 AM, Anne van Kesteren wrote:
> On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking wrote:
>>
>> I would be ok with moz prefixing, though it would be nice to try to
>> find a solution pretty quickly if all this is is a discussion about
>> finding an appropriate name for
On Mon, 18 Oct 2010 18:09:24 +0200, Jonas Sicking wrote:
I would be ok with moz prefixing, though it would be nice to try to
find a solution pretty quickly if all this is is a discussion about
finding an appropriate name for this function.
Well, if people agree with me that the appropriate pla
On Mon, Oct 18, 2010 at 8:00 AM, Anne van Kesteren wrote:
>>> Also, is there some kind of implementation summary available regarding
>>> the File API specifications? With what is shipping prefixed and what is
>>> shipping without a prefix? We are interested in supporting this too in the
>>> dista
On Mon, 18 Oct 2010 16:45:04 +0200, Arun Ranganathan
wrote:
On 10/18/10 10:14 AM, Anne van Kesteren wrote:
we design it in a generic way so that it also works for Stream objects?
This would be a good idea; this was noted as part of the issues [1].
Is your suggestion to have a generic meth
On 10/18/10 10:14 AM, Anne van Kesteren wrote:
On Mon, 18 Oct 2010 16:03:30 +0200, Arthur Barstow
wrote:
Arun and Jonas would like to publish a new Working Draft of the
File API spec and this is Call for Consensus to do so:
http://dev.w3.org/2006/webapi/FileAPI/
As with all of our CfCs
On Mon, 18 Oct 2010 16:03:30 +0200, Arthur Barstow
wrote:
Arun and Jonas would like to publish a new Working Draft of the File
API spec and this is Call for Consensus to do so:
http://dev.w3.org/2006/webapi/FileAPI/
As with all of our CfCs, positive response is preferred and encouraged
Arun and Jonas would like to publish a new Working Draft of the File
API spec and this is Call for Consensus to do so:
http://dev.w3.org/2006/webapi/FileAPI/
As with all of our CfCs, positive response is preferred and encouraged
and silence will be assumed to be assent.
The deadline for
22 matches
Mail list logo
