Adapting Your Site to Different Window Sizes

IE10 in the Windows 8 Release Preview supports the width and height properties of the W3C Working Draft
CSS Device Adaptation
. This gives Web developers a simple tool to control automatic content scaling across various window dimensions. In particular,
it enables Web sites to easily adapt to Windows 8 Metro style browser in the snapped view and portrait orientation.

Auto-Scaling and When It Is Used

Most websites have prioritized optimization for a 1024 pixel wide window. This ensures a good user experience for a wide variety of displays when the browser is maximized. However, sites may not work well on new form factors like tablets and portrait screen orientation if they haven’t optimized for other window sizes as well. In particular, pages often clip or distort layout when viewed in a narrow width.

Screen shot of TechCrunch Web site displayed in a very narrow Window. Only the left edge of the site content is visible. src="" original-url="" />Screen shot of a Wikipedia displayed in a very narrow Window. The left navigation bar is visible; the featured article is readable but wrapped in a very narrow column. style="margin-left: 2em; max-width: 40%; border: 1px solid #999; box-shadow: 3px 3px 8px 0px rgba(0, 0, 0, 0.25);" src="" original-url="" />
TechCrunch and Wikipedia displayed in very narrow windows

This narrow layout is particularly important in Windows 8, where the snapped view of the Metro style browser is in this exact state. This situation also occurs for portrait mode on slate devices due to the smaller form factor.

In the Metro style browser, the snapped view and portrait mode are auto-scaled by default to ensure at least 1024 pixels of layout width. Mobile devices take
a similar approach
when displaying non-mobile-optimized sites on a narrow form factor. Since most sites are built to work well at 1024 pixels, this ensures
that they are laid out well and do not clip content by default.

Screen shot of TechCrunch Web site displayed in Metro style snapped view. The whole page as laid out to a 1024 pixel width is visible and zoomed down to fit. src="" original-url="" />Screen shot of Wikipedia displayed in Metro style browser in snapped view. The whole page as laid out to a 1024 pixel width is visible and zoomed down to fit. style="margin-left: 2em; max-width: 40%; border: 1px solid #999; box-shadow: 3px 3px 8px 0px rgba(0, 0, 0, 0.25);" src="" original-url="" />
TechCrunch and Wikipedia displayed in Windows 8 Metro style browser in snapped view

Although this approach ensures a good default experience, users will need to zoom in to view and interact with the site.

Working Well In a Narrow Window

The best narrow layouts are those that have been custom-made by the Web developer. In addition to fitting the site into a narrower region, this also may require
changes to image sizes, reordering of content, alternative tools for site navigation, or other fundamental changes to content.

If your site has already made these modifications for narrow windows, then Device Adaptation can be used to override the default scale.

For some great examples of adaptive layouts, check out Media Queries. Metal Toad Media also has a great article discussing href="">layout width support based on prevalent devices and screen sizes in
the market.

Using @-ms-viewport

Simple support for the snapped view. If your site is already capable of a 320 pixel width layout, you can easily choose to show that version in the snapped view. Combining
Device Adaptation with CSS media queries allows the auto-scaling feature to be overridden selectively. This CSS overrides the default auto-scaling, and instead
enforces a consistent 320 pixel layout width for all windows 320 pixels wide or narrower:

@media screen and (max-width: 320px) {

@-ms-viewport { width: 320px; }


When the window is less than 320 pixels wide the content will be scaled down to fit. For example, a 300 pixel wide window will show the content at 93.75%
scale. For larger widths, IE10’s normal scaling applies (for example, when the Metro style browser is in portrait mode).

Device adaptation degrades gracefully in browsers which do not yet support it. These browsers can still benefit from narrow layout support—they just won’t auto-scale
to fit content to the window.

Portrait support. If your site supports a 768 pixel wide layout as well, then portrait mode support can be easily added with a second viewport rule:

@media screen and (max-width: 320px) {

@-ms-viewport { width: 320px; }



@media screen and (min-width: 768px) and (max-width: 959px) {

@-ms-viewport { width: 768px; }


We recommend testing your site in layout widths of 768 pixels (portrait on most slates) and 320 pixels (snapped Metro style browser) in addition to 1024 pixels and wider (landscape). You
can see an example of the viewport rule in action in the Make it Snappy! demo on the
IE Test Drive

—Matt Rakow, Program Manager, Internet Explorer

Comments (22)

  1. Arieta says:

    "Adapting Your Site to Different Window Sizes" is nice, but: "IE10 Adapted to Different Windows Versions" would be better.

  2. Pranav says:

    Does anyone else have this bug where after switching back to Metro Style IE from some other app, the frame is occasionally completely blank? The only way to bring the site back is to bring up the app bar with all the tabs and clicking or tapping on the current tab, which causes the page to reappear instantly.

  3. Mikko Tapionlinna says:

    Soo, you're breaking the currently working responsive sites and asking people to add new code just to get them working again? Nice.…/1047

  4. Josh T. says:

    It's great to see an early implementation of this really important spec. The sooner we can get rid of the viewport meta tag, the better.

    However, I won't find this very useful until device-width and device-height are supported.

  5. Anthony Colangelo says:

    Just when IE started to be nice to developers, you do this.

    You blew it.…/you-blew-it1.jpg

  6. Mikko Tapionlinna says:

    Okay, maybe I was a bit harsh. Sorry for that.

    It seems that you're between two tough places. Having few pixels to work with on sites that do not have responsive solution done yet and breaking the already working responsive sites. This all pain seems to come from the grand idea of getting everything (mobile, tablet, desktop) working with the almost the same look and feel (metro). These new things can cause problems, granted. It just felt like "Not again Microsoft, not again"-moment. :)

    Thanks for the post, at least now we can prepare.

  7. Corey says:

    Mikko, the [name="viewport" content="width=device-width, initial-scale=1"] stuff in a meta tag would do exactly what this vendor-specific prefix is trying to do, which is tell the browser that the site is capable of handling a variety of screen sizes ("width=device-width"), so don't zoom it ("initial-scale=1").

    So old sites that don't have that meta tag can safely be zoomed out to fit this very specific use-case (snapped view in Metro). Microsoft are simply duplicating this "signal" in CSS, which (yet again) breaks everything we've already done. BAD Microsoft! NO.

  8. @ Pranav : I experience the same problem….

  9. I'll definitely try this out.

  10. Matt Rakow [MSFT] says:

    @Josh T.:

    IE10 includes support for the device-width and device-height keywords within the viewport rule.  For sites that support a wide variety of window sizes, these values can be used to disable autoscaling entirely.  For sites that only support a subset of window sizes, it's generally a good idea to use these in conjunction with media queries to avoid over-disabling autoscaling.

    @Mikko Tapionlinna:

    You’ve described the challenge exactly:  autoscaling works better for single-layout sites, but sites with adaptive layout need the true window size.  Autoscaling by default is the right choice for the vast majority of sites on the web today, though it does mean that adaptive site authors will need to add a small amount of CSS to get this behavior in the Metro style browser.

  11. Only Release Preview?

  12. pure says:

    This might be a little off-topic now, but seeing the HTML5 and JavaScript support/performance increasing in IE (and other web browsers as well), I don't really get why we should invest time in building platform-specific apps for Windows, Android, and iOS, when all this can be done in HTML5/JavaScript in a platform-independent way. I mean, seriously: Google Mail, for example. It has a decent web interface and user experience for both small and large screen sizes — so, why do we need to build three different types of apps to use it when it can be accessed unchanged on many platforms and devices just as well via your web browser? I mean, it's like building rims for four, five, or any other number of screws but the same type of tire — a vendor-specific distinction that just creates unnecessary development overhead, complexity, and incompatibility. And if we really need a separate app model, the number one requirement should be compatibility across platforms. Make it work everywhere. Windows, Android, iOS — three kinds of the same thing just because everybody wants to do his own s**t. The same is true for all these proprietary CSS additions. Stop that nonsense.

  13. pure says:

    I guess Man has yet to learn that one can have greater benefit from working together than against each other.

  14. Lenard says:

    1.) The comment form is still broken!

    2.) Rather than waste time trying to get developers to support 4 different screen size modes for a single device !!!!! (portrait 768×1024, landscape 1024×768, landscape 2/3rds, and landscape 1/3rd) for their apps on windows 8 – why not just support true multitasking like on the PlayBook?

    *if* I decide to port any of my apps to windows tablets there's no way I'm going to put up with that mess.  The only real benifits to side by side app viewing would be to drag n drop between them but yet this isn't even supported.

    3.) I'm not changing a single line of my web code to support metro IE. the code I serve up works in all browsers and adjusts nicely for different screen sizes. Never again will I add any IE-only code – IE only code was the downfall of the web between 2000-2010.

    4.) Where's the Windows 7 version of IE10 already? I have no intentions of downgrading to Windows 8 (and I'm far from alone on this!) – if you actually want site content checked and tested in IE10 you ***NEED*** to ship a windows 7 version ASAP!!!

  15. Prior Semblance says:

    Guys this is a css feature not windows specific code.  If you're not interested in making your site look good at small sizes (believe it or not, windows 8 is not the only situation where this might happen) ok but this isn't microsoft trying to force anything on you.

  16. ಠ_ಠ says:

    Yeah, just what we need. More vendor prefixes.

  17. karl dubost, opera software says:

    The at-media rule for the viewport is a specification proposed by Opera Software. You might want want to add the vendor prefix for Opera too and the prefix-less one so there is a fallback for the future. It is always a good practice to be inclusive and future proof.

  18. Ryan Ludwig says:

    Can ems be substituted for px within the media query and viewport declarations?

  19. Parrotlover77 says:

    Will the user be able to change the autoscale width from 1024 to a custom value?  I hope so because most other mobile-optimized browsers allow this.

  20. Matt Rakow [MSFT] says:

    @karl dubost, opera software:

    That's absolutely correct — as with all early specifications, it's best practice to include prefixes for all vendors, as well as the unprefixed version.  Thanks for pointing that out.

    @Ryan Ludwig:

    Yes, these properties accept valid CSS length units.


    Yes, any custom value can be specified for the width, which will then be scaled up or down to fit the space available.  For example, a custom width of 768px is specified via:

    @-ms-viewport { width: 768px; }

  21. Colin says:

    Does width: device-width always disable scaling, even if the browser window is not maximized?

  22. Matt Rakow [MSFT] says:


    Yes – width: device-width specifies that the viewport width should match the unscaled window width, so no scaling gets applied.