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

Re: [FileAPI] File.slice spec bug

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 12 Apr 2011 14:34:54 -0400
Message-ID: <4DA49B4E.4080206@mozilla.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: Webapps WG <public-webapps@w3.org>, Eric Uhrhane <ericu@google.com>, Dmitry Titov <dimich@chromium.org>
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


Code of that sort is allowed with Array.slice.

MDC has good developer docs about what's in Firefox for 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*
Received on Tuesday, 12 April 2011 18:35:24 UTC

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