<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 9:09 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br></div></div></div>Some more questions/comments about RW:<div><br><div>- Is maybe-image-width-maybe-viewport-width a useful value? Perhaps there should be an always-present header for viewport width, and one for resource width that is present only when known? Though I’m not sure you can get a resource width even in the case where it’s known.</div></div></div></blockquote><div><br></div><div>I believe that this value is useful since it represents an upper bound of the number of CSS pixels in which the image will be displayed.</div><div>Along with DPR, it enables the server to send the largest possible useful image.</div><div>With that said, we can try to think of use cases where the server actually needs to know which one was provided, and try to account for them if there are any.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>- The “sizes&quot; attribute allows units which can’t be calculated down to px without doing a full style resolution, such as “em&quot; and “ex”. The HTML spec even has an example using em units. But RW requires a number in CSS px units. How can this be reconciled with preloading happening before style is resolved?</div></div></div></blockquote><div><br></div><div><a href="https://html.spec.whatwg.org/multipage/embedded-content.html#source-size-2" target="_blank">Relative units in sizes</a> are resolved similar to relative CSS units in Media Queries - <a href="http://dev.w3.org/csswg/mediaqueries-4/#units" target="_blank">relative to the root font size.</a></div><div>so &quot;em&quot; in this case is identical to &quot;rem&quot;, and &quot;ex&quot; would be half that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>- I don’t think making viewport-size-based decisions on the server side makes sense, because what do you do when the viewport is resized? Do you reissue the HTTP request for the image?</div></div></div></blockquote><div><br></div><div>That&#39;s up for the browser (same as srcset). When the viewport change results in a smaller source-size length, I guess there&#39;s no much sense in downloading a different image, but when it&#39;s significantly larger, it might (and the server can respond with a 304 in case there&#39;s no higher quality version). For WebKit&#39;s case it may make sense to implement that along with srcset&#39;s viewport reactivity.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>- The premise of this spec is to allow an image server to provide multiple representations when the markup can’t be changed, but sizes=“” is a new attribute, so old markup won’t already have it, and it’s normally only useful when doing client-size image selection with srcset=“”. In what case would it make sense to combine client-side and server side selection?</div></div></div></blockquote><div><br></div><div>`DPR` would be useful without any client-side changes. </div><div>`RW` would be useful as well, even without `sizes` in markup - limiting the images to the dimensions of the viewport is something that several automatic image conversion services are doing today, either by using (inaccurate) UA sniffing, or by relying on cookies after the first time the user browses the page.</div><div>Adding `sizes` to the mix (in the use cases when it is possible) provides us with extra optimization on top of that.</div><div><br></div><div>We can also leverage the `width` attribute (when in pixels) to provide us with the display dimensions info when `sizes` is missing in legacy sites.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>- What do you do when sizes=“” is changed on the client side? Do you have to issue a fresh HTTP request?</div></div></div></blockquote><div><br></div><div>Same as the viewport change case.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>The fact that this is all unclear in the current Internet-Draft is part of what makes me think it’s not quite ready for prime time.</div></div></div></blockquote><div><br></div><div>Since the spec is destined to be an IETF RFC, it&#39;s destination audience is not restricted to browsers, and therefore, it&#39;s skimpy on browser related details. </div><div>It&#39;s probably a good idea though to create a related document that would contain all these browser related details, and what browsers are expected to do in various scenarios.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div><br></div><div>More general questions that remain:</div><div><br></div><div>- Why require the server to opt into receiving these headers at all? Why not just always send?</div></div></div></blockquote><div><br></div><div>There was some resistance about sending extra headers over all requests even if they aren&#39;t used, which lead to the introduction of the opt-in signal. With that said, this is up to the UA.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>- Why multiple headers instead of one that can contain multiple tokens? That would allow a clearer name while maintaining compactness.</div></div></div></blockquote><div><br></div><div>Multiple headers are more cache friendly, since you can &quot;Vary&quot; on each one of them independently. If &quot;<a href="https://tools.ietf.org/html/draft-fielding-http-key-02" target="_blank">Key</a>&quot; was complete and implemented everywhere (including intermediaries) we wouldn&#39;t need that split. Unfortunately, that&#39;s not the case, so splitting to multiple headers has significant caching advantages.</div></div></div></div>