Re: WebP, anyone using it?

I'm also aware this has now sidetracked off topic.

My point: relying on the server for any part of <picture> functionality would seem to be counter to <picture>'s reason to exist - to create a client-side mechanism to control what image resource is delivered.

Of course, I could also simply be mis-understanding what the previous messages meant by using MIME information within <picture>.


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

> (ah bah! I pressed send too early! )
> 
> On Thursday, October 18, 2012 at 7:30 PM, Marcos Caceres 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. 
>>> 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.
>> 
> 
> Again, AFAIK, we are not dead set on any one solution. Please lets keep an open mind about all possible alternatives and try to work towards meeting the requirements. 
>>> If that's the case, then we should also be chasing client side solutions for file-type negotiation, not just URI resource negotiation.
>> 
> 
> Yes, that is certainly on the cards.  
>>> 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). 
>> 
> 
> Maybe, but we can learn a lot from TypeKit, which started small. If in TypeKit's experience it does not scale, then it should be noted that this may be an issue. As David pointed out, Google overcame this problem by "being Google" (i.e., they have a lot of infrastructure and computing power to throw at the problem). If another smaller entity solved the problem somehow, then it would be good to hear about it. 
> 
> 
> 
> 
>

Received on Thursday, 18 October 2012 18:48:19 UTC