I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

The problems with the device-adaptation spec

After last week’s rant about, among other things, the W3C Device Adaptation spec, one of the spec’s authors asked me to clarify my critique. Fair enough. Here’s my take on the current specification.

My critique of Device Adaptation consists of three main themes:

1. The spec does not address the actual current situation at all, while all browsers actually support my theory of the layout, visual, and ideal viewports decently, and I’ve already done the heavy lifting.
2. The spec is obscure about what its most important components actually mean; I’m especially thinking of the initial and actual viewport. A simple schematic would have helped a lot here, and it’s fairly easy to produce.
3. Although the spec treats relevant media queries as well as the meta viewport and the @viewport syntax, it does not treat the relevant JavaScript properties such as window.innerWidth and devicePixelRatio. That latter, especially, could do with some specification.

Don’t get me wrong: I do not think that the concepts presented in the specification are incorrect, though I have my doubts about the practical application of some items, notably min-width and max-width for @viewport {width} (in other words, not giving an exact width for the layout viewport, but merely a range within which it should fall). Still, I could be wrong and web devs might love it. Trying them in a practical project might be interesting.

However, the specification should first get the basics right. And it doesn’t.

The current situation

W3C is unfortunately heading back to the bad old days where it ignored actually-existing implementations in favour of completely new ideas whose connection to reality is sometimes tenuous. The Device Adaptation spec is an example of this trend.

I think that my research, and the underlying theories I created, offer a good model of how viewports actually work in browsers nowadays. I define three viewports:

1. The layout viewport defines the width of the entire page, which is equal to CSS’s initial containing block. If you give an element a width: 100% it stretches to 100% of the layout viewport width.
2. The visual viewport defines how much of the layout viewport is currently visible on the screen. The visual viewport changes when the user zooms in or out.
3. The ideal viewport defines the width and height of the layout viewport when width=device-width is set. It is the ideal layout viewport for the device the browser runs on; if set, it gives the browser’s user an ideal viewport width.

If you want to read the viewport saga in easy-to-grasp format I recommend chapter 4 of my book.

Having an actual specification for these three viewports would be useful. Even though all mobile browsers support them (partly thanks to my work in 2010-1), it’s useful to have a standard against which to measure implementations.

Unfortunately the specification does not mention anything remotely resembling the visual viewport even once — and this viewport is important for position: fixed and a few other CSS declarations. I think the spec does mention the layout viewport (see below). As to the ideal viewport, it is vaguely implied sometimes (I think), but any formal definition is lacking.

And that’s while I’ve already done the necessary research and the spec writers could just copy my definitions (or disagree with them, but at the very least acknowledge their existence as an accurate depiction of the current state of affairs).

New concepts

The specification instead defines the initial and actual viewports. Despite reading through the spec several times (once more just before writing this article), I’m not 100% certain which viewport(s) is/are meant here.

My current guess is that the initial viewport equals the natural layout viewport; that is, the layout viewport any web page would get out of the box. In most browsers this layout viewport is between 800 and 1024 pixels wide. It is meant to display desktop websites that aren’t mobile-optimised in any way decently — although they may be not easily readable because they’re too wide for the screen, at least their CSS doesn’t misfire horribly.

The actual viewport, I think, is the layout viewport after all relevant meta viewports have been executed. Thus it will usually be the same as the ideal viewport, since almost every practical use of the meta viewport uses width=device-width and results in the layout viewport being set to the ideal viewport’s dimensions.

However, I’m not sure of this. A simple schematic or code example, or in fact any sort of explanation, would hve helped greatly here. Unfortunately the spec doesn’t provide any.

Therefore I can’t tell you what the initial and actual viewport actually are, and, if my theory above is correct, why the spec does not mention the visual and ideal viewports.

I’m not against these new viewports — they might help to define what actually goes on in browsers when they apply meta viewports. However, they should be described in addition to the actual current state of affairs, not instead of.

JavaScript

One of the more pleasant discoveries I made back in 2010 was that there was an emerging de-facto standard for JavaScript properties that expose viewport widths and heights. Specifically, document.documentElement.clientWidth gives you the actual current dimensions of the layout viewport, while window.innerWidth does the same for the visual viewport.

I spent quite a bit of time telling browser makers to support these properties, especially the latter, and sometimes the going was slow (looking at you, Firefox), but nowadays they work in just about all browsers.

Not a hint of all this enters the specification anywhere. Browsers will continue to support these JavaScript properties anyway, but a specification that doesn’t mention them is incomplete.

DPR

It becomes even worse when we study window.devicePixelRatio. Nowadays, on most mobile browsers, this is the ratio between the physical device pixels on the screen and the ideal viewport. The only exception is the iPhone 6+, which is blatantly lying when it says its DPR is 3, while in fact it should be 1080/414 = 2.60869565217391.

Also, desktop browsers (except for Safari) have taken to treating DPR as a variable that depends on (is?) the current zoom factor. I’m not very happy with this state of affairs, since it breaks compatibility with mobile browsers, which all treat DPR as a constant.

The situation is complex, and I need to run some desktop tests to be certain of what’s going on, but a specification here would help a lot, since it would at least create a consistent theory of what DPR ought to be. That, in turn, would give me (and browser makers) something to agree or disagree with.

Unfortunately the specification doesn’t mention DPR even once.

Conclusion

Concluding, I feel the current Device Adaptation specification is flawed because it does not pay any attention to the actual system that’s in place right now in all browsers, because it doesn’t give a simple example to explain the initial and actual viewports, and because it doesn’t mention crucial JavaScript and media query properties; especially DPR.

Without these features the specification is unlikely to have a lot of influence on how browser vendors actually implement viewports, and how web developers use them. And that’s a pity, since some of the spec’s new concepts could enrich our understanding of the viewports.