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

[Proposal] Viewport HTTP header


Problem statement

The Link HTTP header can have a "media" parameter that specifies which media the resource applies to.

For example, if there’re the following HTTP headers, narrow.css is applied if the viewport width is less than 640px, otherwise wide.css is applied.

Link: <narrow.css>; rel="stylesheet"; media="(max-width:639px)"
Link: <wide.css>; rel="stylesheet"; media="(min-width:640px)"

However, browsers cannot evaluate media queries that depend on viewport dimensions without preprocessing the HTTP response body, because viewport dimensions are determined by the viewport <meta> element or the @viewport rule.

This is especially problematic with Link rel=preload headers, because its purpose is to initiate a resource load as early as possible, but browsers have to delay them until viewport dimensions are fixed.

Proposed solution

Today we don’t have an HTTP header-based mechanism to set a viewport. While it is not an http-equiv, couldn’t we just map the <meta name=viewport> into a Viewport header? For example:

Viewport: width=device-width, initial-scale=1

The header value would be processed in the same way as the <meta> viewport, as if it came before any <meta>, <link>, or <style> elements. Because of this, the Viewport header may be later overridden by ones set by <meta> viewport tags in the response body, but Viewport header would be a strong hint for browsers to start fetching resources for Link headers with media queries.


Just to be clear, this proposal is for a HTTP response header which sets the viewport dimensions of the page.


As you may already know, I think this sounds like a good primitive to include, and when we came across this sort of thing recently with the impl I was surprised something like it didn’t already exist. Am interested in hearing more feedback from web devs though.


YMBII: https://httpwg.org/http-extensions/client-hints.html


Client Hints are request headers that send the server with (among other hints) the viewport dimensions already set. As @irori pointed out, this proposal is about a response header that sets the viewport, similarly to <meta> tag based mechanisms we have today.


Anything that can help enhance RWD and WebPerf is welcome! :+1:t2:


I believe browsers download all stylesheets, even ones they can’t use, and only decide to not apply them later. This sucks, but they haven’t changed the behavior in decades.

Firefox is also the only browser that respects a stylesheet Link header, so maybe ask Mozilla what they think about this proposal?


It’d be easy enough to include this in Client-Hints, with a header that reflects Viewport-Width on the response side (like Content-DPR does for DPR).

In a perfect world, these would be named something like Accept-Viewport and Viewport or Content-Viewport, but that’s just aesthetics.


It’d be easy enough to include this in Client-Hints, with a header that reflects Viewport-Width on the response side (like Content-DPR does for DPR )

Would Content-Viewport be a simple number, like Viewport-Width and Content-DPR, or would it have the full semantics of <meta name=viewport>, like @irori’s initial proposal?