Re: A question about the discussions so far

Thanks Markos

On Thu, Jun 27, 2013 at 12:30 AM, Marcos Caceres <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