Re: [whatwg] Proposal: toDataURL “image/png” compression control

On Mon, Jun 2, 2014 at 10:16 AM, Justin Novosad <junov@google.com> wrote:

> 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


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
> >
> >
>

Received on Monday, 2 June 2014 17:49:46 UTC