I'm writing a CSS book

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

contact

Desktop DPR redux

Well, some discussion has certainly started about my first and second desktop media query bug reports. A redux is useful.

First, some good news. The way the resolution media query is currently behaving in Chrome is a bug, and it’s in the process of being fixed. That takes a load off my shoulders; for a moment I was afraid it was designed this way. But it’s not.

This does not say anything about the underlying issues I have with redefining DPR, though. Apart from the technical issues, there’s a cultural issue, if you wish. The discussions clarified my thinking and I can now describe it.

Desktop and mobile zooming

I wrote:

Zooming on desktop is totally different from zooming on mobile. On the desktop, the (layout) viewport becomes smaller when you zoom in, since less CSS pixels now fit in the browser window. On mobile, the layout viewport is unaffected, and only the visual viewport changes size.

This is all true and important; and I agree that web developers should be hit over the head with the difference time and again until they understand it. In fact, I’m currently selecting the very cudgel I’m going to wield in the process, and you can expect me to use it ad nauseam in the next year or so.

The weird thing is that during my discussions, both on Twitter and in private email, the difference between desktop and mobile zooming was brought up in hushed and reverend tones, as if it’s a totally new concept that nobody in the history of history itself has ever considered ever. Well, I’ve been considering it for three years, and Nokia, BlackBerry, and Apple for even longer.

Even more oddly, it seems as if people think the difference in zooming is an argument in favour of the new-style DPR that desktop browsers are pushing.

1. Desktop and mobile zooming are vastly different.
2. ?????
3. Desktop zoom level should be exposed in window.devicePixelRatio. We break the One Web, hurray, hurray.

I do not understand the second step; the minor of the syllogism, if you wish. If someone could connect the dots for me I’d be grateful. Maybe I’m missing something here.

Meanwhile I will treat the difference between desktop and mobile zooming as an argument for my solution.

1. Desktop and mobile zooming are vastly different.
2. Web developers must be able to disregard mobile zooming while using desktop zooming extensively.
3. We need separate properties, media queries, and events for zooming.

The elephant in the china shop

<soapbox>

In the past three years or so, the mobile viewport has gone from a random collection of good and bad ideas, as well as stretches of pure gibberish, to a de-facto emerging standard. Every time I study the mobile viewport I see more and more browsers subscribing to the same theory and definitions.

Enter the desktop browser vendors. It seems as if the mobile viewport is something totally new and unexpected to them. Worse, they don’t seem to understand the ins and outs of the system.

I’m sorry if this comes across as arrogant, but I feel the desktop browser makers are behaving as the proverbial elephant in the china shop, barging around, creating new definitions and breaking an awful lot of stuff that has just started its ascent to cross-browser compatibility — and all this for no reason but their own confusion.

The exception is Apple, which seems to be the only one to have internalized the shift to mobile. In fact, large swaths of the mobile viewport were invented by Apple, and were subsequently copied by the other browser vendors because iPhone.

I stand solidly behind Apple here, that’s for sure. They’re the only ones to understand what’s at stake.

I mean, the One Web is important, isn’t it? We should take care that properties, media queries, and everything else work the same on desktop, mobile, and as-yet-to-be-invented devices, right? Then do it.

Again, I’m sorry if this comes across as arrogant, but this is truly how I feel. Desktop browser vendors know too little about the mobile viewport and are breaking stuff out of ignorance. (And hey, if you have questions, ask. That’s what I’m here for.)

As to W3C, it has rendered itself effectively irrelevant in this discussion. I first published my mobile viewport findings three and a half years ago, in May 2010, and since then W3C has done absolutely nothing in this area. I expectd a draft spec that treated the mobile viewport, and expected it, and expected it.

Enough. W3C has forfeited its right of initiative. It should rubber-stamp the mobile viewport as it exists today, and not make any changes. It has done nothing to help bring about the de-facto standard, so it has lost its right to determine how the standard looks. (Again, if you need help, ask.)

</soapbox>

Use cases

Alistair Campbell took a look at practical use cases for high-DPI zoom.

It is counter-intuitive, but actually the higher the DPI the better for people with mild/moderate visual impairments (VIPs from here).

For example, I heard from several VIPs that they found the iPhone 4 a big improvement in clarity. Googling just now I found someone post about that.

That’s not what I expected, but it’s interesting. Also, I cannot resist the temptation of making this finding into yet another argument in favour of my theory.

If vision-impaired users would like high DPI for their images, it becomes necessary to leave DPR as it is today. After all, the users will also need high-res images when the zoom level is 1. And if the zoom level is exposed in DPR, and is 1, desktop website makers will assume high-res images are not necessary and withhold them. If DPR were a constant, however, reflecting the device and not the zoom level, vision-impaired users would be adequately served.

matchMedia

Finally, I did one matchMedia test. This method is supposed to return true if a certain media query would fire in the current configuration.

Also, it was suggested that we would do better to use matchMedia than JavaScript properties such as screen.width. This turns out not to be the case.

In Chrome 31, at least, matchMedia for the resolution media query does not actually match the query. The media query remains at 1 for a long time, while the matchMedia value grows slowly.

I haven’t tested matchMedia extensively yet; I’m currently figuring out how to do that (or rather, I know how to do it, but I’m afraid of performance issues on mobile since I’ll have to generate hundreds, maybe thousands of media queries).

However, I extensively tested the traditional JavaScript properties, and found they work in an ever-growing number of mobile browsers. The only exception is screen.width/height, whose definition is shifting.

Therefore I can say with certainty that the JavaScript properties are fairly reliable, while matchMedia is not proven to be reliable, and data is available to show that it isn’t in the exact use case under discussion.

Conclusion

No real conclusion here; the discussion continues and I haven’t yet heard persuasive arguments in favour of DPR exposing zoom level on desktop. In fact, my resolve that I am right and the desktop vendors (except Apple) are wrong is only growing.

But we’ll see. Maybe I’m wrong after all. Wouldn’t be the first time.