On Mon, Nov 11, 2019 at 10:13 PM Maciej Stachowiak <m...@apple.com> wrote:
> > > On Nov 11, 2019, at 4:37 AM, Noam Rosenthal <n...@webkit.org> wrote: > > > > On Mon, Nov 11, 2019 at 12:13 AM Maciej Stachowiak <m...@apple.com> wrote: > >> - Is there a specification for Content-DPR? All I could find in bugzila >> and elsewhere is links to < >> https://httpwg.org/http-extensions/client-hints.html>, which does not >> mention Content-DPR at all). >> > In a nutshell, the spec is in transition from IETF to HTML/fetch, and the > client-hints aspects of it are still in progress (unlike conent-dpr, which > is much simpler hasn't changed since introduced). It's documented here: > https://github.com/yoavweiss/client-hints-infrastructure/blob/master/specification_situation.md > . > I will answer more about this separately if required, waiting for some > info from the people working on the spec originally. > > > It looks like these are the relevant Pull Requests: > > > HTML: https://github.com/whatwg/html/pull/3774 | > https://whatpr.org/fetch/773/6a644c6...5067615.html#concept-response-image-density > Fetch: https://github.com/whatwg/fetch/pull/773 | > https://whatpr.org/html/3774/e32a6f8...ddb0544/images.html#current-pixel-density > > It looks like these are in a somewhat messy state. For example, Fetch > places the Content-DPR value in an “image density” variable, but it doesn’t > look like the Pull Request to HTML doesn’t use it anywhere. As another > example, HTML directly references Content-DPR as setting the “current pixel > density”, but does not specify that it would take priority over a density > derived from srcset. There are also no diffs to CSS Images or to SVG, which > provide distinct ways to reference images and which presumably should > respect Content-DPR. > > > >> - Can you give us some examples of how the CDN would make the decision of >> what density of image to serve without knowing the client’s DPR via >> client-hints? >> > Some examples from https://github.com/eeeps/content-dpr-explainer: > - making decisions by user agent, like choosing to cap certain images for > user-agents known to have smaller displays > - making decisions by traffic/geo, like serving lower-resolution images > when traffic is bogged down > - A client may ask for "placeholder image" (e.g. ?placeholder=true in the > URL), and the CDN would decide whether to serve a lower-quality JPEG or to > scale it down, or do both. > > > These seem like reasonable use cases. > > > - Is this presuming situations where the CDN serves the images but not the >> markup or CSS (which presumably could be rewritten to account for DPR)? >> > Correct. > > >> - What happens if Content-DPR is provided, but the markup or CSS has >> conflicting explicit info? For example, <img srcset=“image-2x.jpg 2x, >> image.jpg 1x”>, and image-2x.jpg is served with a Content-DPR header of 3x. >> Or the analogous thing with CSS. >> > When image size is decided, css/markup takes precedence, then content DPR, > and finally srcset-selection DPR. This is actually a bonus value of this > feature - if the server happens to serve an image that differs from the > ratio requested in the srcset tag, the intrinsic size match the served > content and not the request (which is more of a recommendation). > > - Does Content-DPR have any effect on images where an explicit size is >> provided, either in markup or in CSS? (I’m assuming no.) >> > No, it only has effect on intrinsic size. > > > Overall, this seems like a feature with valid use cases. But > unfortunately, it’s a (currently) Blink-only feature with no clear > specification. To the extent there is a spec, it’s mixed in with multiple > Pull Requests. These pull requests mix in Client Hints, a feature unlikely > to gain multi implementor support, so they probably won’t land any time > soon. And the language about Content-DPR is broken and does not not seem to > match Chrome’s actual implementation. > > So in summary, there is no proper spec, and Chrome has shown willingness > to have their implementation change faster than even draft spec language in > PRs can keep up with. > > Although the use case seems valid, I don’t think it’s a good idea for > WebKit to implement the feature in this state. It seems likely to cause > interop headaches and a need to reverse engineer Blink rather than > developing against specs and test cases. > > I would like to see a clean spec, either separating Content-DPR PRs from > client-hints or making a standalone spec. And either way it should be fixed > to match what Chrome has implemented, and have WPT tests that reflect the > spec and intended behavior. > I hear you. Let me get back to this thread once we're cleaner on the spec front. Thank you for the detailed response, it gives a clear path forward. ~Noam > > Regards, > Maciej > > > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev