Browsing in the new Windows UI for web developers
This article describes how pages function differently in Windows 8 between the familiar Internet Explorer for the desktop and Internet Explorer in the new Windows UI. It also describes best practices for building touch-first sites. These recommendations apply to both browsing experiences of Internet Explorer 10 and later.
Windows 8 provides two browsing experiences with Internet Explorer 10: the familiar desktop browsing experience and the new Windows 8 browsing experience.
Both browsing experiences use the same underlying components, from the network stack and cache to the rendering engine, and both send the same User Agent string and have the same Document Object Model (DOM). As a developer, treat both experiences as one browser, Internet Explorer 10.
ActiveX and other binary extensibility
The Windows 8 browsing experience doesn't support Microsoft ActiveX or any other binary extensibility. To ensure your site works for all customers, provide an experience that doesn't depend on plug-ins. This helps all customers who browse without plug-ins, whether they use the Windows 8 browsing experience, disable plug-ins with ActiveX Filtering or a browser add-on, or browse on a device like a phone or tablet that doesn't support plug-ins.
Patterns for proper fallback
Your site will provide a better customer experience by following best practices to test for the standards-based feature first, and fall back to plug-ins only if necessary. The following example shows how to detect and use HTML5 video first, and then use plug-ins if the video element isn't available:
<video id="video1" width="640" height="360" controls>
<source src="video.mp4" type="video/mp4">
<source src="video.webm" type="video/webm">
<object width="640" height="360" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0">
<param name="SRC" value="http://ie.microsoft.com/testdrive/IEBlog/Common/player.swf?file=video.mp4">
<p>Please update your browser or install Flash</p>
</object>
</video>
For more info about cross-browser support for HTML5 audio and video, including codecs and captioning, see Practical Cross-Browser HTML5 Audio and Video. Many sites already perform the equivalent of this fallback when serving ads in the absence of plug-ins, showing that this approach is a practical and scalable solution.
If your site delivers a premium experience with a plug-in, use the following fallback:
<object width="640" height="360" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0">
<param name="SRC" value="http://ie.microsoft.com/testdrive/IEBlog/Common/player.swf?file=video.mp4">
<video id="video1" width="640" height="360" controls>
<source src="video.mp4" type="video/mp4">
<source src="video.webm" type="video/webm">
<p>Please update your browser or install Flash</p>
</video>
</object>
This pattern guarantees that anyone with the plug-in will use it and those without it will get the native platform experience. If the customer is on a browser without the plug-in or the native support, the customer can attempt to install the plug-in.
Short-term mitigation
Making updates to your site might take time. If you temporarily need to suggest users view your site in Internet Explorer 10 on the desktop, you can update your site with either a "META" tag or "HTTP" header and Windows Internet Explorer will notify the user and provide an option to switch to the desktop.
HTTP Header
X-UA-Compatible: requiresActiveX=true
META TAG
<meta http-equiv="X-UA-Compatible" content="requiresActiveX=true"/>
Note Keep in mind that the user might be using a device, such as a phone, that doesn't run existing ActiveX controls even in Internet Explorer for the desktop. Some of these devices might also have a small screen and only touch input, which doesn't always work well with ActiveX controls or with the desktop browsing experience. Forcing users into the desktop experience should only be a last resort when no comparable fallback content exists.
Debugging the new Windows UI browsing experience issues
The only difference between how sites behave in the two browsing experiences is plug-in support. If you want to emulate the plug-in free experience in the desktop to debug site issues with the F12 developer tools, enable ActiveX Filtering: "Tools->Safety->ActiveX Filtering".
If you notice other differences in how sites work, make sure to report the issue on Connect.
Building a touch-first site
Internet Explorer 10 on Windows 8 is the first browser to let users choose from a variety of input devices: touch, pen, and mouse. Customers who visit your site in Internet Explorer 10 might have one or more of these input devices. While the Windows 8 UI is designed to provide a great touch experience, some customers might prefer to use a mouse and keyboard, while others prefer to use touch with the familiar desktop experience.
It’s important to not make assumptions about the user's input method. Instead, use feature detection to see what the device is capable of.
Detecting touch input
The following example can help your app decide whether it can provide a touch-first experience or not:
if (window.navigator.maxTouchPoints) {
// user has touch hardware
}
else {
// user does not have touch hardware
}
If you’re interested in the number of touch points available, such as if your game requires a minimum of three touch points, change the detection code to this:
if (window.navigator.maxTouchPoints >= 3) {
// user has at least three touch points
}
else if (window.navigator.maxTouchPoints) {
// user has only one or two touch points
}
else {
// user does not have touch hardware
}