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

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

From: Justin Novosad <junov@google.com>
Date: Mon, 2 Jun 2014 13:16:34 -0400
Message-ID: <CABpaAqScFuPjm4JRw5uu9XDG+QwwN45q3q6J-zGgsr5aeUf03A@mail.gmail.com>
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

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