- From: Justin Novosad <junov@google.com>
- Date: Mon, 2 Jun 2014 13:16:34 -0400
- To: Glenn Maynard <glenn@zewt.org>
- Cc: whatwg <whatwg@lists.whatwg.org>, Robert O'Callahan <robert@ocallahan.org>, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
On Sat, May 31, 2014 at 1:46 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Fri, May 30, 2014 at 1:25 PM, Justin Novosad <junov@google.com> wrote: > > I think this proposal falls short of enshrining. The cost of adding this >> feature is minuscule. >> > > I don't think the cost is ever really miniscule. > https://codereview.chromium.org/290893002 > >> >> >>> True, you'd never want to use toDataURL with a compression operation >>> that takes many seconds ((or even tenths of a second) to complete, and data >>> URLs don't make sense for large images in the first place. It makes sense >>> for toBlob(), though, and having the arguments to toBlob and toDataURL be >>> different seems like gratuitous inconsistency. >>> >> >> Yes, toBlob is async, but it can still be polyfilled. >> > > (I'm not sure how this replies to what I said--this feature makes more > sense for toBlob than toDataURL, but I wouldn't add it to toBlob and not > toDataURL.) > What I meant is that I agree that adding the compression argument to toBlob answers the need for an async API (being synchronous was one of the criticisms of the original proposal, which only mentioned toDataURL). However, this does not address the other criticism that we should not add features to toDataURL (and by extension to toBlob) because the new functionality could implemented more or less efficiently in JS. > -- > Glenn Maynard > >
Received on Monday, 2 June 2014 17:16:59 UTC