Re: publish new Working Draft of Indexed Database API; deadline April 16
On Sat, Apr 9, 2011 at 2:22 PM, Arthur Barstow art.bars...@nokia.com wrote: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html I expect this message to only have editorial comments. However, I'm not fond of April 16th, this month is tax month and I still need to file. Transaction A transaction is used to interact with the data in a database. Whenever data is read or written to the database this is done using a transaction. maybe s/this/it/ All transactions are created using a connection, I don't like using, perhaps from? -- I haven't gotten to the API yet. I'm also uncertain about 'a connection' vs. 'connections' which is the transactions connection. s/transactions/transaction's/ The transaction has a mode which determines which types of interactions can be performed using the transaction. s/using the transaction/upon it/ ? -- The transaction also started the sentence. The mode is set when the transaction is created and remains constant for the s/constant/fixed/ lifetime of the transaction. s/lifetime/life/ The transaction also has a scope which determines which object stores the transaction can interact with. s/which.*with/the object stores with which the transaction may interact/. Finally, transactions have a active flag, s/ a / an / s/Finally, t/T/ -- It isn't Finally -- Finally is used again in the next sentence. which determines if new requests can currently be placed against the transaction. The prose here implies that this is mutable, it's also awkward (probably he use of 'currently'). Finally, transactions also contain a request list of requests which have been placed against the transaction. It seems that placed is treated as technical language, I'd expect it to be defined somewhere (or globally replaced by 'made'). Transactions have a constant scope which is determined when the transaction is created and remains constant for the lifetime of the transaction. Each transaction has a fixed scope determined at creation time. Transactions offer some protection from application and system failures. A transaction represents an atomic and durable set of data access and mutation operations. I know that data can be uncountable or plural, but I'm unsure that 'access' fits with its use here -- should it be 'accesses'? This is encouraged using the automatically committing functionality described below. s/using the automatically/by the automatic/ Authors can still cause transactions to run for a long time, however this is generally not a usage pattern which is recommended s/usage pattern which is recommended/a recommended usage pattern/ and can lead to bad user experience in some implementations. possibly a bad user experience | bad user experiences ? A transaction is created using IDBDatabase.transaction. The arguments passed determine what the scope of the transaction is s/what//; s/is// and whether it's read only or not. whether or not it is read-only. When a transaction is created its active flag is initially set to true. The implementation MUST allow requests to be placed against the transaction whenever the active flag is true. This is the case even if the transaction has not yet been started. Until the transaction is started the implementation MUST NOT execute these requests, but the implementation MUST still keep track of the requests and their order. s/, but/;/ s/still// Requests may only be placed against the transaction s/the/a/ while the transaction is active. s/the transaction/it/ If a request is attempted to be placed against a transaction when I find request/attempted/placed awkward, possibly because it lacks an actor... it is not active, I believe not active is used here to be the technical state not active, perhaps it should be marked up. Otherwise as this is prose, I'd use inactive. the implementation MUST reject the attempt by throwing a TRANSACTION_INACTIVE_ERR exception. Inactive is used in the exception type, it's a valid English word Once an implementation is able to enforce the constraints defined for the mode of the transaction, transaction mode defined below, the implementation MUST asynchronously start the transaction. When this happens is affected by the mode in which the transaction is opened, and which object stores are included in scope of the transaction. s/which/the/ s/are// s/scope of the transaction/the transaction's scope/ Once the transaction has been started the implementation can start executing the requests placed against the transaction. Unless otherwise defined requests MUST be executed in the order they are placed against the transaction. s/they/in which they/ s/are/were/ I find placed against strange. made against seems to work Otherwise placed into Likewise, their result MUST be returned in the order the request was placed against a specific transaction. result appears to be used as a mass noun, but request is singular, I'm pretty
[FileAPI] File.slice spec bug
Hi All, It was recently (yesterday) pointed out to me that we let a bad spec-bug slip through for File.slice. It doesn't match the argument semantics of Array.slice which can be very confusing for developers. In Array.slice the second argument is the index of the last item to be included in the returned slice. In File.slice the second argument is the number of bytes included in the returned slices. In other words, it's Array.slice(start, end), but File.slice(start, length). Additionally, in Array.slice the second argument is optional. File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. So consider this an official request, would chrome be ok with changing the spec here? / Jonas
Re: [FileAPI] File.slice spec bug
On 4/12/11 2:24 PM, Jonas Sicking wrote: Hi All, It was recently (yesterday) pointed out to me that we let a bad spec-bug slip through for File.slice. It doesn't match the argument semantics of Array.slice which can be very confusing for developers. In Array.slice the second argument is the index of the last item to be included in the returned slice. In File.slice the second argument is the number of bytes included in the returned slices. In other words, it's Array.slice(start, end), but File.slice(start, length). Additionally, in Array.slice the second argument is optional. File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. So consider this an official request, would chrome be ok with changing the spec here? / Jonas I'm bummed that we collectively let this slip through the cracks, and personally think it's early enough to fix it. But we should also decide how closely to match Array.slice. Should we allow code of the sort file.slice(-80)? Code of that sort is allowed with Array.slice. MDC has good developer docs about what's in Firefox for Array.slice: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/slice Developers may have already discovered file.slice (e.g. see http://hacks.mozilla.org/2011/04/resumeupload/), so fixing this will involve some messaging. -- A*
Re: [FileAPI] Result of calling MultipleReads on FileReader
On 4/11/11 1:39 PM, Adrian Bateman wrote: On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote: On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathana...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). I don't think so. I think that calling two read methods is the kind of thing that will come up in initial testing, the exception won't be caught at all, and thus will be noticed and the bug removed. On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. I'd *much* rather have an exception than silently get some random result depending on which method I accidentally called last. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception. I agree with Eric - I prefer to fail fast when the developer has misused an API. It makes it much easier to see that there is a mistake and debug why. So the key question to me is Is this misuse? I can't think of a good use case where a developer would want to call read again during the LOADING state and expect that the correct behaviour would be to implicitly call abort(). That doesn't seem like a common scenario. In the EMPTY or DONE states makes perfect sense - that makes FileReader reusable - but during LOADING I think is a developer mistake. I felt it desirable to stick to what XHR does, which is an abort on previous calls. Eric, Adrian: do you both feel we shouldn't be consistent with XHR? If so, an exception makes sense. But I honestly think similarity with XHR is desirable in this case. -- A*
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Tue, Apr 12, 2011 at 11:44 AM, Arun Ranganathan a...@mozilla.com wrote: On 4/11/11 1:39 PM, Adrian Bateman wrote: On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote: On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathana...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). I don't think so. I think that calling two read methods is the kind of thing that will come up in initial testing, the exception won't be caught at all, and thus will be noticed and the bug removed. On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. I'd *much* rather have an exception than silently get some random result depending on which method I accidentally called last. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception. I agree with Eric - I prefer to fail fast when the developer has misused an API. It makes it much easier to see that there is a mistake and debug why. So the key question to me is Is this misuse? I can't think of a good use case where a developer would want to call read again during the LOADING state and expect that the correct behaviour would be to implicitly call abort(). That doesn't seem like a common scenario. In the EMPTY or DONE states makes perfect sense - that makes FileReader reusable - but during LOADING I think is a developer mistake. I felt it desirable to stick to what XHR does, which is an abort on previous calls. Eric, Adrian: do you both feel we shouldn't be consistent with XHR? If so, an exception makes sense. But I honestly think similarity with XHR is desirable in this case. I'd rather have an exception, and no interruption to the read already in progress. I don't think similarity with XHR, which is already somewhat different, is worth the cost. Eric
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Mon, Apr 11, 2011 at 10:39 AM, Adrian Bateman adria...@microsoft.com wrote: On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote: On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). I don't think so. I think that calling two read methods is the kind of thing that will come up in initial testing, the exception won't be caught at all, and thus will be noticed and the bug removed. On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. I'd *much* rather have an exception than silently get some random result depending on which method I accidentally called last. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception. I agree with Eric - I prefer to fail fast when the developer has misused an API. It makes it much easier to see that there is a mistake and debug why. So the key question to me is Is this misuse? I can't think of a good use case where a developer would want to call read again during the LOADING state and expect that the correct behaviour would be to implicitly call abort(). That doesn't seem like a common scenario. In the EMPTY or DONE states makes perfect sense - that makes FileReader reusable - but during LOADING I think is a developer mistake. FileReader is extremely similar to XMLHttpRequest. The main difference is in how you initiate the request (.open/.send vs. .readAsX). This similarity is even getting stronger now that XHR gets .result. So I think there are good reasons to sticking to XMLHttpRequest here too. Note that no error events are fired by XMLHttpRequest. Just an abort event. So error is still reserved for actual reading errors whereas abort will fire for script-initiated aborts. I agree that calling .readAsX multiple times could be an indication of developer bugs and as such could throw an exception. However I think given the precedence set by XMLHttpRequest it could just as well mean that a new resource is now the one that the author is interested in reading. / Jonas
Re: [FileAPI] File.slice spec bug
File.slice was first supported in Firefox 4. - Kyle On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote: The biggest concern is that this is a breaking change and quite a few web applications have already been using it. As far as I know, File.slice(start, length) has been supported as early as Chrome 6 and Safari 5. Also Firefox 3 is supporting it. How do we communicate with web developers about this breaking change if we decide to make the change? Jian On Tue, Apr 12, 2011 at 11:34 AM, Arun Ranganathan a...@mozilla.comwrote: On 4/12/11 2:24 PM, Jonas Sicking wrote: Hi All, It was recently (yesterday) pointed out to me that we let a bad spec-bug slip through for File.slice. It doesn't match the argument semantics of Array.slice which can be very confusing for developers. In Array.slice the second argument is the index of the last item to be included in the returned slice. In File.slice the second argument is the number of bytes included in the returned slices. In other words, it's Array.slice(start, end), but File.slice(start, length). Additionally, in Array.slice the second argument is optional. File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. So consider this an official request, would chrome be ok with changing the spec here? / Jonas I'm bummed that we collectively let this slip through the cracks, and personally think it's early enough to fix it. But we should also decide how closely to match Array.slice. Should we allow code of the sort file.slice(-80)? Code of that sort is allowed with Array.slice. MDC has good developer docs about what's in Firefox for Array.slice: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/slice Developers may have already discovered file.slice (e.g. see http://hacks.mozilla.org/2011/04/resumeupload/), so fixing this will involve some messaging. -- A*
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote: The biggest concern is that this is a breaking change and quite a few web applications have already been using it. As far as I know, File.slice(start, length) has been supported as early as Chrome 6 and Safari 5. Also Firefox 3 is supporting it. How do we communicate with web developers about this breaking change if we decide to make the change? Firefox added support for .slice in Firefox 4. Safari 5 does not seem to support it. Based on that I'd like to see something backing the claim that Chrome 6 supports it. / Jonas
Re: [FileAPI] File.slice spec bug
We're using ArrayBuffer... It's been through a few changes of its own relating to slice. I think they just went the route of renaming the method. -Charles On Apr 12, 2011, at 1:36 PM, Dmitry Titov dim...@chromium.org wrote: Indeed, it appeared in FF 4 which was shipped end of March, so if it was only FF API, it would be fine to change it since it's only been official for a couple of weeks. However in Chrome this was shipped August 2010, and in Safari sometime in 2010 I think. Oprah seems also support it, although I don't know for how long. This could give plenty of time to developers to start using the API, so I can see how it would give us a pause while considering such a change... Dmitry On Tue, Apr 12, 2011 at 1:15 PM, Kyle Huey m...@kylehuey.com wrote: First supported in Firefox in Firefox 4, if that is unclear. On Tue, Apr 12, 2011 at 1:14 PM, Kyle Huey m...@kylehuey.com wrote: File.slice was first supported in Firefox 4. - Kyle On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote: The biggest concern is that this is a breaking change and quite a few web applications have already been using it. As far as I know, File.slice(start, length) has been supported as early as Chrome 6 and Safari 5. Also Firefox 3 is supporting it. How do we communicate with web developers about this breaking change if we decide to make the change? Jian On Tue, Apr 12, 2011 at 11:34 AM, Arun Ranganathan a...@mozilla.com wrote: On 4/12/11 2:24 PM, Jonas Sicking wrote: Hi All, It was recently (yesterday) pointed out to me that we let a bad spec-bug slip through for File.slice. It doesn't match the argument semantics of Array.slice which can be very confusing for developers. In Array.slice the second argument is the index of the last item to be included in the returned slice. In File.slice the second argument is the number of bytes included in the returned slices. In other words, it's Array.slice(start, end), but File.slice(start, length). Additionally, in Array.slice the second argument is optional. File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. So consider this an official request, would chrome be ok with changing the spec here? / Jonas I'm bummed that we collectively let this slip through the cracks, and personally think it's early enough to fix it. But we should also decide how closely to match Array.slice. Should we allow code of the sort file.slice(-80)? Code of that sort is allowed with Array.slice. MDC has good developer docs about what's in Firefox for Array.slice: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/slice Developers may have already discovered file.slice (e.g. see http://hacks.mozilla.org/2011/04/resumeupload/), so fixing this will involve some messaging. -- A*
Re: [FileAPI] File.slice spec bug
Taking back the claim about Safari :-) It doesn't have File.slice indeed. Sorry about that. On Tue, Apr 12, 2011 at 1:36 PM, Dmitry Titov dim...@chromium.org wrote: Indeed, it appeared in FF 4 which was shipped end of March, so if it was only FF API, it would be fine to change it since it's only been official for a couple of weeks. However in Chrome this was shipped August 2010, and in Safari sometime in 2010 I think. Oprah seems also support it, although I don't know for how long. This could give plenty of time to developers to start using the API, so I can see how it would give us a pause while considering such a change... Dmitry On Tue, Apr 12, 2011 at 1:15 PM, Kyle Huey m...@kylehuey.com wrote: First supported in Firefox in Firefox 4, if that is unclear. On Tue, Apr 12, 2011 at 1:14 PM, Kyle Huey m...@kylehuey.com wrote: File.slice was first supported in Firefox 4. - Kyle On Tue, Apr 12, 2011 at 1:08 PM, Jian Li jia...@chromium.org wrote: The biggest concern is that this is a breaking change and quite a few web applications have already been using it. As far as I know, File.slice(start, length) has been supported as early as Chrome 6 and Safari 5. Also Firefox 3 is supporting it. How do we communicate with web developers about this breaking change if we decide to make the change? Jian On Tue, Apr 12, 2011 at 11:34 AM, Arun Ranganathan a...@mozilla.comwrote: On 4/12/11 2:24 PM, Jonas Sicking wrote: Hi All, It was recently (yesterday) pointed out to me that we let a bad spec-bug slip through for File.slice. It doesn't match the argument semantics of Array.slice which can be very confusing for developers. In Array.slice the second argument is the index of the last item to be included in the returned slice. In File.slice the second argument is the number of bytes included in the returned slices. In other words, it's Array.slice(start, end), but File.slice(start, length). Additionally, in Array.slice the second argument is optional. File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. So consider this an official request, would chrome be ok with changing the spec here? / Jonas I'm bummed that we collectively let this slip through the cracks, and personally think it's early enough to fix it. But we should also decide how closely to match Array.slice. Should we allow code of the sort file.slice(-80)? Code of that sort is allowed with Array.slice. MDC has good developer docs about what's in Firefox for Array.slice: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/slice Developers may have already discovered file.slice (e.g. see http://hacks.mozilla.org/2011/04/resumeupload/), so fixing this will involve some messaging. -- A*
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 1:57 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 12, 2011 at 1:36 PM, Dmitry Titov dim...@chromium.org wrote: Indeed, it appeared in FF 4 which was shipped end of March, so if it was only FF API, it would be fine to change it since it's only been official for a couple of weeks. However in Chrome this was shipped August 2010, and in Safari sometime in 2010 I think. Oprah seems also support it, although I don't know for how long. This could give plenty of time to developers to start using the API, so I can see how it would give us a pause while considering such a change... Can you provide a testcase that you are using to verify this? I've attached the testcase I'm using and it shows that Safari 5.0.4 does not support File.slice. Will check Opera in a second. It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. Does anyone know of any sites that actually uses File.slice. It's fairly easy to detect how an implementation interprets the File.slice arguments so it should be easy for websites to support both the old and the new behavior. However of course the websites needs to be updated to do so. If someone knows about any websites I can personally take care of contacting them and trying to get them fixed. / Jonas
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote: File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. bb = new BlobBuilder(); bb.append(abcd); bb.getBlob().slice(2, 2).size == 0 is a straightforward feature test, except that Firefox 4 doesn't support BlobBuilder. Is there another way to synchronously retrieve a non-empty Blob to test with? -- Glenn Maynard
Re: [FileAPI] File.slice spec bug
On 4/12/11 5:27 PM, Glenn Maynard wrote: On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote: File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. bb = new BlobBuilder(); bb.append(abcd); bb.getBlob().slice(2, 2).size == 0 is a straightforward feature test, except that Firefox 4 doesn't support BlobBuilder. Is there another way to synchronously retrieve a non-empty Blob to test with? Get a file. input name=foo type=file onchange=alert(this.files[0]);alert(this.files[0].slice); -- Glenn Maynard
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 2:27 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking jo...@sicking.cc wrote: File.slice is currently shipped by Chrome and Firefox 4. I would be fine with fixing this in Firefox 4.0.1, however that only makes sense if the chrome folks are fine with fixing it in their implementation. bb = new BlobBuilder(); bb.append(abcd); bb.getBlob().slice(2, 2).size == 0 is a straightforward feature test, except that Firefox 4 doesn't support BlobBuilder. Is there another way to synchronously retrieve a non-empty Blob to test with? No, but feature testing only when you're about to use the function shouldn't be a problem, no? Another possible solution, and one that I'm leaning towards if other browsers aren't willing to change the .slice() implementation. Is to remove .slice from the spec and instead add something like .createSubBlob(). / Jonas
Re: [FileAPI] File.slice spec bug
On 4/12/11 4:45 PM, Charles Pritchard wrote: We're using ArrayBuffer... It's been through a few changes of its own relating to slice. I think they just went the route of renaming the method. To be clear, here you're referring to the *.subarray method of TypedArray: http://www.khronos.org/registry/typedarray/specs/latest/#7 This does rename something akin to Array.slice. Renaming could be an option, but it seems that slice is a good word for what we're doing to Blobs. -- A*
Re: [FileAPI] File.slice spec bug
On 4/12/11 2:05 PM, Jonas Sicking wrote: It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. The first public build [1] with File.slice was made available last week. It's only been officially supported as of today, however, with the release of 11.10. [1] http://my.opera.com/desktopteam/blog/2011/04/05/stability-gmail-socks - Mike
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote: On 4/12/11 2:05 PM, Jonas Sicking wrote: It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. The first public build [1] with File.slice was made available last week. It's only been officially supported as of today, however, with the release of 11.10. [1] http://my.opera.com/desktopteam/blog/2011/04/05/stability-gmail-socks - Mike As Jian mentioned earlier, File.slice has been available in Chrome since version 6, which was released Sept 2, 2010: http://googlechromereleases.blogspot.com/2010/09/stable-and-beta-channel-updates.html It seems like too much time has passed with this feature baked into Chrome for us to be able to change its behavior now. While I agree that it would be nice for .slice(...) to work the same way in all contexts, I'm just not sure that this is something we can remove from Chrome at this point or even change. I'm very concerned about breaking existing web content. A new name for this function might be nice, but once you do that then I'm not sure that its arguments should really be any different than the current arguments for Blob.slice(). What's wrong with start and length other than that the fact that it differs from the parameters to Array.slice? Why should Blob.createSubBlob favor the argument style of Array.slice over Blob.slice? I guess I'm leaning toward no change at all and just taking our lumps for having created an inconsistent API :-/ -Darin
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 4:25 PM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote: On 4/12/11 2:05 PM, Jonas Sicking wrote: It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. The first public build [1] with File.slice was made available last week. It's only been officially supported as of today, however, with the release of 11.10. [1] http://my.opera.com/desktopteam/blog/2011/04/05/stability-gmail-socks - Mike As Jian mentioned earlier, File.slice has been available in Chrome since version 6, which was released Sept 2, 2010: http://googlechromereleases.blogspot.com/2010/09/stable-and-beta-channel-updates.html It seems like too much time has passed with this feature baked into Chrome for us to be able to change its behavior now. While I agree that it would be nice for .slice(...) to work the same way in all contexts, I'm just not sure that this is something we can remove from Chrome at this point or even change. I'm very concerned about breaking existing web content. A new name for this function might be nice, but once you do that then I'm not sure that its arguments should really be any different than the current arguments for Blob.slice(). What's wrong with start and length other than that the fact that it differs from the parameters to Array.slice? Why should Blob.createSubBlob favor the argument style of Array.slice over Blob.slice? I don't really care much about which style a new function would take. I just think it's a really bad idea to have File.slice and Array.slice which basically do exactly the same thing but take subtly different arguments. I guess I'm leaning toward no change at all and just taking our lumps for having created an inconsistent API :-/ Given that only chrome has supported File.slice up until last week, I doubt there are that many sites that rely on it. Do you know of any? Any non-google ones (and thus would be harder to update)? / Jonas
[FileAPI] BlobBuilder.getBlob should clear the BlobBuilder
Hello All, In the current FileAPI Writer spec a BlobBuilder can be used to build a series of blobs like so: var bb = BlobBuilder(); bb.append(foo); var foo = bb.getBlob(); bb.append(bar); var bar = bb.getBlob(); foo.size; // == 3 bar.size; // == 6 My concern with this pattern is that it seems that one of the primary use cases is to keep a BlobBuilder around for a while to build up a blob over time. A BlobBuilder left around could potentially entrain large amounts of memory. I propose that BlobBuilder.getBlob() clears the BlobBuilder, returning it to an empty state. The current behavior also doesn't seem terribly useful to me (though I'm happy to be convinced otherwise) and be easily replicated on top of the proposed behavior (immediately reappending the Blob that was just retrieved.) Thoughts/comments? - Kyle
Re: [FileAPI] BlobBuilder.getBlob should clear the BlobBuilder
On Tue, Apr 12, 2011 at 3:38 PM, Kyle Huey m...@kylehuey.com wrote: Hello All, In the current FileAPI Writer spec a BlobBuilder can be used to build a series of blobs like so: var bb = BlobBuilder(); bb.append(foo); var foo = bb.getBlob(); bb.append(bar); var bar = bb.getBlob(); foo.size; // == 3 bar.size; // == 6 My concern with this pattern is that it seems that one of the primary use cases is to keep a BlobBuilder around for a while to build up a blob over time. A BlobBuilder left around could potentially entrain large amounts of memory. I propose that BlobBuilder.getBlob() clears the BlobBuilder, returning it to an empty state. The current behavior also doesn't seem terribly useful to me (though I'm happy to be convinced otherwise) and be easily replicated on top of the proposed behavior (immediately reappending the Blob that was just retrieved.) Thoughts/comments? - Kyle If you don't have a use for a current behavior, you can always just drop the BlobBuilder as soon as you're done with it, and it'll get collected. I think that's simpler and more intuitive than having it clear itself, which is a surprise in an operation that looks read-only. In the other case, where you actually want the append behavior, it's faster and simpler not to have to re-append a blob you've just pulled out of it. Eric
Re: [FileAPI] File.slice spec bug
Darin's position is leaning toward not breaking compatibility with what Chrome has shipped for a while. That's one consideration. It can't be the only consideration, or there's no point having a discussion and whatever Chrome ships first is an instant standard. When we talked to Kenneth Arnold of Google about a typed array method that was more subtly misnamed slice, he quickly worked with other WebGL folks to rename it to subarray. That in spite of some support for the typed array slice method having shipped in some beta releases (at least; not sure if any final releases supported slice). The subtler differences between typed array's subarray (formerly named slice) and JS's Array slice: (a) The subarray method returns a view of mutable ArrayBuffer data, its elements alias the elements of the typed array from which it came. This is the big reason to avoid using slice. (b) While subarray takes (start, end) parameters and allows end to be omitted; and it handles negative indexes; it does not allow start to be omitted too, whereas JS (after Python) does. http://www.khronos.org/registry/typedarray/specs/latest/ http://www.khronos.org/webgl/public-mailing-list/archives/1102/msg00028.html The DOM is full of crazy inconsistency from insta-standards in the mid-'90s, starting with my DOM level 0 work. That is not a good pattern to repeat now that we have more balanced market actors and the benefits of hindsight. We should try to agree on less inconsistent APIs and prototype them, but no single prototype implementation can create a standard. Only interoperable de-facto standards can do that. At this point we need to be completely concrete, no leaning one way or another: 0. Do nothing. 1. Should we change slice, possibly breaking Chrome-only content that detects it by name but does not test its functionality? 2. Should we rename slice, allowing Chrome to keep the old name for a while if it must? Solution 0 just leaves a noxious inconsistency on two counts: length not end as the second parameter, the lack of negative index support. Is there another difference with Array slice (which comes from Python and is in Ruby too)? What about optionality of the arguments? Doing 1 is simpler for future users who don't have to deal with the legacy that Chrome-only content might represent. Doing 2 avoids breaking any such legacy, but may increase the cognitive load for users who see the legacy and the new renamed method. What about negative indexes? Is there time to spec and implement these per Python/JS/Ruby? Without negative index support, the case for 2 is stronger again. If Blob slice returns an aliasing view onto mutable data instead of a copy, just as typed arrays' subarray method does, then the case for 2 is extremely strong. I do not see any mutator methods in http://dev.w3.org/2006/webapi/FileAPI/, but with the typed array precedent I didn't want to assume. I favor 1 if negative index and optional argument semantics can be made to match precedent, and assuming no way to mutate shared Blob/sub-Blob data. If not, I suggest 2, with subBlob or a better name -- that one hurts due to the shifted-B, but subblob seems also bad for the run-together bb. /be
Re: [FileAPI] File.slice spec bug
It can be more then it looks though - if site detects File.slice and then uses it, it will automatically pick up FF and Opera now because the method now is defined. But the code is assuming the 'length' semantics of the second parameter. So if the site is using recommended method of detection, the fact that it is only Chrome that implemented it so far does not necessarily reduce the scope of compat issue. For example, there is an open-source JS library that uses file.slice: http://www.plupload.com/index.php. They detect it by checking File.prototype.slice. So essentially, they are cross-browser. File.slice is probably going to be used by minority of advanced web developers (for offline apps or async upload kind of scenarios) and those care less about similarity with string.slice() perhaps. They routinely fight the subtle differences between browsers though. They already do detection for slice(), if FF will implement some newSlice(begin, end) - they probably will just add another line to detection, a piece of different math and curse the browser developers :-) On Tue, Apr 12, 2011 at 4:55 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 12, 2011 at 4:25 PM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote: On 4/12/11 2:05 PM, Jonas Sicking wrote: It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. The first public build [1] with File.slice was made available last week. It's only been officially supported as of today, however, with the release of 11.10. [1] http://my.opera.com/desktopteam/blog/2011/04/05/stability-gmail-socks - Mike As Jian mentioned earlier, File.slice has been available in Chrome since version 6, which was released Sept 2, 2010: http://googlechromereleases.blogspot.com/2010/09/stable-and-beta-channel-updates.html It seems like too much time has passed with this feature baked into Chrome for us to be able to change its behavior now. While I agree that it would be nice for .slice(...) to work the same way in all contexts, I'm just not sure that this is something we can remove from Chrome at this point or even change. I'm very concerned about breaking existing web content. A new name for this function might be nice, but once you do that then I'm not sure that its arguments should really be any different than the current arguments for Blob.slice(). What's wrong with start and length other than that the fact that it differs from the parameters to Array.slice? Why should Blob.createSubBlob favor the argument style of Array.slice over Blob.slice? I don't really care much about which style a new function would take. I just think it's a really bad idea to have File.slice and Array.slice which basically do exactly the same thing but take subtly different arguments. I guess I'm leaning toward no change at all and just taking our lumps for having created an inconsistent API :-/ Given that only chrome has supported File.slice up until last week, I doubt there are that many sites that rely on it. Do you know of any? Any non-google ones (and thus would be harder to update)? / Jonas
Re: [FileAPI] File.slice spec bug
I just realized that string.slice also follows the pattern of Array.slice. I really think we need to fix this to not cause a very unfortunate inconsistency. I'd rather take some short term pain rather than foist this upon developers forever. We're also all guilty of releasing unprefixed code for a spec that isn't even in last call yet. That leaves us with the two choices of removing File.slice or fixing it. / Jonas On Tue, Apr 12, 2011 at 6:16 PM, Dmitry Titov dim...@chromium.org wrote: It can be more then it looks though - if site detects File.slice and then uses it, it will automatically pick up FF and Opera now because the method now is defined. But the code is assuming the 'length' semantics of the second parameter. So if the site is using recommended method of detection, the fact that it is only Chrome that implemented it so far does not necessarily reduce the scope of compat issue. For example, there is an open-source JS library that uses file.slice: http://www.plupload.com/index.php. They detect it by checking File.prototype.slice. So essentially, they are cross-browser. File.slice is probably going to be used by minority of advanced web developers (for offline apps or async upload kind of scenarios) and those care less about similarity with string.slice() perhaps. They routinely fight the subtle differences between browsers though. They already do detection for slice(), if FF will implement some newSlice(begin, end) - they probably will just add another line to detection, a piece of different math and curse the browser developers :-) On Tue, Apr 12, 2011 at 4:55 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 12, 2011 at 4:25 PM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote: On 4/12/11 2:05 PM, Jonas Sicking wrote: It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. The first public build [1] with File.slice was made available last week. It's only been officially supported as of today, however, with the release of 11.10. [1] http://my.opera.com/desktopteam/blog/2011/04/05/stability-gmail-socks - Mike As Jian mentioned earlier, File.slice has been available in Chrome since version 6, which was released Sept 2, 2010: http://googlechromereleases.blogspot.com/2010/09/stable-and-beta-channel-updates.html It seems like too much time has passed with this feature baked into Chrome for us to be able to change its behavior now. While I agree that it would be nice for .slice(...) to work the same way in all contexts, I'm just not sure that this is something we can remove from Chrome at this point or even change. I'm very concerned about breaking existing web content. A new name for this function might be nice, but once you do that then I'm not sure that its arguments should really be any different than the current arguments for Blob.slice(). What's wrong with start and length other than that the fact that it differs from the parameters to Array.slice? Why should Blob.createSubBlob favor the argument style of Array.slice over Blob.slice? I don't really care much about which style a new function would take. I just think it's a really bad idea to have File.slice and Array.slice which basically do exactly the same thing but take subtly different arguments. I guess I'm leaning toward no change at all and just taking our lumps for having created an inconsistent API :-/ Given that only chrome has supported File.slice up until last week, I doubt there are that many sites that rely on it. Do you know of any? Any non-google ones (and thus would be harder to update)? / Jonas
Re: [FileAPI] File.slice spec bug
Dmitry Titov dim...@chromium.org wrote: It can be more then it looks though - if site detects File.slice and then uses it, it will automatically pick up FF and Opera now because the method now is defined. FF and Opera just added File slice support, IIUC. For Firefox at least we are willing to change things for 4.0.1 or an automatic patch release. Down the road, if we change to a better name, this episode will fade away and devs won't have to remember it or (more important) learn about it. But we're late. You're right. I wish I caught this before we shipped Firefox 4. It smells like yet another inconsistent or badly named web API _fait accompli_, and perhaps it is (a _fait accompli_, I mean; it's badly named in any event). However: the Chrome (or any one vendor) shipped it so it can't change virtual-rule put forth with leaning-toward fuzziness is not going to fly in a modern, post-duopoly, multi-vendor browser market. We need to agree on specs and then prototype them -- and then if some bug is found later, be able to change spec and implementations before the spec goes to REC. IINM File API is still a WD so in theory we can still do this if we so choose. /be
Re: [FileAPI] File.slice spec bug
I strongly prefer a rename as done with subarray in the typed arrays spec. It's straightforward on feature detection, as it's just an if [exists] statement. On Apr 12, 2011, at 7:03 PM, Jonas Sicking jo...@sicking.cc wrote: I just realized that string.slice also follows the pattern of Array.slice. I really think we need to fix this to not cause a very unfortunate inconsistency. I'd rather take some short term pain rather than foist this upon developers forever. We're also all guilty of releasing unprefixed code for a spec that isn't even in last call yet. That leaves us with the two choices of removing File.slice or fixing it. / Jonas On Tue, Apr 12, 2011 at 6:16 PM, Dmitry Titov dim...@chromium.org wrote: It can be more then it looks though - if site detects File.slice and then uses it, it will automatically pick up FF and Opera now because the method now is defined. But the code is assuming the 'length' semantics of the second parameter. So if the site is using recommended method of detection, the fact that it is only Chrome that implemented it so far does not necessarily reduce the scope of compat issue. For example, there is an open-source JS library that uses file.slice: http://www.plupload.com/index.php. They detect it by checking File.prototype.slice. So essentially, they are cross-browser. File.slice is probably going to be used by minority of advanced web developers (for offline apps or async upload kind of scenarios) and those care less about similarity with string.slice() perhaps. They routinely fight the subtle differences between browsers though. They already do detection for slice(), if FF will implement some newSlice(begin, end) - they probably will just add another line to detection, a piece of different math and curse the browser developers :-) On Tue, Apr 12, 2011 at 4:55 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Apr 12, 2011 at 4:25 PM, Darin Fisher da...@chromium.org wrote: On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor miketa...@gmail.com wrote: On 4/12/11 2:05 PM, Jonas Sicking wrote: It appears that Opera too implements File.slice. Would be great to know for how long it's been implemented. The first public build [1] with File.slice was made available last week. It's only been officially supported as of today, however, with the release of 11.10. [1] http://my.opera.com/desktopteam/blog/2011/04/05/stability-gmail-socks - Mike As Jian mentioned earlier, File.slice has been available in Chrome since version 6, which was released Sept 2, 2010: http://googlechromereleases.blogspot.com/2010/09/stable-and-beta-channel-updates.html It seems like too much time has passed with this feature baked into Chrome for us to be able to change its behavior now. While I agree that it would be nice for .slice(...) to work the same way in all contexts, I'm just not sure that this is something we can remove from Chrome at this point or even change. I'm very concerned about breaking existing web content. A new name for this function might be nice, but once you do that then I'm not sure that its arguments should really be any different than the current arguments for Blob.slice(). What's wrong with start and length other than that the fact that it differs from the parameters to Array.slice? Why should Blob.createSubBlob favor the argument style of Array.slice over Blob.slice? I don't really care much about which style a new function would take. I just think it's a really bad idea to have File.slice and Array.slice which basically do exactly the same thing but take subtly different arguments. I guess I'm leaning toward no change at all and just taking our lumps for having created an inconsistent API :-/ Given that only chrome has supported File.slice up until last week, I doubt there are that many sites that rely on it. Do you know of any? Any non-google ones (and thus would be harder to update)? / Jonas
Re: More questions about contextual reference nodes
Lachlan Hunt: I reviewed WebIDL again, and I think I've started to understand the difference between sequenceT and T[] now. As I understand it, the algorithm to convert an ECMAScript object to an IDL sequence should work with any object that has a length property and indexed values containing Node objects. That is true for an Array of Nodes, NodeList, HTMLCollection and the above JQuery case, they can all be handled in the same way. Yes, that’s right. This seems to differ from the algorithm given for T[], which requires that the object be either an array host object or a native object, which would not handle the JQuery case. The sequenceT type seems more generic than that as the algorithm seems to be able to support any object with a length and indexed properties. Why wouldn’t it handle the JQuery case? Isn’t it a native object? I've updated and simplified the spec to handle the above case using the parameter sequenceNode. I still need to update the prose to say that while the collections may contain any Node, only Element nodes are added to the list of contextual reference elements. But the following cases should all work. Agreed, that works, according to Web IDL’s currenty definition of overloading. The issue of whether you want to throw eagerly if passed an array with elements of the wrong type to an operation taking a sequenceT is an interesting one, which probably still could bear some more discussion. On the one hand, it helps ensure implementations don’t diverge based on when during the course of running the method these elements from the sequence are looked up. I could mean a lot of useless checks, though. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Support for matchesSelector()
On 4/10/11 4:32 AM, Lachlan Hunt wrote:
The same issue will occur with any new selector that gets added in the
future. The only real difference between this and any other is that
support for :scope will inherently imply refElement support.
Indeed.
I'm not entirely sure what you consider to be obvious benefits. Do you
think authors should be able to do this?
if (el.matchesSelector) {
// Confirms that browser supports :scope and refNodes
That would be nice, yes.
Are there any other obvious benefits that I may be missing?
I don't think so.
I'm fine with waiting till we're very sure, and I hope we can get to
that stage soon. Do you have any suggestions for how we could lower the
risk of unforeseen problems in the future?
I think we're doing that right now. ;) In particular, discussing how
that argument should work before actually implementing it.
I'd love for other UA vendors to chime in here if they've looked at this.
I think it makes sense for matchesSelector and querySelector to use a
common API design and accept the same parameters.
Yes, agreed.
1. Leave the spec as is and implement with the refElements parameter.
This has the advantage of keeping the API simple.
Modulo defining the exact behavior of refElements, yes.
2. Create a more generic extension mechanism, such as an options
parameter.
My gut feeling is that that's overdesign in this case. But if we think
we'll want to add namespace stuff soon (or at least at some point),
maybe worth thinking about.
This would allow for easier extensions in the future where the method
just ignores unknown options, but at the expense of a more complex
syntax. It's not clear what the chances are of wanting more extensions,
nor if it's worth the complexity cost to go down such a path now merely
as a precaution.
Indeed.
2a. Initially do what the spec says (#1), and then if such extensions
are wanted in the future, overload the method in a backwards compatible
way to accept both an refElements or an options object (#2). That is, if
adding a 3rd parameter or introducing a new method is undesirable.
This seems like a good plan.
3. Introduce new methods every time we want to add a new feature.
Let's not do that.
-Boris
Re: More questions about contextual reference nodes
On 4/10/11 4:30 AM, Lachlan Hunt wrote: Would it be useful, and is it possible to define the refElements parameter to accept any object that contains a .length and indexed properties, just like a JQuery object? Looks like this already got answered, but yes, sequenceNode should make that work. OK. Then I'm not sure what the practical difference between the Element[] or sequenceElement would be then, nor which one to use. I'm not either. That's why Cameron is cced. If using webidl array/sequence types, that would help with the iteration, but not the large allocation. OK, does that mean it's not really worth defining like that? I think this is an edge case we shouldn't worry about. Perhaps famous last words. Yes, I just checked and I think you may be right. The WebIDL algorithm to convert an ECMAScript array to an IDL value of type T[] iterates the array and says: While i n: Let x be the result of calling [[Get]] on V with property name ToString(i). Set Ei to be the result of converting x to an IDL value of type T. This step can throw (as part of the conversion process defined for converting to type T); seems like that would involve throwing from the whole algorithm. -Boris
Re: More questions about contextual reference nodes
On 4/10/11 12:02 PM, Lachlan Hunt wrote: I've updated and simplified the spec to handle the above case using the parameter sequenceNode. I still need to update the prose to say that while the collections may contain any Node, only Element nodes are added to the list of contextual reference elements. Looks like you now made that change too. The new text looks good to me. Thanks! What Firefox 5 will ship doesn't match this yet (because we don't actually have a sane webidl implementation yet), but that's why we're prefixing... ;) -Boris
Re: More questions about contextual reference nodes
Lachlan Hunt: OK. Then I'm not sure what the practical difference between the Element[] or sequenceElement would be then, nor which one to use. Boris Zbarsky: I'm not either. That's why Cameron is cced. If you are choosing between those two for the type of an argument, and you don’t have any way of getting an actual array host object Element[] (so will be passing in a native Array, or a NodeList, or…), and hence the method cannot cause a reference to a passed-in Element[] object to be kept, then the only difference is that with Element[] you can distinguish between null and an array of length 1, while with sequenceElement you can’t. While i n: Let x be the result of calling [[Get]] on V with property name ToString(i). Set Ei to be the result of converting x to an IDL value of type T. This step can throw (as part of the conversion process defined for converting to type T); seems like that would involve throwing from the whole algorithm. Yep. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [FileAPI] BlobBuilder.getBlob should clear the BlobBuilder
On 04/12/2011 05:33 PM, Eric Uhrhane wrote: On Tue, Apr 12, 2011 at 3:38 PM, Kyle Hueym...@kylehuey.com wrote: Hello All, In the current FileAPI Writer spec a BlobBuilder can be used to build a series of blobs like so: var bb = BlobBuilder(); bb.append(foo); var foo = bb.getBlob(); bb.append(bar); var bar = bb.getBlob(); foo.size; // == 3 bar.size; // == 6 My concern with this pattern is that it seems that one of the primary use cases is to keep a BlobBuilder around for a while to build up a blob over time. A BlobBuilder left around could potentially entrain large amounts of memory. I propose that BlobBuilder.getBlob() clears the BlobBuilder, returning it to an empty state. The current behavior also doesn't seem terribly useful to me (though I'm happy to be convinced otherwise) and be easily replicated on top of the proposed behavior (immediately reappending the Blob that was just retrieved.) Thoughts/comments? - Kyle If you don't have a use for a current behavior, you can always just drop the BlobBuilder as soon as you're done with it, and it'll get collected. I think that's simpler and more intuitive than having it clear itself, which is a surprise in an operation that looks read-only. I agree. getBlob() sounds very much like read-only operation. If there is a use case for clearing BlobBuilder, the method should be called takeBlob() or some such. -Olli In the other case, where you actually want the append behavior, it's faster and simpler not to have to re-append a blob you've just pulled out of it. Eric
Re: [FileAPI] File.slice spec bug
On Tue, Apr 12, 2011 at 5:59 PM, Brendan Eich bren...@mozilla.org wrote: Darin's position is leaning toward not breaking compatibility with what Chrome has shipped for a while. That's one consideration. It can't be the only consideration, or there's no point having a discussion and whatever Chrome ships first is an instant standard. Agreed. I certainly don't assert that whatever Chrome ships first should be regarded as standard. Our rapid release schedule depends on platform features beginning life with a vendor prefix. I believe that we goofed in this case by not vendor-prefixing the slice method. More on this below... When we talked to Kenneth Arnold of Google about a typed array method that was more subtly misnamed slice, he quickly worked with other WebGL folks to rename it to subarray. That in spite of some support for the typed array slice method having shipped in some beta releases (at least; not sure if any final releases supported slice). s/Kenneth Arnold/Kenneth Russell/ WebGL was disabled by default (hidden behind a flag) up until Chrome 9. It was trivial to change the API from the point of view of Chrome prior to it coming out from behind a flag. The subtler differences between typed array's subarray (formerly named slice) and JS's Array slice: (a) The subarray method returns a view of mutable ArrayBuffer data, its elements alias the elements of the typed array from which it came. This is the big reason to avoid using slice. (b) While subarray takes (start, end) parameters and allows end to be omitted; and it handles negative indexes; it does not allow start to be omitted too, whereas JS (after Python) does. http://www.khronos.org/registry/typedarray/specs/latest/ http://www.khronos.org/webgl/public-mailing-list/archives/1102/msg00028.html The DOM is full of crazy inconsistency from insta-standards in the mid-'90s, starting with my DOM level 0 work. That is not a good pattern to repeat now that we have more balanced market actors and the benefits of hindsight. We should try to agree on less inconsistent APIs and prototype them, but no single prototype implementation can create a standard. Only interoperable de-facto standards can do that. At this point we need to be completely concrete, no leaning one way or another: 0. Do nothing. 1. Should we change slice, possibly breaking Chrome-only content that detects it by name but does not test its functionality? 2. Should we rename slice, allowing Chrome to keep the old name for a while if it must? Solution 0 just leaves a noxious inconsistency on two counts: length not end as the second parameter, the lack of negative index support. Is there another difference with Array slice (which comes from Python and is in Ruby too)? What about optionality of the arguments? Doing 1 is simpler for future users who don't have to deal with the legacy that Chrome-only content might represent. Doing 2 avoids breaking any such legacy, but may increase the cognitive load for users who see the legacy and the new renamed method. What about negative indexes? Is there time to spec and implement these per Python/JS/Ruby? Without negative index support, the case for 2 is stronger again. If Blob slice returns an aliasing view onto mutable data instead of a copy, just as typed arrays' subarray method does, then the case for 2 is extremely strong. Blobs are views on immutable data. WebKit's implementation will reject reads on a Blob, which points to a file that has since been modified. (This should be part of the spec if it is not.) I do not see any mutator methods in http://dev.w3.org/2006/webapi/FileAPI/, but with the typed array precedent I didn't want to assume. I favor 1 if negative index and optional argument semantics can be made to match precedent, and assuming no way to mutate shared Blob/sub-Blob data. If not, I suggest 2, with subBlob or a better name -- that one hurts due to the shifted-B, but subblob seems also bad for the run-together bb. /be One option we can consider is to rename Blob.slice to Blob.webkitSlice and adopt the newer arguments. I think we would want to similarly vendor-prefix BlobBuilder and FileReader as those too are non-standard. This change runs just as much risk of breaking Chrome-specific content; however, the failure mode (absence of a method) should be easier for apps to cope with. I'm not stating that we will do this yet. I'm just proposing it as another approach to consider. I'll discuss this idea with others on the team tomorrow. By the way, I'm not too concerned about having to fix Google web apps. I'm much more concerned about third-party, Chrome-specific content available as either apps or extensions through the Chrome app store. It is hard to grep for instances of Blob.slice!! -Darin
Re: More questions about contextual reference nodes
Cameron McCormack: then the only difference is that with Element[] you can distinguish between null and an array of length 1, while with sequenceElement you can’t. Length 0, not 1. -- Cameron McCormack ≝ http://mcc.id.au/
