Use Blob constructor and ArrayBufferView about zip.js HOT 14 CLOSED

I added the implementation to support ArrayBufferView objects in Blob constructor and changed feature tests order in blobSlice function. I won't fix the feature tests order of Blob vs BlobBuilder constructors because it is more reliable to detect the BlobBuilder constructor than the Blob constructor (see issue #16).

from zip.js.

This is a reliable feature detect for Blob():

function hasBlobConstructor() {
  try {
    return !!new Blob();
  } catch(e) {
    return false;
  }
}

It's also what Modernizr uses.

BTW, every stable Modernizr browser now supports Blob(), so you could do away with BlobBuilder:
https://developer.mozilla.org/en-US/docs/DOM/Blob

from zip.js.

Actually I didn't want to use a try/catch. Maybe the removal of BlobBuilder is the good choice, so I won't need any feature test.

from zip.js.

I would recommend switching from BlobBuilder to Blob very soon. Chrome Canary has officially removed support for BlobBuilder, i.e. it's completely gone. I give it about a couple months or so before that change propagates through the Stable releases as well.

from zip.js.

zip.js does support both Blob and BlobBuilder interfaces to build Blob objects.

from zip.js.

I'm sorry, you are absolutely correct! That's what I get for just quickly scanning the master branch. Updated to the latest version of your library and sure enough it works perfectly. Thanks!

from zip.js.

I have just reviewed the code and yes, it support Blob constructor, but this check

typeof BlobBuilder == "undefined"

show it's done bad. Since it's a polyfill, the good way to do it is "future proof", checking for the new API and build it using old concepts (develop a Blob constructor using BlobBuilder) instead of checking for the deprecated API and build the old one (develop a BlobBuilder from a Blob constructor) just to don't modify the base code as it's being done currently. If required, I would be able to upgrade the code and send the pull request.

from zip.js.

You're right, but I'm wondering if I shouldn't simply remove the support for the old BlobBuilder API.

from zip.js.

It's not about remove the support for BlobBuilder, it's about change the code to use Blob constructor natively and use a polyfill with BlobBuilder when native Blob constructor is not available, and deprecate it. This way, removing the support for the deprecated BlobBuilder is as simple as remove the polyfill without needing to inspect all the code.

from zip.js.

But I don't want to include polyfills in zip.js. From my point of view, polyfills should be outside of zip.js. Then the developper can choose if he wants to include it or not.

from zip.js.

Interesting point... I think you can have the polyfill instead of your current checking code, or at an external file (Blob.js) or directly as an external project, so user can decide to add them if required.

By the way, your BlobBuilder implementation is somewhat a hardcoded retro-polyfill... ;-)

from zip.js.

I know that my BlobBuilder implementation is a retro-polyfill :p. It has been coded quite urgently because WebKitBlobBuilder has been totally removed from Chromium 24+.

from zip.js.

Then since BlobBuilder is being not only deprecated but also removed I believe the best move is to move fordward to the new specification with Blob constructor, and maybe add a polyfill as an external file or project for older browsers, but I wouldn't think too much about it...

from zip.js.

Yep, we totally agree :)

from zip.js.