Windows Phone 8 Viewport Issue
Recently, our development team ran into an interesting issue while testing a responsive web design layout on Windows Phone 8. There are in-depth posts out there on the topic and the fix, specifically from Tim Kadlec and Matt Stow, but I'd like to give a quick overview of what our team discovered and why we weren't overly surprised to find it.
If you're unfamiliar with this topic, responsive web design relies on the viewport meta tag, which allows developers to tell mobile browsers on which scale (pixel-wise) to render a web page. For example, let's say your website has a 980 pixel width and it's being rendered on a 720 pixel-wide Galaxy SIII (although the xhdpi of 200% translates to an actual 360 pixel device width). If the web page doesn't declare a viewport, then the device will intelligently render a zoomed-out layout to the point of the outer-most site container. Declaring a viewport that includes an initial scale of 1 and a width relative to the device width will ask the device to zoom in and render the page relative to the CSS pixel ratio of 1. Using the viewport, in combination with media queries, is the basis of responsive web design.
In this scenario, our team's tests showed that Windows Phone 8 clearly behaved differently to every other mobile OS in that it seemed to interpret the viewport relative to the defined device width as dictated by the manufacturer. So the Windows Phone 8, in portrait mode, was returning a response that suggested the device was 768px-wide and not the expected optimal visual viewport based on the browser's CSS pixel calculation. We worked around this by applying the approaches outlined in the posts by Tim Kadlec and Matt Stow, which improved on the suggested fix directly come from Microsoft. Unfortunately the fix involves client-side user agent sniffing...not ideal, but acceptable in this case.
Considering the viewport bug was logged by Microsoft back in early 2013, and hasn't yet been patched and pushed to devices, we're once again wondering if Microsoft (or at least it's carriers) shouldn't consider the 'micro-updating' structure that so many application developers have embraced. This allows for agile updates and bug-fixes that are otherwise lost or delayed by Microsoft's current update delivery schedule.
In addition to this, we ran into another Windows Phone issue on a different site where we were strategically layering responsiveness into an existing site layout to make it mobile friendly. Unfortunately, the master templates included a meta tag that forced IE to render in IE8 compatibility mode. This declaration affected IE Mobile as well, meaning it was put it into compatibility mode of an IE version that predates responsive techniques. Conditionally loading the IE=8 Compatibility meta tag within <![if !IEMobile]> was the fix in this instance.
As I wrap up this post, further IE10 Mobile tests have exposed irregularities with respect to hover events, like menus. But that's another discussion.
Although the IE development team has clearly made great strides in recent years, it's déjà vu when we find ourselves discussing how IE continues to require developers to bend to it's shortcomings, this time in the mobile space. IE Mobile continues the challenge, and we're not out of the woods yet.