Re: A question about the discussions so far

Hi Adam,   
Apologies for top posting, but I think you should just try this out. I think the best way for us to evaluate this solution is to have a prototype and prollyfill. It doesn't have to be anything fancy, just a quick slap-dash to show how it could work.  

What do you think?  


--  
Marcos Caceres


On Thursday, June 27, 2013 at 6:02 PM, Adam van den Hoven wrote:

> Thanks Markos
>  
> On Thu, Jun 27, 2013 at 12:30 AM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > Hi Adam,
> >  
> > On Thursday, June 27, 2013 at 12:31 AM, Adam van den Hoven wrote:
> >  
> > > Pardon me if this has already been addressed but I couldn't find any reference to this from a Google search so maybe its new.
> > >  
> > > The way I see the responsive images problem is one of responsibilities. The developer knows what he wants to show but only the user agent knows what its capabilities are. Ideally we would give the user agent the ability to request the correct representation of a resource based on a context only it knows (hardware, network, physical location...)..
> > >  
> > > In general it seems that most solutions put the onus on the developer to make optimal decisions about what representations to use when. But I think that we're going to run into the unavoidable problem of how do you efficiently declare representations for every possible situation? There are too many different variables to consider to do it justice.
> > >  
> > > Great, the new guy is telling us its a hard problem. Someone get out the cluebat.
> > heh. We all need a smack with the cluebat… don't worry :)
> > >  
> > >  
> > > What my question is, has anyone considered an HTTP solution?
> > Yes, see client hints:
> > https://github.com/igrigorik/http-client-hints
> >  
> > > Specifically, it seems to me that you could use the "300 Multiple Choices" response and then document a new mime type that specifies the collection of representations for this resource and relevant metadata (dimensions, file size, format, quality, location, geographic location?).
> > IIRC, 300 is not great, because when given multiple choices, it's the user that needs to make the choice.
>  
>  
> Actually no (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 emphasis is mine):  
>  
> "Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection."  
>  
> But one of the things that my proposal allows is control for the user. The UA could choose to pick what it thinks is an optimal image for the situation and then provide feedback to the user allowing them to get higher quality images if they choose.  
>  
> > > The user agent can then look at the metadata and decide which representation of the resource to use and then request that? So the UA could choose the high pixel, low quality small file size representation since is on a mobile network and has a high dpi screen (for example), but when it gets on WIFI it gets the bigger one. This is, again, not perfect since its hard for the UA to know how the resource will be used, but it can make more intelligent decisions in many cases. (and maybe we can use the equivalent of http's q property to indicate preferences, Location header aside)
> >  
> >  
> > Right, but it still needs to make a choice from a choice derived from a HTTP request (i.e., that's two requests, which is not great). Allowing the client to have more information up front avoids that.
>  
> The only way that can really happen is if you simply provide a list of variations with all relevant metadata so that the UA can make a real decision. Then its equivalent. But the current <picture> and srcset proposal (as I've seen it) do exactly the opposite. In that proposal, the content author says, "if you have these capabilities use that image" without any consideration of whether the user really wants to load the 40 megapixel image of your sports car.  
>  
> > > The value of this idea would seem to be that any type of resource could be handled this way (images, video, audio, code??) and it could be used anywhere (html, css, and js) without modifying them since its in the layer below.
> >  
> >  
> > Depends on the hinting provided to the server. There is another downside, pointed to by Ilya Grigorik, which is sending more data with each request. Not a lot, but a bit (Ilya says about 10-20 bytes).
>  
> My proposal does not increase the individual request size it increases the number of requests.  
>  
> > > Its not ideal because you need a new mime type, although, the UAs could explicitly add it to their accepts list and servers could use that for content negotiation and not break existing browsers.
> >  
> >  
> > I missed the new mime type bit? Where does that come in?
>  
> From the HTTP spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 again my emphasis added):  
>  
> "Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection."
>  
> > > It also requires extra HTTP requests.
> >  
> >  
> > Yep.
> > > This can be mitigated by embedding the entity in the page using a data uri (i realize this departs from the model somewhat) based on content negotiation.
> >  
> >  
> > This is adding a lot of complexity, IMO.
>  
> Actually not really. Its no different (other than what you're encoding) to the markup version. Sure, you couldn't hand code it (assuming a high density binary format) but its not substantially different in effect.  
>  
> > >  
> > > One could even create something like mod_responsive on the server side that used some convention to automatically handle this (say, create a folder called 'myfile.responsive' and the contents of the folder become the different representations of myfile) which would take away the complexity of this from content creators.
> >  
> > The research we have done within the group shows that a significant number of devs don't have control over the server side. Solutions that rely too much on the server
>  
> That's fine. I'm not suggesting that everyone would have to use it or that markup solutions are unnecessary. We don't need only one type of mousetrap.  
>  
> > > I'm sure that there is something inherently flawed in my thinking, but I have met very few people who think too hard about HTTP (we all worked at that place where we 'broke the web' in one way or another) so I'm hoping that maybe there is something here to investigate.
> >  
> >  
> > Don't worry, we have Ilya kicking around here to remind us about HTTP… he is also involved with HTTP 2.0.
>  
> I'm glad I'm not the only HTTP geek out there.  
>  
> I have one other thought in this regard. HTTP is at a much lower level than the browser; typically the OS (or at least frequently) handles HTTP itself and simply provides the UA with the things it asks for. Its entirely possible (again since I'm just the "HTML Dude" around here someone with "real" coding knowledge would have a better answer) that this approach could happen independent of browsers which would mean that the next security update of the OS could add the functionality to legacy browsers (although they may not be able to communicate user preferences for resource choices to the HTTP layer)  
>  
> > > Not being a browser guy, I can't say much more than, "did anyone consider"?
> >  
> >  
> > We have and we certainly need to keep investigating the viability of these options.
> >  
> > Kind regards,
> > Marcos
> > --
> > Marcos Caceres
>  
>  
> Cheers!
> Man, I should be working
>  
> --  
>  
> Adam van den Hoven1

Received on Thursday, 27 June 2013 19:12:15 UTC