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

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Sat, 31 May 2014 14:00:29 -0700
Message-ID: <CAGN7qDCbgSqM_7s0otAG_T0McfB2c5BcVd10Bt9j_ofaDaF7mA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Justin Novosad <junov@google.com>, whatwg <whatwg@lists.whatwg.org>, Robert O'Callahan <robert@ocallahan.org>, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
On Sat, May 31, 2014 at 10:46 AM, 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.
>
>
> >
> >
> >> 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.)
>
>
> On Sat, May 31, 2014 at 7:44 AM, Robert O'Callahan <robert@ocallahan.org>
> wrote:
>
> > On Sat, May 31, 2014 at 3:44 AM, Justin Novosad <junov@google.com>
> wrote:
> >
> >> My point is, we need a proper litmus test for the "just do it in script"
> >> argument because, let's be honnest, a lot of new features being added to
> >> the Web platform could be scripted efficiently, and that does not
> >> necessarily make them bad features.
> >>
> >
> > Which ones?
> >
>
> The ones that are used so frequently that providing a standard API for them
> benefits everyone, by avoiding the fragmentation of everyone rolling their
> own.  For example, URL parsing and manipulation, and lots of DOM interfaces
> like element.closest(), element.hidden and element.classList.  (Cookies are
> another one that should be in this category; document.cookie isn't a sane
> API without a wrapper.)
>
> This isn't one of those, though.
>

roc was asking which NEW feature is being added that can be done in script.
Received on Saturday, 31 May 2014 21:01:07 UTC

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