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

Re: [FileAPI] File.slice spec bug

From: Dmitry Titov <dimich@chromium.org>
Date: Tue, 12 Apr 2011 18:16:54 -0700
Message-ID: <BANLkTikrc6cdMeV4ky4i2f2StWDYZBbHfQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: 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>
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 01:17:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT