Re: Responsive Image Protocol proposal

Thanks for the comments.

1) I think it's possible to avoid to make multiple HTTP request in most 
cases by directly serving the 2x version to a browser which advertise 2x 
support in an header (Vary: Resolution). I may update my proposal in the 
future to take that in consideration. BTW, sending a 2x version directly 
doesn't degrade the experience in the case of a JPEG-XR transfer becase 
JPEG-XR supports progressive loading (generating previews from partial 
data). However, using JPEG-XR directly and stopping the transfer when the 
client has enough data is not a good idea because it would result in a lot 
of wasted bandwidth (the time that the server receive the client message 
that it got enough information, a lot of data would already have been set by 
him, potentially the whole file).

2) That's what I'm trying here. By using no specific format for transfering 
the image, support is easy for browser vendors and hardware since we can 
build on existing formats such as PNG and JPEG-XR.

3) Yeah, we need to convince browser makers we need a solution for this. 
I'll try to reach some of them out using other channels once I worked out 
the issues I was reported.




-----Message d'origine----- 
From: Jason Grigsby
Sent: Tuesday, August 21, 2012 7:23 PM
To: François REMY
Cc: public-respimg@w3.org
Subject: Re: Responsive Image Protocol proposal

That is a pretty cool demo. Love see the diffs. I have a few thoughts on it:

1. There is a real emphasis from the browser makers on reducing the number 
of http requests because it is one of the largest determents of page load 
time. While I like the solution and the fact it works with existing formats 
and could in theory be polyfilled, I wonder if this is the road we go down 
(new image format), if the browser makers would rather work with a new image 
format that contained the different resolutions in the same file so it was 
only one HTTP request.

2. In my mind, the question of new image formats has never been a question 
of whether or not they would be nice to have. They assuredly would be. It 
was a question of someone volunteering a format that the browser makers can 
agree on and that doesn’t infringe on someone’s IP.

My sense is that the people in this group are ill-equipped to figure that 
out. Look at what happened with video codecs. I’m not saying a new format is 
impossible, but that it is somewhat out of our hands.

My fantasy scenario is that one of the browser makers that participates in 
the W3C would come forth and volunteer a format and donate it to the web.

One of the reasons for pushing forward with picture and srcset is that it 
forces the issue. If there are companies that don’t like srcset and would 
like to see a new image format, then they have a deadline to step up and 
make it happen before the new spec gets adopted.

Pushing forward with a solution that we know will work, imperfections and 
all, forces the conversation to happen which is what we’re seeking.

-Jason

On Aug 21, 2012, at 7:21 AM, François REMY wrote:

> Dear members,
>
> I’m new to this group and I hope I don’t relaunch an already-existing
> thread but here’s a proposal I crafted about a Responsive Image
> Protocol (file format) that some of you may find interesting :
>
>
> http://fremycompany.com/BG/2012/Responsive-Image-Protocol-proposal-908/
>
>
> Please feel free to comment; this is only an experiment at this point
> but I think it can solve a lot of the current respimg problem, and
> replace the srcset attribute (aka RIP srcset).
>
>
> Best regards,
> François
>

--

Jason Grigsby
+1 (503) 290-1090 o
+1 (503) 502-7211 m
jason@cloudfour.com
http://cloudfour.com

Received on Thursday, 23 August 2012 13:33:55 UTC