W3C home > Mailing lists > Public > public-respimg@w3.org > October 2012

Re: WebP, anyone using it?

From: Marcos Caceres <w3c@marcosc.com>
Date: Tue, 16 Oct 2012 19:00:14 +0100
To: David Demaree <ddemaree@adobe.com>
Cc: Matthew Wilcox <mail@matthewwilcox.com>, Tom Lane <tom@tomlane.me>, Peter Gasston <pgasston@gmail.com>, David Newton <david@davidnewton.ca>, François REMY <fremycompany_pub@yahoo.fr>, "public-respimg@w3.org" <public-respimg@w3.org>
Message-ID: <A34C8C650294472FA2784912AB838A03@marcosc.com>
On Tuesday, October 16, 2012 at 6:02 PM, David Demaree wrote:
> On Oct 16, 2012, at 10:45 AM, Matthew Wilcox <mail@matthewwilcox.com (mailto: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/
This is _exactly_ the kind of evidence we are looking for (even if it's fonts, not images). We can base a strong requirement on the experience of web fonts.  
> 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.
ok, so now we have some concrete data to point to :D  Excellent contribution, David!  

I'll work together offline with David to come up with some concrete text for the doc and report back once we have something.  

Kind regards,
Received on Tuesday, 16 October 2012 18:00:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:39 UTC