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

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.

-- 
Glenn Maynard

Received on Saturday, 31 May 2014 17:47:12 UTC