> On Apr 23, 2015, at 12:48 AM, Yoav Weiss <[email protected]> wrote: > > Hi, > > As I've discussed during my session at the contributor's meetup, I'm > interested in implementing Client-Hints > <http://igrigorik.github.io/http-client-hints/> in WebKit. > > For those unfamiliar with it, Client-Hints 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. > > 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. > > I'd like to emphasize that this effort is orthogonal to the <picture> effort. > (and the use-cases covered by each are orthogonal as well) > > 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.
Is the Internet-Draft for this planned to become a standards-track RFC? Is there an IETF Working Group that has adopted it? 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? 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. The <meta> requirement is problematic for two reasons: - Most <meta http-equiv> 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. - 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 <meta> being processed before image requests are sent. Also, if a content author is able to add a <meta> header, that contradicts the use case assumption that 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. 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. These issues make me wonder if the spec is really mature enough to implement. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
