Headers for markup resource referencing images

[waldbaerkoch]

Specifying CH-DPR and CH-RW headers for image requests (and Vary headers for image responses) is one thing. What is the recommended behaviour in terms of headers for requesting/responding the markup resource referencing images when the simplified markup syntax is used, e.g.

<img alt="A rad wolf." src="pic.jpg">

instead of

<picture>
  <source srcset="pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x">
  <img alt="A rad wolf." src="pic1x.jpg">
</picture>

in order to facilitate caching? Send CH-DPR in the request and DPR: ... with Vary: CH-DPR in the response? What about the markup request/response for the use cases in examples 4 and 5? Does the client have to send both CH-DPR and CH-RW? If so, what is the recommended value for CH-RW then?

Maybe you can clarify this in the spec.

[waldbaerkoch]

When creating the markup response, in order to be able to decide whether or not to send the simplified markup, the server-side component has to know whether the client will send a CH-RWheader in an image request. So some indicator is required even in the markup request.

[igrigorik]

As far as DPR/RW headers are concerned, there is no difference between "simplified" and "full" markup. The client should always send the DPR value, and RW if/when available. Also, note that you still want the "full" markup with sizes attribute, as that allows you to set the width at which the image should be displayed.

[waldbaerkoch]

As I read the spec, one gain from client hints is to simplify the srcset attribute value referencing resources. My concern is, how to decide server-side when to deliver short srcset attribute values (with only one URI) as indicated in the examples marked 'equivalent functionality...'. When the full srcset contains x descriptors, the indicator is the presence of CH-DPR, when it contains w descriptors,it is the presence of both CH-DPR and CH-RW, right?

[igrigorik]

You should always specify the full sizes attribute because that's what tells the browser the display width when it renders the image. Also, CH-RW wouldn't communicate the vw unit but the actual (CSS) pixel dimensions, which would allow the server to render/scale the asset (and yes, you'd also need DRP header for that to adjust for resolution).

[waldbaerkoch]

Hmm, looks like I couldn't make clear what I'm after. I'm not talking about asset (e.g. image) requests. I don't question the use of the sizes attribute. To me the spec sounds like, with client hints, there is a way to shorten the srcset attribute value in the markup request.and then let the server do the calculation of the appropriate response to the asset request. Example 1:

<!-- picture resolution switching -->
<picture>
  <source srcset="pic1x.jpg 1x, pic2x.jpg 2x, pic4x.jpg 4x">
  <img alt="A rad wolf." src="pic1x.jpg">
</picture>

<!-- equivalent functionality via CH-DPR -->
<img alt="A rad wolf." src="pic.jpg">

Here the trigger for the server to return the shortened markup (only img instead of picture with source and img) is probably the presence of CH-DPR in the markup request, because calculation of the asset response depends on CH-DPR in the asset request.. Example 4:

<!-- (Example 4) variable density / size selection -->
<picture>
  <source sizes="100vw" srcset="pic400.jpg 400w, pic800.jpg 800w, pic1600.jpg 1600w">
  <img src="pic400.jpg" alt="The president giving an award.">
</picture>

<!-- equivalent functionality with CH-DPR and CH-RW -->
<picture>
  <source sizes="100vw" srcset="pic.jpg">
  <img src="pic400.jpg" alt="The president giving an award.">
</picture>

Here the trigger for the server to return the shortened markup (shorter srcset attribute) is probably the presence of both CH-DPR and CH-RW in the markup request, because calculation of the asset response depends on both CH-DPR and CH-RW in the asset request..

[ghost]

Sorry to jump in, but not sure I agree that servers should be returning modified markup based on CH headers, seems really messy to me.

I wouldn't expect requests for non-image assets (at least initially) to contain CH headers? Ilya, maybe you can clear that up for me?

Also, images and other large assets are very often held on different domains/servers, so you can't assume that the server delivering the image (supporting client hints) has the ability to affect the markup.

And as a developer, I wouldn't want a server messing with my markup in a 'black box' fashion, I would know whether my server(s) supports client hints and would prefer control over my own markup.

Ed

[waldbaerkoch]

@resrcit-dev: If the spec does not allow (not require!) servers to change the markup, then what is the meaning of the section titled 'Interaction with picture element'?

[ghost]

The section describes how usage of the picture element could be simplified with Client Hints. Not necessarily that there is any responsibility of the server to 'clean' markup.

Ed

[waldbaerkoch]

@resrcit-dev. OK, not necessarily. But: whoever uses the picture element and wants to simplify it needs a trigger to know when to do that. In my use case I want to do it on the server.

[ghost]

I'd probably say this is outside the scope of client hints. I agree re: trigger, but argue the vast majority of developers will be aware of their server and whether client hints is supported. Absolutely nothing stopping you write something proprietary if thats what your requirements / use-case dictate though.

[waldbaerkoch]

OK, ignore everything that I said about doing something server-side :-) What are the conditions for being able to 'simplify' 'usage of the picture element' 'with Client Hints' in examples 1 and 4?

[igrigorik]

If the origin opts-in, the CH headers are automatically sent for all requests initiated by that page - images, stylesheets, XHR, and so on. It's reasonable to expect that the server may want to leverage hints to return a custom CSS stylesheet, a different set of scripts, and so on.

Note that Content-DPR confirmation header is only required for image responses, as it allows the browser to adjust its display logic. The confirmation header is unnecessary for other content types.

Hope that clarifies it!