Taking the Responsive Web to Windows 8... and 8.1
I've worked on three Windows 8 apps using HTML/CSS/JavaScript (one largescale for a client and two smaller apps of my own), and I started all of them before Windows 8 was officially released. Going into the projects one of my favorite features was the multitasking views, showing two apps side by side. It seemed ripe for responsive web design...
We made mistakes.
Microsoft had a key recommendation early on to support these multiple "view state" scenarios: Take a more "adaptive" approach where you target the four view states specifically using media queries with four specific -ms-view-state values (fullscreen-landscape, fullscreen-portrait, filled, snapped). Snapped view was always 320px wide. Filled was always the device width minus 320px. Portrait was always fullscreen. Landscape was also fullscreen horizontally. While we all felt (on the client project) that a more responsive approach was better and future friendly, based on Microsoft's recommendation + an aggressive timeline + little documentation and community to find support at the time we decided to take this differing approach.
Enter Windows 8.1
This favorite side-by-side approach for apps in Windows 8 received an important advancement in Windows 8.1, one that fits in much better with 2013. Snapped view is no longer a guaranteed 320px. When you launch apps side by side they are by default each 50% width. Launch another and they fit into thirds. Want to make one slightly bigger? drag it and it is done. The world of four fixed states is gone, and an app can fit any number of widths and heights. Great for the user? Definitely. Great for the developer stuck in self-described 2010-fixed-width glory? Not at all. Great for developers excited about the real world where devices range from tiny to huge, and everything between and beyond? Yes.
And is it great for developers like me who followed the Windows 8 recommendation? Sure, because it reminds me to listen to myself and do things right the first time. Windows 8 was a big unknown in the summer of 2012. We knew you could develop with web technologies, and there was a WinJS library. Beyond that we didn't know if coding it like a typical single-page website was appropriate. There was the thinking that beyond using JavaScript, we needed to rethink how we worked. This turned out to be again a lesson in overthinking. If you can use HTML/CSS/JavaScript... then use it in the way that makes sense. We followed the recommendation that ultimately was not in line with our current thinking, and now we get to revisit everything and rework it. We could have coded everything without using the four view states and had it work the same in Windows 8 and been prepared for the change that eventually came in Windows 8.1. Alas.
Specific Changes in Windows 8.1
Most of these changes are highlighted in Microsoft's documentation.
First of all, the four specific view states in media queries are deprecated. Snap view even has a new minimum width of 500px (though you are able in your app's manifest to change it to 320px if desired). So they will continue to work today, but may not work in the way you expect if you target your app to the 8.1 SDK. Instead, use the more common media queries for min- and max-width (and the same for height).
Similarly, the ApplicationView.value property in JavaScript is deprecated. So instead of checking against this property to see which view state you were in, you directly fetch the document.documentElement.offsetWidth. PageControls in Windows 8 had an updateLayout method that would be called as a view state changed. I've not been able to find a mention of this being deprecated, but it appears the new suggested approach is simply to add a listener for the window's resize event.
There is no more unsnapping. Well... at least it, too, has been deprecated. We used this one a few times in our client app. Click on an item while in snap view and the app will, as expected, try to make your app be the on in the filled state, and shrink the other to snap view. It worked well, but Microsoft clearly wants your app to work regardless the width/height to which it is constrained. Reasonable.
Our New Approach
Do it right. Use relational units. Minimize our use of WinJS-y methods when there is a standard web alternative (unless there is a performance gain, etc.).
Also, with the old four view states, the thinking was often keep portrait, landscape, and filled relatively the same (scrolling horizontally as all good Windows 8 apps should), but make the snap view flow vertically (as the best Windows 8 apps did). With the increased minimum width, the vertical flow does not make as much sense always. So we are experimenting with always scrolling horizontally, adjusting list styles/sizes, and placement of flyouts, etc. Only time (and users) will tell what approach makes the most sense on this new platform.
The one thing we know for sure is that this approach for Windows 8.1 is a welcome change (even if we have to rework based on the original Windows 8 implementation/recommendation). It's a step in the right direction.