Re: DOM collections index out of bounds and JavaScript.
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
Re: DOM collections index out of bounds and JavaScript.
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 >> bindings for these allows us to use indexed getters instead of calling >> the item method. > > I think in practice this has been a fiction in the edge case you're > interested in. > >> The problem is that trying to get a non existing property in JS should >> return undefined. > > This is what UAs implement, yes (modulo bugs). > That is mostly true. Though with IE errors, there is evidence there of catchall/proxy at hand. I recall Opera also has observable catchall or "proxy" for get access on certain collection objects to return "null" (looking for Opera on this computer...) Opera 10.5: document.styleSheets[99] === null - yet - document.childNodes[99] === undefined. Obviously since [[Get]] access on styleSheets collection returns null, it is not a [[Get]] as defined for native ES objects and so it can only be explained by a specialized [[Get]] on that object. AIUI ES committee is calling this "forwarded get access" on proxies now (though I've not been following that closely.). >> Since we are >> trying to realign these specs with the web it would make sense to try >> to make them fit better with JavaScript and mandate that the JS >> bindings for collections should return undefined for getting an item >> out of bounds. > That makes sense, as otherwise there would be a catchall at hand. And that brings us to the next issue: > This has nontrivial compat risks, I suspect. I've seen code that > compares the return value of item() to null using ===... > > I agree that using the [] notation should return undefined for > out-of-bounds stuff; I'm pretty sure the indexgetter stuff already says so. > The risk in changing "item" and property access to return undefined is that of strict equality checks, e.g. if (ob.item(n) === null) Loose equality checks will ahve the same result, as null == undefined, e.g. if (ob.item(n) == null) FWICT, it doesnt seem like a serious impact: http://www.google.com/codesearch?hl=en&lr=&q=\.item\%28\d%2B\s*\%29\s*%3D%3D%3D\s*null+lang%3Ajavascript&sbtn=Search Though please consider that I've missed something and double check my regexp: \.item\(\d+\s*\)\s*===\s*null lang:javascript Garrett
Re: DOM collections index out of bounds and JavaScript.
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 instead of calling the item method. I think in practice this has been a fiction in the edge case you're interested in. The problem is that trying to get a non existing property in JS should return undefined. This is what UAs implement, yes (modulo bugs). Since we are trying to realign these specs with the web it would make sense to try to make them fit better with JavaScript and mandate that the JS bindings for collections should return undefined for getting an item out of bounds. This has nontrivial compat risks, I suspect. I've seen code that compares the return value of item() to null using ===... I agree that using the [] notation should return undefined for out-of-bounds stuff; I'm pretty sure the indexgetter stuff already says so. -Boris
Re: createBlobURL
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 aspect of placing these interfaces on the Window and WorkerContext was to scope the lifetime of the manufactured url to the respective window or worker object. I thought adam's url api was all about parsing and building valid urls, so i'm not sure these methods are such a good fit for that interface. I agree. Another thing that is nice about the window.*BlobURL() API is that it makes it clear which origin the created url will have. I.e. the origin of the window which it's called on. I agree too, and upon reflection, I'm sorry I let myself get distracted by the URL API (but thanks anyway Anne for making me re-read it and contemplate its future ;-)). Renaming to createObjectURL/revokeObjectURL seems like the most straightforward way to generify the existing methods. I talked with Arun about this, and one argument was that we can keep the createBlobURL name since the returned url always uses the scheme 'blob'. However I have to say that I really like the createObjectURL/revokeObjectURL names, and it might create less confusion. So createObjectURL/revokeObjectURL has my vote. Well, that's two implementers who have working prototypes of createBlobURL and revokeBlobURL, and since you and Michael are in favor of the name change on behalf of the implementers, that's fine by me to rename it :). I'll make this change. Moreover, no need to hold up the CfC on this account, since these changes are easy to make. Future proponents of the nascent Stream API [1] can simply create another [Supplemental] interface (or further extend the existing one) to allow createObjectURL to take a Stream object and return a blob: URL. So that future proofs us elegantly enough. -- A* [1] http://dev.w3.org/html5/html-device/#stream-api
Re: DOM collections index out of bounds and JavaScript.
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 >> trying to realign these specs with the web it would make sense to try >> to make them fit better with JavaScript and mandate that the JS >> bindings for collections should return undefined for getting an item >> out of bounds. > > Does it particularly matter that collection.item(999) returns null while > collection['999'] evaluates to undefined? To me, it makes sense enough. > Functions and properties that returns Nodes, and which have no Node to > return, return null. I think for consistency with all of these other > funtions and properties, it is preferable to return null from > collection.item(). That’s a much bigger (better) consistency to strive > for than one between collection.item(999) and collection['999'], IMO. There's no difference between collection[999] and collection['999'] as an implementation has to check to see if a string can be converted to an integer (just as it does with array), otherwise for(in) enumeration would not work. Also in ecmascript logically all properties are string names it's only for reasons of performance that implementations distinguish integer vs. string property names internally. --Oliver > > -- > Cameron McCormack ≝ http://mcc.id.au/ >
Re: DOM collections index out of bounds and JavaScript.
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 try > to make them fit better with JavaScript and mandate that the JS > bindings for collections should return undefined for getting an item > out of bounds. Does it particularly matter that collection.item(999) returns null while collection['999'] evaluates to undefined? To me, it makes sense enough. Functions and properties that returns Nodes, and which have no Node to return, return null. I think for consistency with all of these other funtions and properties, it is preferable to return null from collection.item(). That’s a much bigger (better) consistency to strive for than one between collection.item(999) and collection['999'], IMO. -- Cameron McCormack ≝ http://mcc.id.au/
DOM collections index out of bounds and JavaScript.
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 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 try to make them fit better with JavaScript and mandate that the JS bindings for collections should return undefined for getting an item out of bounds. [1] http://dev.w3.org/html5/spec/Overview.html#dom-htmlcollection-item [2] http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration-item erik
Re: createBlobURL
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 the Window and > WorkerContext was to scope the lifetime of the manufactured url to the > respective window or worker object. I thought adam's url api was all about > parsing and building valid urls, so i'm not sure these methods are such a > good fit for that interface. I agree. Another thing that is nice about the window.*BlobURL() API is that it makes it clear which origin the created url will have. I.e. the origin of the window which it's called on. We could maintain that even if we used a URL constructor by saying that it's tied to the window whose .URL property was used as constructor, but it makes it a much more indirect connection. > Renaming to createObjectURL/revokeObjectURL seems like the most > straightforward way to generify the existing methods. I talked with Arun about this, and one argument was that we can keep the createBlobURL name since the returned url always uses the scheme 'blob'. However I have to say that I really like the createObjectURL/revokeObjectURL names, and it might create less confusion. So createObjectURL/revokeObjectURL has my vote. / Jonas > On Mon, Oct 18, 2010 at 11:50 AM, Arun Ranganathan wrote: >> >> 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, if people agree with me that the appropriate place would be the URL >>> object -- assuming for now we are going to get that -- it would be more >>> involved than just renaming. >> >> Moving these features to the URL object is more complex, but may be >> desirable. I'm not sure I can shoe horn that big an adjustment in time for >> the CfC (not least of all because there isn't a draft of the URL API I can >> refer to. I suppose I could specify the object that Adam has started with >> in the File API draft, though). Maybe more discussion is warranted at a >> venue like the TPAC. >> >> However, the revocation capability is pretty essential. So this is >> something we'd have to add to the URL API. And, the URL API has to be >> robust enough for both Stream and Blob use cases. >> >> Since Anne's suggestion is an important but late-breaking one, I'd propose >> tabling a CfC till the editor's draft accurately reflects consensus on what >> to do with URL generation and revocation for Blobs. Maybe one thing we can >> do with existing implementation trains is: >> >> 1. Use vendor prefixing for create* and revoke* according to some rules >> [1] (since underscores are rarely used in DOM APIs, we'd have >> window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really like >> to hear from the Chromium folks. Darin? Others? >> >> 2. Adding revoke* to Adam's URL *or* create more versatile APIs that are >> better named within window* that account for Stream *and* Blob. >> >> A benefit *and* a drawback of reusing the URL object is that this would >> make Blob URLs and HTTP URLs within the same object. It makes sense to >> revoke a Blob URL, but much less sense to revoke another URL. The schemes >> are different, but they *do* behave pretty much similarly. >> >> I'd like a bit more implementer feedback, especially since doing 2. would >> be a pretty late breaking change. I'm in favor of the best solution, but >> hate late breaking changes. Chrome folks? >> >> -- A* >> [1] >> https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing >> > >
Re: createBlobURL
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 manufactured url to the respective window or worker object. I thought adam's url api was all about parsing and building valid urls, so i'm not sure these methods are such a good fit for that interface. Renaming to createObjectURL/revokeObjectURL seems like the most straightforward way to generify the existing methods. On Mon, Oct 18, 2010 at 11:50 AM, Arun Ranganathan wrote: > 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, if people agree with me that the appropriate place would be the URL >> object -- assuming for now we are going to get that -- it would be more >> involved than just renaming. >> > > Moving these features to the URL object is more complex, but may be > desirable. I'm not sure I can shoe horn that big an adjustment in time for > the CfC (not least of all because there isn't a draft of the URL API I can > refer to. I suppose I could specify the object that Adam has started with > in the File API draft, though). Maybe more discussion is warranted at a > venue like the TPAC. > > However, the revocation capability is pretty essential. So this is > something we'd have to add to the URL API. And, the URL API has to be > robust enough for both Stream and Blob use cases. > > Since Anne's suggestion is an important but late-breaking one, I'd propose > tabling a CfC till the editor's draft accurately reflects consensus on what > to do with URL generation and revocation for Blobs. Maybe one thing we can > do with existing implementation trains is: > > 1. Use vendor prefixing for create* and revoke* according to some rules [1] > (since underscores are rarely used in DOM APIs, we'd have > window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really like > to hear from the Chromium folks. Darin? Others? > > 2. Adding revoke* to Adam's URL *or* create more versatile APIs that are > better named within window* that account for Stream *and* Blob. > > A benefit *and* a drawback of reusing the URL object is that this would > make Blob URLs and HTTP URLs within the same object. It makes sense to > revoke a Blob URL, but much less sense to revoke another URL. The schemes > are different, but they *do* behave pretty much similarly. > > I'd like a bit more implementer feedback, especially since doing 2. would > be a pretty late breaking change. I'm in favor of the best solution, but > hate late breaking changes. Chrome folks? > > -- A* > [1] > https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing > >
Re: Updates to FileAPI
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 wrote: > > WebApps WG, > > There have been some updates to the File API. > > http://dev.w3.org/2006/webapi/FileAPI/ > > Notable changes are: > > 1. Exception codes are no longer harnessed to DOMException's exception > codes, per discussion on this listserv. > > 2. Metadata attributes creationDate and lastModifiedDate have been > added > to > the File object, per discussion on the WHATWG listserv. My apologies for not bringing this up earlier; I just realized that the discussions I've been involved with weren't on the public lists, and I didn't share their conclusions on the relevant threads. The creationDate is going to be problematic. It works fine on Windows, but not on Unix-style systems. On Unix, ctime is *not* creation time. It's the last time the inode was modified, so e.g. changing permission bits will alter it. http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime. I see that your spec allows for an empty string on systems where creationDate isn't available, but my gut response is not to add a Windows-specific feature. >>> >>> (Yes, this discussion also occurred on WHATWG). >> >> Well, there was discussion in May about how modificationDate might be >> earlier than creationDate on Windows, due to odd copy behavior, but no >> mention IIRC that this couldn't work at all on Unix systems, which I >> think is significant. >> >>> Is your suggestion to *only* allow lastModifiedDate, and not to support >>> creationDate at all, even though implementations can return the empty >>> string >>> on [Unix-style] systems where creationDate is unreliable? >> >> Yes. If we publish APIs that only work on Windows, Windows-based >> developers will write code that works on their test machines, but >> fails elsewhere. Web code is supposed to be more portable than that. > > Eric: I agree with this, so I'll strike creationDate as an attribute on File > objects. > > (FWIW, though, the fact that we return ArrayBuffer objects on file reads, > which allows for endian considerations, means that we already allow a back > door for platform specific code). Yeah, I just don't see any efficient way of getting around that. And at least you *can* write code that'll work on any platform--you just have to be aware of the issues. And libraries can be written that'll wrap ArrayBuffers and take care of it for you, if that turns out to be useful. Thanks for the update. Eric
Re: Updates to FileAPI
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/2006/webapi/FileAPI/ Notable changes are: 1. Exception codes are no longer harnessed to DOMException's exception codes, per discussion on this listserv. 2. Metadata attributes creationDate and lastModifiedDate have been added to the File object, per discussion on the WHATWG listserv. My apologies for not bringing this up earlier; I just realized that the discussions I've been involved with weren't on the public lists, and I didn't share their conclusions on the relevant threads. The creationDate is going to be problematic. It works fine on Windows, but not on Unix-style systems. On Unix, ctime is *not* creation time. It's the last time the inode was modified, so e.g. changing permission bits will alter it. http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime. I see that your spec allows for an empty string on systems where creationDate isn't available, but my gut response is not to add a Windows-specific feature. (Yes, this discussion also occurred on WHATWG). Well, there was discussion in May about how modificationDate might be earlier than creationDate on Windows, due to odd copy behavior, but no mention IIRC that this couldn't work at all on Unix systems, which I think is significant. Is your suggestion to *only* allow lastModifiedDate, and not to support creationDate at all, even though implementations can return the empty string on [Unix-style] systems where creationDate is unreliable? Yes. If we publish APIs that only work on Windows, Windows-based developers will write code that works on their test machines, but fails elsewhere. Web code is supposed to be more portable than that. Eric: I agree with this, so I'll strike creationDate as an attribute on File objects. (FWIW, though, the fact that we return ArrayBuffer objects on file reads, which allows for endian considerations, means that we already allow a back door for platform specific code). -- A*
Re: createBlobURL
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, if people agree with me that the appropriate place would be the URL object -- assuming for now we are going to get that -- it would be more involved than just renaming. Moving these features to the URL object is more complex, but may be desirable. I'm not sure I can shoe horn that big an adjustment in time for the CfC (not least of all because there isn't a draft of the URL API I can refer to. I suppose I could specify the object that Adam has started with in the File API draft, though). Maybe more discussion is warranted at a venue like the TPAC. However, the revocation capability is pretty essential. So this is something we'd have to add to the URL API. And, the URL API has to be robust enough for both Stream and Blob use cases. Since Anne's suggestion is an important but late-breaking one, I'd propose tabling a CfC till the editor's draft accurately reflects consensus on what to do with URL generation and revocation for Blobs. Maybe one thing we can do with existing implementation trains is: 1. Use vendor prefixing for create* and revoke* according to some rules [1] (since underscores are rarely used in DOM APIs, we'd have window.moz_createBlobURL() or chrome_createBlobURL( ) ), but I'd really like to hear from the Chromium folks. Darin? Others? 2. Adding revoke* to Adam's URL *or* create more versatile APIs that are better named within window* that account for Stream *and* Blob. A benefit *and* a drawback of reusing the URL object is that this would make Blob URLs and HTTP URLs within the same object. It makes sense to revoke a Blob URL, but much less sense to revoke another URL. The schemes are different, but they *do* behave pretty much similarly. I'd like a bit more implementer feedback, especially since doing 2. would be a pretty late breaking change. I'm in favor of the best solution, but hate late breaking changes. Chrome folks? -- A* [1] https://wiki.mozilla.org/Tantek-Mozilla-projects#DOM_API_vendor_prefixing
Re: createBlobURL
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 accept URL objects in addition to strings? > > I am not sure what the use case for revoking is, but that method can move to > the URL object itself I suppose. (I would not want to modify everything to > also accept URL objects by the way.) Without revoking the UA has to keep around the URL-string -> resource mapping for the lifetime of the page. Which in the world of web apps can be a very long time. Even worse, in the case of dynamically created blobs (blobbuilder, canvas.toFile/toBlob/getAsFile whatever we'll call it), the resource has to stay around at least on the users file system for the lifetime of the page. / Jonas
Re: CfC: WD of File API; deadline October 22
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 preferred and encouraged and
> silence will be assumed to be assent.
>
> The deadline for comments is October 22. This comment period is a bit
> shorter than our typical 1-week review period but this will allow us to sync
> the publication of this spec with the File API: {Writer, Directories and
> System} specs. If this short comment period causes any issues or concerns,
> please let us know.
>
> -Art Barstow
>
>
>
>
>
Re: createBlobURL
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 case for revoking is, but that method can move to the URL object itself I suppose. (I would not want to modify everything to also accept URL objects by the way.) -- Anne van Kesteren http://annevankesteren.nl/
Re: createBlobURL
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 this function. > > Well, if people agree with me that the appropriate place would be the URL > object -- assuming for now we are going to get that -- it would be more > involved than just renaming. 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? / Jonas
Re: createBlobURL
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 place would be the URL object -- assuming for now we are going to get that -- it would be more involved than just renaming. -- Anne van Kesteren http://annevankesteren.nl/
Re: createBlobURL
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 >>> distant future. >> >> No, but there should be. I think it's Firefox nightlies and Chromium >> nightlies for now. Firefox isn't using a prefix on the method. > > I would prefer it if createBlobURL and co were prefixed. Everything else is > probably stable enough. cc'ing Darin who knows more about the chrome implementation status here. I was under the impression that they were even closer to shipping this than we are. 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. / Jonas
Re: createBlobURL
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 method (with a better name) that takes Streams or Blobs as arguments? Do you have a suggestion for signature or method name? I did not come further than createURL or createURLFromObject. However, if we get URL objects (or maybe WebURL to prevent clashes) tying it to that makes a lot of sense to me. Otherwise we will get createStreamURL as well which seems kind of unnecessary. Maybe even better, can we somehow converge this with the URL specification Adam Barth was working on? So you can do new URL(Blob) rather than having more methods on Window? OK, that's engineering for maximum use cases, but not a bad idea on the whole. However last I checked, the URL API was a proposal as a Google doc[2]. Does it live somewhere more permanent? No, not yet, but I suspect it would not be a problem for Adam to make this into a Working Draft. Implementations are already in circulation that have *.createBlobURL which leads me to: 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 distant future. No, but there should be. I think it's Firefox nightlies and Chromium nightlies for now. Firefox isn't using a prefix on the method. I would prefer it if createBlobURL and co were prefixed. Everything else is probably stable enough. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0083.html [2] https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1# -- Anne van Kesteren http://annevankesteren.nl/
Re: createBlobURL
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, positive response is preferred and
encouraged and silence will be assumed to be assent.
The deadline for comments is October 22. This comment period is a bit
shorter than our typical 1-week review period but this will allow us
to sync the publication of this spec with the File API: {Writer,
Directories and System} specs. If this short comment period causes
any issues or concerns, please let us know.
I support publication, but [XHR2] is currently a broken link (misses a
# I think).
Duly noted. I'll fix this ASAP.
Also, if createBlobURL is the way to go -- rather than Blob.url -- can
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 method (with a better name) that
takes Streams or Blobs as arguments? Do you have a suggestion for
signature or method name?
Otherwise we will get createStreamURL as well which seems kind of
unnecessary. Maybe even better, can we somehow converge this with the
URL specification Adam Barth was working on? So you can do new
URL(Blob) rather than having more methods on Window?
OK, that's engineering for maximum use cases, but not a bad idea on the
whole. However last I checked, the URL API was a proposal as a Google
doc[2]. Does it live somewhere more permanent? Implementations are
already in circulation that have *.createBlobURL which leads me to:
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 distant future.
No, but there should be. I think it's Firefox nightlies and Chromium
nightlies for now. Firefox isn't using a prefix on the method.
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0083.html
[2]
https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en&pli=1#
createBlobURL (was: Re: CfC: WD of File API; deadline October 22)
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
and silence will be assumed to be assent.
The deadline for comments is October 22. This comment period is a bit
shorter than our typical 1-week review period but this will allow us to
sync the publication of this spec with the File API: {Writer,
Directories and System} specs. If this short comment period causes any
issues or concerns, please let us know.
I support publication, but [XHR2] is currently a broken link (misses a # I
think).
Also, if createBlobURL is the way to go -- rather than Blob.url -- can we
design it in a generic way so that it also works for Stream objects?
Otherwise we will get createStreamURL as well which seems kind of
unnecessary. Maybe even better, can we somehow converge this with the URL
specification Adam Barth was working on? So you can do new URL(Blob)
rather than having more methods on Window?
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
distant future.
--
Anne van Kesteren
http://annevankesteren.nl/
CfC: WD of File API; deadline October 22
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 comments is October 22. This comment period is a bit
shorter than our typical 1-week review period but this will allow us to
sync the publication of this spec with the File API: {Writer,
Directories and System} specs. If this short comment period causes any
issues or concerns, please let us know.
-Art Barstow
