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 <dhtmlkitc...@gmail.com> wrote:

> On 3/21/15, Jake Archibald <jaffathec...@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

Reply via email to