[css-device-adapt] @viewport is preloader-hostile

[RByers]

There's been a flury of discussion on twitter about how <meta viewport> is badly broken, but @viewport has performance properties that makes it a bad replacement.

We should hash this out. In particular, what's the right way to bring the features of <meta viewport> to all browsers (regardless of form factor) without introducing new barriers to performance?

/cc @jacobrossi @ChumpChief @yoavweiss @domenic @rune-opera @bokand

[ChumpChief]

I've been doing a good bit of thinking on this one lately, and in general I feel like we should step back and scope this feature quite a bit. <meta viewport> is terrible because of all the magic behaviors and its strong association with mobile, specific device sizes, and assumptions of a fullscreen browser. @viewport is terrible because its behavior is too complex beyond the needs of most scenarios. And maybe this performance thing, though that hasn't really been a major source of pain for us compared to the functional issues of both viewport options.

Maybe a good first step would be for us to discuss the functionality that we want to support. I think a more scoped set of scenarios will allow more flexibility in the syntax used.

[RByers]

Sounds good to me. Maybe create a GitHub repo with a list of use cases (with the intention of incubating it in the WICG)?

[bradkemper]

I guess I'll wait for @yoavweiss to explain why at-viewport is bad.

[jacobrossi]

@bradkemper here's the issue, as I understand it:

When the parser loads the document, it may hit responsive images (srcset/picture). At that point, the parser wants to be able to kick off fetches for the right resource. However, if there's an at-viewport rule in an external stylesheet (which, by definition, is async loaded) then you don't actually know what the final viewport settings will be. As such, the parser/preloader doesn't know which resource to go fetch. So either (a) you guess and may end up loading the wrong one (make 2 img request, waste data, and possibly flash of the wrong content), or (b) block and wait until you've loaded the external stylesheets (non-starter, PLT would get killed).

meta viewport doesn't have this issue since it's inline in the HTML. Additionally, an inline style with at-viewport doesn't have the issue since it can be parsed synchronously.

[yoavweiss]

What @jacobrossi said. Also, the problem is particularly bad for images, but it also applies to any link element with a media attribute, including external styles, preload, and to some extent preconnect.

With @viewport you cannot know the dimensions of the viewport until you finished parsing (or at least tokenizing) all your HTML, found all external styles, downloaded all of them in their entirety and parsed them. If you also have blocking scripts before any one of your external styles, guess what? You have to wait on them as well** . Only then can you start downloading your responsive assets.

Otherwise, on the deployability front, browsers will have to continue to support <meta viewport> forever and authors would have to continue sending down <meta viewport> for years to come. So IMO, we have to properly spec what it does, and we might as well try to extend it in a backwards compatible way to support the use-cases that it doesn't cover today.

I very much support @ChumpChief's proposal to start with the use-cases that need handling and work our way from there.

** The script part can be optimized away by creating a CSS preloader that looks for @viewport tokens, but that'd definitely add complexity for no good reason other than @viewport's design.

[tabatkins]

I agree with everything @yoavweiss just said, and I'd love to see @ChumpChief and/or @RByers start up a GH repo to hash this out.

[bradkemper]

I don't know what the answer is, put from my point of view as an author, one of the biggest advantages is being able to have it in an external style sheet, instead of authored into every individual html document (which I often have no personal control over).

I don't mind limiting it to the common use cases.

Maybe there could be a requirement for the at-rule to be in the first 100 bytes of the file or something, and only when linked from the HEAD of the document (or inline in the HEAD).

[jacobrossi]

Limiting to the first N bytes or the head doesn't really help. Parsing is fast, network is slow. It's the fact hat the rule has to be fetched at all that makes it a perf problem not that it is deep in the file.

[frivoal]

The fact that the design is preloader-hostile is indeed an issue we need to solve. But there's another tension in the other direction: regardles of the actual mechanism, this really is style, not content, and belongs on that side of the divide.

This is not just true philosophically (although it is as well), but also practically: whether you should have an @viewport / <meta viewport> / whatever-alternative-we-come-up-with and what parameters it should have depends on what's in your stylesheet. If the same document / app is styled differently, you may need different viewport settings. Even if you're not switching stylesheets, content and styles may be handled by different teams, and the style teams has access to the css but not to the markup, yet they're the one who know what needs to go in to the viewport settings.

But this requirement is at odds with being pre-loader friendly, since it implies (at least naïvely) to store this in the form of a css rule in the stylesheet, as the current iteration does it.

I am not entirely sure how to solve both problems at the same time. I'd be tempted to experiment with something along the lines of what @bradkemper said: keep it in css, but only accept it from inline styles in <head> or from a stylesheet directly linked from <head> (no @import), and only if there's not synchronous js before it, and... That feels a bit clucky, and I'd certainly welcome something simpler, but I am very reluctant to have this somewhere else than in CSS, regardless of what the final incarnation turns out to be.

[frivoal]

Hopefully we can find an elegant solution that is both preloader friendly and preserves the separation of concerns.

If we can't find a general one though, would it really be terrible to have a preloader that's specialized to look for @viewport in inline styles inside <head>, but still have @viewport work elsewhere, with the implied downsides in terms of perf (and have dev tools, linters and friends warn about that)?

People who have a workflow where they can put it in the document itself, as they do today, can do so, and other people who value flexibility over performance could but it wherever.

[alexelias]

My perspective on this is that the only truly useful feature of meta viewport is "width=device-width". This tells mobile browsers to behave like desktop browsers (set layout width to size of the window). Therefore, desktop browsers "already support" the useful part of meta viewport in some sense, so there is actually almost no action we need to take here.

Breaking down the other features of meta viewport:

• width=[fixed number]; very rarely used (mainly ancient mobile content), enables actively non-responsive websites
• height=[anything]; even more rarely used. interop is extremely poor between different mobile browsers on "height" but we treat this as a P3 bug since there is very little usage nor use cases (except non-responsive, short-height layouts)
• minimum-scale, maximum-scale, initial-scale = non-1: I've never seen any use case for setting specific non-1 values of these
• initial-scale=1: arguably useful to disable some mobile browsers' behavior to always zoom out to fit the content width (although this can also be addressed by simply sizing all of one's content properly). This one is moot for the same reason as width=device-width though -- setting this value to 1 makes mobile browsers behave more like desktop browsers, so there's nothing to support here on desktop.
• user-scalable=no: arguably useful on desktop as well, although this can also be achieved by preventDefaulting input events (which use cases like maps which truly care about this are likely to do anyway).

Another way of phrasing this is that meta viewport is largely a way to declare "I designed my site with mobile browsers in mind, therefore disable all those mobile browser quirks that exist to compensate for non-responsive legacy desktop sites, and simply behave like a normal browser". It's just another piece of header boilerplate that will be on all sites moving forward, like the HTML DTD. It doesn't provide any functionality per se, it just disables some developer-hostile interventions.

[jacobrossi]

FWIW at-viewport was attempting to do more than just disable the "developer-hostile intervention" of mobile scaling. For example, width=[fixed number] becomes more useful because you can target multiple fixed numbers based on media queries (e.g. scale the viewport to a set of well-tested fixed widths depending on the range the device-width falls in).

So this comes back to the need to enumerate the scenarios like this and decide which ones we care about delivering. I'm not sure I want to jump to the conclusion that the only scenario we're trying to enable is disabling mobile scaling.

[alexelias]

I feel that if there was any developer interest in nonresponsive fixed layouts, we would've seen uptake of those capabilities of meta viewport in the ~2008-2012 period where iPhone was ascendant and had a single screen size. The fact that we didn't is a pretty strong signal that those capabilities are useless, to me. (I think it's a big stretch to argue that the media query feature was the key missing piece that prevented that.) I also feel that I would've seen, in years of bug triage, at least one issue that made me think, "ah, if only we supported @Viewport sizing capabilities, this could be solved".

So I don't think I'm jumping to conclusions. I think we gave that layout model a good chance and experience has shown it's a dead end. The only thing that was actually needed, and the inexorable trend of how UAs and webdevs treat meta viewport in practice, is as a convoluted equivalent to the old "mobileOptimized=true/false" property.