Re: WebP, anyone using it?

> On Oct 16, 2012, at 10:45 AM, Matthew Wilcox <mail@matthewwilcox.com> wrote:
> 
>> Sorry everyone, I keep forgetting in Gmail to "Reply All" instead of "Reply" and therefor stuff doesn't get on the list...
>> 
>> Anyway:
>> 
>> I find it odd, and somewhat contradictory, that there's an argument for the stance on negotiating *filetype* being "do it on the server" when the existence of <picture> at all is because we decided that we should negotiate *file URI* on the client side. How does that square up? Why are these different?
> 
> Just to offer some insight on this, given that I work on a product (Typekit) that is all about content negotiation, one reason I'm a strong proponent of doing this in the client is that server-side techniques can become very difficult — and very costly — at scale. I wrote a post for our blog last year about why we use JavaScript-based client-side content negotiation for web fonts instead of doing it on the server: http://blog.typekit.com/2011/08/11/better-web-font-loading-with-javascript/
> 
> The short version is: commercial CDNs either don't offer a way to do this on the server at scale, or will do it but only as a custom deployment that can be very expensive at virtually any scale. Google can do it server-side for their Web Fonts API because they're Google, and have their own, very robust CDN infrastructure. We initially did it client side because we were on a startup's budget, however using JavaScript we're also able to target browser edge cases (such as the IE rendering mode) that aren't reliably detectable with just a UA string.
> 
> I practically guarantee you that if responsive images don't have native content negotiation in the client, adding a JS-based solution is one of the first things I'd need in order to recommend using responsive images at scale.
> 
> 
>> I'm not following the PNG argument. How many years did it take to get usable Alpha PNG after the PNG spec came out? 6? 7? Have any of you used animated PNG's in a web browser recently? No? Why are you still using GIF for this, when the PNG spec allows for animation? It's because it's not supported properly. Even after many years. Why isn't it supported properly? Because no one uses it. Why? ... Aaaand there we go with the chicken and egg again.
>> 
>> PNG is not a success. It's an illustration of how incredibly long it takes for a file format to get *partial* support in a broad base of browsers. Being able to allocate fallback types should help alleviate this.

That's interesting :) It doesn't explain to me why some in the thread are arguing for a server-side mechanism for dealing with Filetype negotiation though.  If anything it argues that we explicitly should not be doing that.

Again, the reason <picture> was decided as preferable was the assumption that server-side negotiation was "too hard" and there are currently problems with the scaling factor. If that's the case, then we should also be chasing client side solutions for file-type negotiation, not just URI resource negotiation.

On a seperate note: while I see there is clearly a problem at the moment with scaling server-side; that's because this stuff is rare now. Because it's not a standard thing now. Won't that cost problem go away once it's a common option? I do not want us to throw out a good, powerful, solution just because there are current problems for a small (yes, small) use case (i.e., site's that run at huge scale). The majority of sites on the web aren't Adobe.com.