Re: [webkit-dev] Client Hints
On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org wrote: 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? The resource width is planned to be based on the `sizes` attribute when available, and to fall back to the viewport width when it is not. There are no plans to delay image loading waiting for layout, nor are there current plans to use the layout information once we have it, as that would introduce undesired raciness. Okay, thanks for the clarification. Perhaps the spec should explictily state that. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Client Hints
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 m...@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 y...@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 y...@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 m...@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Client Hints
On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org wrote: 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? The resource width is planned to be based on the `sizes` attribute when available, and to fall back to the viewport width when it is not. There are no plans to delay image loading waiting for layout, nor are there current plans to use the layout information once we have it, as that would introduce undesired raciness. On Tue, May 5, 2015 at 10:59 PM, Maciej Stachowiak m...@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 y...@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 y...@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 m...@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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Client Hints
On Wed, May 6, 2015 at 8:41 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss y...@yoav.ws wrote: On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org wrote: 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? The resource width is planned to be based on the `sizes` attribute when available, and to fall back to the viewport width when it is not. There are no plans to delay image loading waiting for layout, nor are there current plans to use the layout information once we have it, as that would introduce undesired raciness. Okay, thanks for the clarification. Perhaps the spec should explictily state that. Good idea. I'll file a spec issue. Can I take the feedback here as a green light to implement (assuming that the header name concerns will be addressed)? Are there other blocking issues? Any other feedback? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Yusuke Suzuki is now a WebKit Reviewer
Congratulations, Yusuke! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Client Hints
On May 6, 2015, at 4:49 AM, Yoav Weiss y...@yoav.ws wrote: On Wed, May 6, 2015 at 8:41 AM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss y...@yoav.ws mailto:y...@yoav.ws wrote: On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: 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? The resource width is planned to be based on the `sizes` attribute when available, and to fall back to the viewport width when it is not. There are no plans to delay image loading waiting for layout, nor are there current plans to use the layout information once we have it, as that would introduce undesired raciness. Okay, thanks for the clarification. Perhaps the spec should explictily state that. Good idea. I'll file a spec issue. Can I take the feedback here as a green light to implement (assuming that the header name concerns will be addressed)? Are there other blocking issues? Any other feedback? Some more questions/comments about RW: - Is maybe-image-width-maybe-viewport-width a useful value? Perhaps there should be an always-present header for viewport width, and one for resource width that is present only when known? Though I’m not sure you can get a resource width even in the case where it’s known. - The “sizes attribute allows units which can’t be calculated down to px without doing a full style resolution, such as “em and “ex”. The HTML spec even has an example using em units. But RW requires a number in CSS px units. How can this be reconciled with preloading happening before style is resolved? - I don’t think making viewport-size-based decisions on the server side makes sense, because what do you do when the viewport is resized? Do you reissue the HTTP request for the image? - The premise of this spec is to allow an image server to provide multiple representations when the markup can’t be changed, but sizes=“” is a new attribute, so old markup won’t already have it, and it’s normally only useful when doing client-size image selection with srcset=“”. In what case would it make sense to combine client-side and server side selection? - What do you do when sizes=“” is changed on the client side? Do you have to issue a fresh HTTP request? The fact that this is all unclear in the current Internet-Draft is part of what makes me think it’s not quite ready for prime time. More general questions that remain: - Why require the server to opt into receiving these headers at all? Why not just always send? - Why multiple headers instead of one that can contain multiple tokens? That would allow a clearer name while maintaining compactness. General thoughts: - I am kind of skeptical of doing image selection on the server side. The claimed use cases of not wanting to change the markup don’t make sense to me, since to make effective use of the spec as written you may need to change your markup. That said, if there is real-world demand for this approach, and if we can resolve some of the thorny technical issues, I won’t object to an implementation. Right now I’m still not fully convinced this technology is compatible with image preloading. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Yusuke Suzuki is now a WebKit Reviewer
Thanks a lot for all your support!!! I'm so happy :D ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
