W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2014

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 2 Jun 2014 10:49:21 -0700
Message-ID: <CAGN7qDBGzrdaoTfHmSTTpbNQ5ULh3g3TUsLV3=pXBLbxYnzASQ@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: whatwg <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, Robert O'Callahan <robert@ocallahan.org>, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
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

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