I'm writing a CSS book

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

sitemapcontact

Orientationchange and resize events on mobile

I published my research on the orientationchange and resize events on mobile. If you’re expecting plenty of browser incompatibility fun you won’t be disappointed.

orientationchange

I didn’t realise that the orientationchange event is WebKit-only (well, and Blink, but that doesn’t count). Opera/Presto, IE, and Firefox do not support it. I had assumed they’d meanwhile built it in, but no.

A typical orientation change is from landscape to portrait or vice versa. But what about turning the device 180 degrees? The orientation remains landscape, but something has surely happened. Should the event fire?

Only Safari, BlackBerry 10, and Tizen fire the event in these circumstances. The other browsers do not. I’m not sure who’s right or wrong.

resize

The resize event fires when the viewport is resized. But which viewport?

Browsers generally agree that it should fire when the layout viewport is resized; by an orientation change or by rewriting the meta viewport with JavaScript.

Opinions on the visual viewport differ. If the browser fires the resize event in this case, the event might serve as a proxy for a zoom event. We need a zoom event.

Only BlackBerry (all versions) and IE10 always fire the event when the visual viewport is resized. For the specific zoom use case they’re joined by Android WebKit 2 (but not 4), some Opera/Prestos, UC, and Dolfin.

The visual viewport also changes when the browser toolbar scrolls into or out of view, or when the software keyboard pops up. Android WebKit 4 is particularly annoying: in the first case one out of six tested versions fires the event, and in the second case two out of six. Android 4 !== Android 4. As if we needed more evidence.

So it seems that in general a visual viewport resize does not trigger a resize event. I’m wondering if this is a correct reading of the event’s meaning. The spec says it should fire when a document view has been resized, but fails to specify what a document view is. So for now I’m going to assume that the visual viewport is a document view, too. You view a document in it, after all.