<div dir="ltr">+Ilya for spec related questions.<div><br></div><div>Also, I forgot to mention it, but my intention is to implement the RW and DPR hints first, and see about the MD and RQ hints (which are newer to the spec) later on.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 7:02 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>Additional spec concerns:</div><div><br></div><div>(1) The RW header is unimplementable because image requests are sent before the display width of the image is known.</div></div></blockquote><div><br></div><div>The intent is not to rely on actual display width for content images, but to rely on HTML based info (mainly the sizes attribute), similar to srcset.</div><div>It might be better to clarify that in the spec.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>(2) The MD header is defined in a way that’s probably not useful to rely on; if I’m on 802.11g on a home WiFi network where the next hop is a cable modem, the nominal speed of 802.11g is not helpful for knowing how long it would take to load a large resource.</div></div></blockquote><div><br></div><div>While the maximum downlink bandwidth does not provide the author with accurate bandwidth information, it provides them a cap over the current bandwidth. In other words, if that value is low, you can be certain that the network is limited, but the contrary is not necessarily true.</div><div>While accurate bandwidth would have been better (both here and as part of the NetInfo API), I don&#39;t think we have consensus on a decent way to expose (heuristic) bandwidth measurements.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>(3) The MD header references a table of values in the W3C’s Network Information API spec, but that is a Working Group Note with no technical content and a warning that work has been discontinued because “while working on this specification the Device APIs Working Group encountered issues related to estimating network bandwidth and with providing useful information”. In other words, the WG concluded that there isn’t a sensible way to do what the MD header is trying to do.</div></div></blockquote><div><br></div><div>The spec refers to the recent version of the <a href="https://w3c.github.io/netinfo/#downlinkmax-attribute">Network Information API</a>, rather than the outdated WG note.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>(4) The RQ header seems silly. It’s supposed to be a number 0-100, with fractional values allowed, that let the client specify it’s desired “resource quality”.  Why would you conceivably need this level of fine-grained selection? Will there really be a server with so many different versions of a resource that there’s a difference between quality 55.431 and 55.432? Furthermore, how is a client supposed to set this? Without knowing what the server will do or what value thresholds are important, is there anything useful WebKit could do other than always send 100?</div><div><br></div></div></blockquote><div> </div><div>I believe fractional values here are not intentional.</div><div> </div><div>&lt;snip&gt;</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Is the Internet-Draft for this planned to become a standards-track RFC? Is there an IETF Working Group that has adopted it?</div></blockquote></div></div></div></div></blockquote><div>Not sure. I&#39;ll let Ilya answer that. <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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On the use cases: is there really anyone who is able to provide new higher resolution versions of their images, but cannot modify the HTML that references them?</div></blockquote></div></div></div></div></blockquote><div>For the legacy content use case: It&#39;s not about providing new higher resolution images, but about adapting current images to smaller viewports, and sending smaller images when the device doesn&#39;t need to full desktop-sized image.</div><div><br></div><div>For the automated image conversion use case: The use case is about optimizing the images at a separate layer, that&#39;s not necessarily HTML aware.</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On the spec contents: I’m wary of the fact that the header names are very opaque. That’s not in the HTTP tradition, where header names are generally human-readable. I am skeptical that the HTTP WG would be satisfied with these header names as-is.</div></blockquote></div></div></div></div></blockquote><div>I believe the intent with the short names was to minimize impact on the network, since the headers will be sent with every sub-resource requests once the server has opted-in. With that said, you&#39;re not the first to make that comment, so I&#39;m open to modify that, especially since HTTP/2 makes this consideration irrelevant.</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">The &lt;meta&gt; requirement is problematic for two reasons:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">- Most &lt;meta http-equiv&gt; values are not processed as the equivalent http header. HTML5 limits it to a whitelist. It doesn’t seem like a good idea to extend this legacy facility.</div></blockquote></div></div></div></div></blockquote><div>While true, this won&#39;t be the first header to extend that white list. Looking at Document.cpp::processHttpEquiv I see that x-dns-prefetch-control, x-frame-options and various variants of Content-Security-Policy already have support for their meta equivalent.</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">- Browser engines may issue image requests before actually parsing the document (e.g. WebKit’s preloading feature) so it doesn’t seem safe to rely on &lt;meta&gt; being processed before image requests are sent.</div></blockquote></div></div></div></div></blockquote><div>True, but the preloadScanner can parse out these &lt;meta&gt; tags and add them to its logic.</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Also, if a content author is able to add a &lt;meta&gt; header, that contradicts the use case assumption that </div></blockquote></div></div></div></div></blockquote><div>True for legacy content, less so for automated image optimizers. </div><div>An example use case can be a site which HTML is hosted at a static location (e.g. GitHub pages) while the images are served from an image-aware CDN.</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Finally, content negotiation has mostly been a giant failure on the Web, so I’m not sure why we would want to expand it. Is there a reason to believe this spec will be less of a failure than existing content negotiation.</div></blockquote></div></div></div></div></blockquote><div>Since the server has to opt-in to be sent with Client-Hints, it doesn&#39;t suffer from ailments of previous content negotiation solutions.</div><div>The main criticism heard about past content negotiation attempts have been that we have to keep sending these request headers even if no one uses them. That won&#39;t be the case here.</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 class="h5"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:14px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I know spec feedback may be off-topic for an implementation thread, but I’m not sure where else to send it since it’s not clear if this Internet-Draft is associated with a working group.</div></blockquote></div></div></div></div></blockquote><div>Spec feedback is most welcome. The best place to send it is <a href="https://github.com/igrigorik/http-client-hints/issues">the GitHub repo</a>. </div></div><br></div></div></div>