Additional spec concerns: (1) The RW header is unimplementable because image requests are sent before the display width of the image is known.
(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. (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. (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? Regards, Maciej > On Apr 23, 2015, at 9:46 AM, Maciej Stachowiak <[email protected]> wrote: > >> >> On Apr 23, 2015, at 12:48 AM, Yoav Weiss <[email protected] >> <mailto:[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
