On Fri, May 30, 2014 at 1:25 PM, Justin Novosad <ju...@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 <rob...@ocallahan.org> wrote: > On Sat, May 31, 2014 at 3:44 AM, Justin Novosad <ju...@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
