[webkit-dev] Client Hints

[Yoav Weiss]

On Wed, May 6, 2015 at 9:09 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

I believe that this value is useful since it represents an upper bound of
the number of CSS pixels in which the image will be displayed.
Along with DPR, it enables the server to send the largest possible useful
image.
With that said, we can try to think of use cases where the server actually
needs to know which one was provided, and try to account for them if there
are any.


>
> - 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?
>

Relative units in sizes
<https://html.spec.whatwg.org/multipage/embedded-content.html#source-size-2>
are resolved similar to relative CSS units in Media Queries - relative to
the root font size. <http://dev.w3.org/csswg/mediaqueries-4/#units>
so "em" in this case is identical to "rem", and "ex" would be half that.


>
> - 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?
>

That's up for the browser (same as srcset). When the viewport change
results in a smaller source-size length, I guess there's no much sense in
downloading a different image, but when it's significantly larger, it might
(and the server can respond with a 304 in case there's no higher quality
version). For WebKit's case it may make sense to implement that along with
srcset's viewport reactivity.


>
> - 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?
>

`DPR` would be useful without any client-side changes.
`RW` would be useful as well, even without `sizes` in markup - limiting the
images to the dimensions of the viewport is something that several
automatic image conversion services are doing today, either by using
(inaccurate) UA sniffing, or by relying on cookies after the first time the
user browses the page.
Adding `sizes` to the mix (in the use cases when it is possible) provides
us with extra optimization on top of that.

We can also leverage the `width` attribute (when in pixels) to provide us
with the display dimensions info when `sizes` is missing in legacy sites.



> - What do you do when sizes=“” is changed on the client side? Do you have
> to issue a fresh HTTP request?
>

Same as the viewport change case.


> 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.
>

Since the spec is destined to be an IETF RFC, it's destination audience is
not restricted to browsers, and therefore, it's skimpy on browser related
details.
It's probably a good idea though to create a related document that would
contain all these browser related details, and what browsers are expected
to do in various scenarios.


>
>
> More general questions that remain:
>
> - Why require the server to opt into receiving these headers at all? Why
> not just always send?
>

There was some resistance about sending extra headers over all requests
even if they aren't used, which lead to the introduction of the opt-in
signal. With that said, this is up to the UA.

- Why multiple headers instead of one that can contain multiple tokens?
> That would allow a clearer name while maintaining compactness.
>

Multiple headers are more cache friendly, since you can "Vary" on each one
of them independently. If "Key
<https://tools.ietf.org/html/draft-fielding-http-key-02>" was complete and
implemented everywhere (including intermediaries) we wouldn't need that
split. Unfortunately, that's not the case, so splitting to multiple headers
has significant caching advantages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150508/5c90dbaf/attachment.html>