> On May 6, 2015, at 4:49 AM, Yoav Weiss <[email protected]> wrote: > > > > On Wed, May 6, 2015 at 8:41 AM, Ryosuke Niwa <[email protected] > <mailto:[email protected]>> wrote: > On Tue, May 5, 2015 at 11:35 PM, Yoav Weiss <[email protected] > <mailto:[email protected]>> wrote: > On Wed, May 6, 2015 at 8:14 AM, Ryosuke Niwa <[email protected] > <mailto:[email protected]>> 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 [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
