A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Viewport Height Client Hint Proposal

tbansal
2020-11-02

Currently, Responsive Image Client Hints provide a way for origins to obtain the viewport’s width. However, no such attribute exists for viewport height. We’ve observed that to optimize the loading of content that appears in viewport, it is essential for the origins to adapt HTML response based on viewport height. Current methods of doing that include content-negotiation through the User-Agent string, but that is sub-optimal as it’s indirect, and doesn’t cover all platforms.

We’d like to propose adding a new attribute “viewport-height” (similar to existing viewport-width). Similar to other client hints, origins would be able to register the opt-in for viewport-height client-hint via Accept-CH header, and receive the attribute value as part of HTTP request headers. This would enable origins to e.g., inline all the content that’s expected to appear in the viewport, or avoid lazy-loading it.

Even if the above mechanism is an optimization, using Client Hints would enable to benefit from Client Hints Reliability and have that information available on the very-first load.

Thoughts on the above? Would the hint be useful for other forms of content-negotiation? (e.g. for height-bound images)

yoavweiss
2020-11-02

/cc @eeeps

eeeps
2020-11-25

I think that this would be a good addition to the Responsive Images Client Hints spec.

For height-bound image optimization, I guess you’d really want a CH-Height hint + something like the two-dimensional sizes syntax outlined by @tabatkins back in 2014.

But the same use cases that motivate CH-Viewport-Width for images carry over to CH-Viewport-Height:

  • a backup in cases where there is no CH-Height (allowing servers to do what browsers do when doing srcset+w selection when no sizes is present: default to 100vw as a backup).
  • server-side automated art direction (ensuring that, e.g., the whole product is always visible above the fold by serving a visibly-different image on wide+short viewports).

Looking beyond images, on navigation requests – dynamically inlining “above-the-fold” styles, or figuring out which images need a lazyload attribute or not, seem like exciting possibilities. I’m also imagining dynamically subsetting fonts for later patching.