Re: [FileAPI] File.slice spec bug

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!!

-Darin