W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2015

Re: [whatwg] Canvas image to blob/dataurl within Worker

From: Jake Archibald <jaffathecake@gmail.com>
Date: Mon, 23 Mar 2015 07:55:54 +0000
Message-ID: <CAJ5xic9FTtChdEDY9Zveab+ygEfF04UN8S_VBTfZEB3sm-ZvkA@mail.gmail.com>
To: Garrett Smith <dhtmlkitchen@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, Rik Cabanier <cabanier@gmail.com>, robert@ocallahan.org
I'd rather Firefox did a small hack under hood for compatibility than we
hack the spec with a separate method.

We shouldn't be adding async APIs to browsers that use callbacks. Only one
browser implements the callback version here, and they can maintain compat
easily & remove the callback when usage stats drop off.

On Mon, 23 Mar 2015 07:43 Garrett Smith <dhtmlkitchen@gmail.com> wrote:

> On 3/21/15, Jake Archibald <jaffathecake@gmail.com> wrote:
> > I'd rather we did that by introducing promises to HTMLCanvasElement.
> > Returning a promise from toBlob is easy, making the callback arg optional
> > by checking the type of the first arg is hacky but possible (and is done
> in
> > js libs).
> >
> Overloading with optional middle arguments is hacky,
>
> A different-named method is a better idea than in-place
> transmogrification. Don't change toBlob to be overloaded, create a new
> method, toBlobPromise. IMO.
>
> In JS libs and even in canvas methods, overloading - especially with
> optional middle arguments, causes problems. I went over some of the
> branching complexities of that. Not all, but some (the email was
> already too long and I have other things to do).
>
> https://lists.w3.org/Archives/Public/public-whatwg-archive/
> 2015Mar/0059.html
> --
> Garrett
> @xkit
> ChordCycles.com
> garretts.github.io
> personx.tumblr.com
>
Received on Monday, 23 March 2015 07:56:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:29 UTC