On Mon, Jun 2, 2014 at 10:16 AM, Justin Novosad <ju...@google.com> wrote:
> On Sat, May 31, 2014 at 1:46 PM, Glenn Maynard <gl...@zewt.org> wrote: > > > On Fri, May 30, 2014 at 1:25 PM, Justin Novosad <ju...@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 That's implementation cost to you :-) Now we need to convince the other vendors. Do they want it, want more, want it in a different way? Then it needs to be documented. How can authors discover that this is supported? How can it be poly-filled? > >>> 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 > > > > >