W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [FileAPI] File.slice spec bug

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 12 Apr 2011 19:16:36 -0700
Message-Id: <2EF47348-AF08-4A15-B8B2-F5AD787EB171@jumis.com>
Cc: Dmitry Titov <dimich@chromium.org>, Darin Fisher <darin@chromium.org>, Mike Taylor <miketaylr@gmail.com>, Kyle Huey <me@kylehuey.com>, Jian Li <jianli@chromium.org>, "arun@mozilla.com" <arun@mozilla.com>, Maciej Stachowiak <mjs@apple.com>, Web Applications Working Group WG <public-webapps@w3.org>, Eric Uhrhane <ericu@google.com>
To: Jonas Sicking <jonas@sicking.cc>
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 <jonas@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 <dimich@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 <jonas@sicking.cc> wrote:
>>> On Tue, Apr 12, 2011 at 4:25 PM, Darin Fisher <darin@chromium.org> wrote:
>>>> On Tue, Apr 12, 2011 at 4:02 PM, Mike Taylor <miketaylr@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
Received on Wednesday, 13 April 2011 02:17:12 UTC

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