Re: WebP, anyone using it?

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

> (ah bah! I pressed send too early! )

Heh, I do that all the time! 

> 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. 

That's my point - it's only a problem to people who have the scale issue. Which the majority of websites don't. I.e., the scale-to-very-high-traffic problem simply isn't an issue that a smaller site would have by definition of being a smaller site.

As I understand the reported problem, it's not that CDNs can't do it - it's that their current business model makes it expensive. That's only because it's a niche technique at the moment. There's no reason not to believe that should this become common the CDNs would roll out the feature as standard, and thus the cost issue becomes moot.

From an actual server perspective, content negotiation based on a header property sent along with a request is not that expensive - you don't even have to spool up a dynamic language like PHP; you just configure the server engine to look in a different directory using a re-write rule. The only reason Adaptive Images requires Cookies; and thus requires PHP (and thus doesn't work on CDNs) is because the browser doesn't send useful headers along with URI requests. It has to use a cookie instead. We are, theoretically, in a position to change that.

Again; I'm not arguing for server side techniques *over* client side ones; I'm arguing it would be beneficial to have both.

Received on Thursday, 18 October 2012 18:44:33 UTC