<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 23, 2015, at 12:48 AM, Yoav Weiss &lt;<a href="mailto:yoav@yoav.ws" class="">yoav@yoav.ws</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><span style="font-size:12.8000001907349px" class="">Hi,</span><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">As I've discussed during my session at the contributor's meetup, I'm interested in implementing&nbsp;<a href="http://igrigorik.github.io/http-client-hints/" target="_blank" class="">Client-Hints</a>&nbsp;in WebKit.</div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">For those unfamiliar with it,&nbsp;<span style="font-size:12.8000001907349px" class="">Client</span><span style="font-size:12.8000001907349px" class="">-</span><span style="font-size:12.8000001907349px" class="">Hints</span><span style="font-size:12.8000001907349px" class="">&nbsp;is a standard destined to improve content negotiation, and enable the browser to advertise various characteristics to the server along with resource requests, so that the server can adapt its responses to these characteristics in a cache friendly way.</span></div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">It was conceived to enable and facilitate server-side based responsive images solutions. The main use-cases for that are automatic optimization of legacy Web content, where it's not always easy to go back and modify the HTML, as well as external image optimization solutions that prefer content negotiation over HTML modification.</div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">I'd like to emphasize that this effort is orthogonal to the &lt;picture&gt; effort. (and the use-cases covered by each are orthogonal as well)</div><div style="font-size:12.8000001907349px" class=""><br class=""></div><div style="font-size:12.8000001907349px" class="">Since I intend to go ahead with implementation soon, I wanted to share my intentions with the wider WebKit community and gather feedback at this early stage.</div></div></div></blockquote><br class=""></div><div>Is the Internet-Draft for this planned to become a standards-track RFC? Is there an IETF Working Group that has adopted it?</div><div><br class=""></div><div>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><div><br class=""></div><div>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><div><br class=""></div><div>The &lt;meta&gt; requirement is problematic for two reasons:</div><div>- 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><div>- 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><div><br class=""></div><div>Also, if a content author is able to add a &lt;meta&gt; header, that contradicts the use case assumption that&nbsp;</div><div><br class=""></div><div>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><div><br class=""></div><div>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><div><br class=""></div><div>These issues make me wonder if the spec is really mature enough to implement.</div><div><br class=""></div><div>Regards,</div><div>Maciej</div><div><br class=""></div></body></html>