[webkit-dev] Client Hints

[Ryosuke Niwa]

I do have the same concern over terse names.  I don't see any point in
saving 13 bytes by abbrebiating DevicePixelRadio as DPR.

In the case of ResourceWidth, we can't get this number until we trigger a
layout.  It doesn't seem desirable to slow down the page load speed by
eagering triggering layout before loading each image.  How do we plan to
work around that?

On Tue, May 5, 2015 at 10:59 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> Does anyone else in the WebKit community have comments on this proposal?
>
>
>  - Maciej
>
> On Apr 28, 2015, at 8:42 AM, Yoav Weiss <yoav at yoav.ws> wrote:
>
> (Re) Posting Ilya's response from April 24th, since his response wasn't
> published on the mailing list archive for some reason.
>
> On Thu, Apr 23, 2015 at 1:37 PM, Yoav Weiss <yoav at yoav.ws> wrote:
>
>> +Ilya for spec related questions.
>>
>> 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.
>>
>
> Yes, we should scope this discussion to RW and DPR. This is consistent
> with Blink implementation [1], and to keep this thread focused I'll skip
> the comments on MD/RQ/etc. That said, happy to discuss those in a separate
> thread :)
>
>
>> On Thu, Apr 23, 2015 at 7:02 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> Is the Internet-Draft for this planned to become a standards-track RFC?
>>> Is there an IETF Working Group that has adopted it?
>>>
>>> Yes, and as part of the HTTP WG. /cc mnot
>
>> 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.
>>>
>>> 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're not the first to make
>> that comment, so I'm open to modify that, especially since HTTP/2 makes
>> this consideration irrelevant.
>>
>
> Uncompressed bytes on the wire add up quickly and short names are
> consistent with general policy of keeping those at a minimum. I don't
> believe this is counter to HTTP WG goals or guidance. That said, I'm not
> opposed to renaming them if there is a strong preference one way or another.
>
>> 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.
>>>
>>> Spec feedback is most welcome. The best place to send it is the GitHub
>> repo <https://github.com/igrigorik/http-client-hints/issues>.
>>
>
> Big +1 to that. This is all great feedback, thanks Maciej.
>
> ig
>
> [1]
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/vOgv-TqefsA/o_fEsy8RFcwJ
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150505/aa156fef/attachment.html>