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

Re: WebP, anyone using it?

From: Matthew Wilcox <elvendil@gmail.com>
Date: Thu, 18 Oct 2012 19:36:17 +0100
Cc: David Demaree <ddemaree@adobe.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: <8ECE537A-6669-4566-8379-527CAE09364F@gmail.com>
To: Marcos Caceres <w3c@marcosc.com>

On 18 Oct 2012, at 19:30, Marcos Caceres <w3c@marcosc.com> wrote:

> Hi Matt, 
> On Thursday, October 18, 2012 at 7:21 PM, Matthew Wilcox wrote:
>>> On Oct 16, 2012, at 10:45 AM, Matthew Wilcox <mail@matthewwilcox.com (mailto:mail@matthewwilcox.com)> wrote:
>>>> 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.
> I don't think anyone is arguing for or against. We are discussing the range of options within the problem space and gathering evidence. We are all on the same side here and we are just gathering as much data as we can. 

Yeah, that's cool, I'm not picking a side - sides suck, they're divisive. It's my belief there are benefits to both approaches (server-side and client side). I'm just pointing out a problem with the viewpoint that the server might be relied upon for a particular feature when the logic that lead to <picture> itself negates the argument of using the server for that feature within <picture>.

>> 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 (http://Adobe.com). 
Received on Thursday, 18 October 2012 18:36:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:06:08 UTC