Windows 8 will have two versions of Internet Explorer 10: a conventional browser that lives on the legacy desktop, and a new Metro-style, touch-friendly browser that lives in the Metro world. The second of these, the Metro browser, will not support any plugins. Whether Flash, Silverlight, or some custom business app, sites that need plugins will only be accessible in the non-touch, desktop-based browser.

Should one ever come across a page that needs a plugin, the Metro browser has a button to go to that page within the desktop browser. This yanks you out of the Metro experience and places you on the traditional desktop.

The rationale is a familiar one: plugin-based content shortens battery life, and comes with security, reliability, and privacy problems. Sites that currently depend on the capabilities provided by Flash or Silverlight should switch to HTML5.

Microsoft has been vigorously promoting HTML5 for the last year and a half as the best way of providing rich interactivity on the Web. HTML5 potentially has reach far beyond that of Flash, since it can target both conventional browsers and closed ecosystems (such as iOS) alike. However, until now, Microsoft's messaging has been tempered somewhat: use HTML5 when you can, but if you can't—if you need support for DRM-protected media streaming, for example—then it's reasonable to switch to an alternative, plugin-based technology.

With Windows 8, however, those reasonable decisions to use Flash or Silverlight will now be heavily penalized. Technically, there's nothing wrong with the desktop browser, of course; the rendering engine and performance will be identical between both Metro and desktop. But the experience will be substantially inferior. The desktop browser isn't designed for touch inputs, meaning that users will either have to switch to a mouse and keyboard, or fumble around with an interface that wasn't built for fingers. The switch to the desktop browser also appears to discard things like back button history and current page state.

This puts the Metro browser in a peculiar position. Microsoft has positioned tablets as merely a different kind of PC. That, the company argues, affords capabilities and features not possible on iPad-style devices. But PCs have browser plugins—more generally, they have the ability to use the right technology for the job. If Metro doesn't include that flexibility, that could be seen as diminishing the "PCness" of the platform.

HTML5 still isn't a total replacement for plugin technologies, either. The gap is certainly narrowing: Web Sockets, Web Workers, built-in support for webcams and microphones, and more, are all coming to HTML5 browsers (or are available already), and these features will obviate the need for plugins for many applications. But certain corners are likely to remain; DRM-protected video, for example, might forever be impossible in HTML5, and while many people find DRM distasteful, many broadcasters feel they have little choice but to use it.

The solution to this conundrum on the iOS platform has been the app: companies like Netflix and the BBC have applications to watch video on these devices. The result is that in the desire to push an open, plugin-free Web, companies are being forced to migrate away from the Web entirely. Silverlight developers, at least, will have an easy migration path available to them: the new Metro development environment, used for producing native Metro applications, borrows heavily from Silverlight, and making the switch from an in-browser plugin-based application to a standalone Metro application should be relatively easier. Flash developers will have to wait to see what tools Adobe delivers.

HTML5 design and developer tools also remain weak, though this situation is improving with the creation of products like Adobe Edge.

With Microsoft's promotion of HTML5, and the precedent set by iOS, the decision to get rid of plugins in the Metro browser is perhaps unsurprising. But it's not clear that this will truly help Windows 8; the awkward user experience penalizes users who, for no fault of their own, need to use plugins, and detracts from Windows 8's PC claims. A switch to a more HTML5-powered Web will happen regardless—does Microsoft really need to force the issue like this?