- From: David Demaree <ddemaree@adobe.com>
- Date: Tue, 16 Oct 2012 10:02:27 -0700
- To: Matthew Wilcox <mail@matthewwilcox.com>
- CC: Marcos Caceres <w3c@marcosc.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: <AD9A4735-3C23-4A7E-B44C-CA68F9AB11F2@adobe.com>
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/ 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.
Received on Tuesday, 16 October 2012 21:33:39 UTC