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

Re: [FileAPI] File.slice spec bug

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 13 Apr 2011 10:55:14 -0700
Message-ID: <BANLkTinz-BMM36PETXeQdONMBaAQ7ecEuQ@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: Brendan Eich <brendan@mozilla.org>, public-webapps@w3.org
On Tue, Apr 12, 2011 at 11:50 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Apr 12, 2011 at 10:01 PM, Darin Fisher <darin@chromium.org> wrote:
>> On Tue, Apr 12, 2011 at 5:59 PM, Brendan Eich <brendan@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!!
> Removing Blob.slice and replacing it with Blob.prefixSlice for now
> sounds like a good idea. Once websites have migrated over to it we can
> re-introduce Blob.slice with the correct arguments.
> I'll look into what I can do for Firefox 4.0.1 tomorrow.

Things are looking good for taking this change for Firefox 4.0.1!

So to be clear, here is the plan I propose:

Make implementations add a Blob.prefixSlice which uses the same
semantics as Array.slice and String.slice. Including support for
negative indexes and end being optional.

Change the spec to use the same semantics as Array.slice/String.slice.
Add a note to the spec describing the situation. I.e. that authors
should expect the function to be prefixed for now and that unprefixed
functions might be using bad semantics.

In a few months when we feel more comfortable with pages having gotten
updated, we'll add back File.slice but with Array.slice/String.slice
semantics. There is no real hurry to do this.

/ Jonas
Received on Wednesday, 13 April 2011 17:56:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:31 UTC