Internet Explorer 10 is a fast browser with good standards compliance, and the version of Internet Explorer 10 included with Windows Phone 8 is no exception, as it's almost identical to its desktop sibling. But Internet Explorer 10 has a problem: Web developers don't expect to see it on the mobile Web. The mobile Web is dominated by WebKit-based browsers, and mobile sites tend to be developed exclusively for, and tested exclusively on, WebKit browsers. A similar problem exists for tablets.
Often the development is even narrower; although both Android and iOS sport WebKit-based browsers, iOS is the one that dominates mobile browser usage, and dominates testing as a result.
This situation is all rather familiar; WebKit, especially on iOS, is occupying a similar position to that once held by Internet Explorer 6 on the desktop, where Web content was "best viewed in Internet Explorer 6" and was prone to breaking in Netscape or Firefox.
Keen to avoid being left out, Microsoft is imploring Web developers to adapt their sites. In a recent blog post, the software giant explains a variety of ways in which devs can update their sites to work well in browsers other than WebKit. Key to this was proper handling of incompatible features.
There are several sources of incompatibility. The hardest case is features that are simply proprietary to WebKit; these need to be worked around in some way or other.
Most other cases are a result of the standardization process used for Web specifications. When a CSS or JavaScript specification is under development and still subject to change, browsers implementing it are supposed to add a browser-specific prefix to the pieces of CSS or JavaScript they use. So for example, while still in development, WebKit's implementation of CSS rounded borders should use properties like -webkit-border-radius. Once the standard is stable and a browser is implementing that stable standard, the property should be renamed to simply border-radius.
For some standards, both browsers implement the stable version, without any prefix required. However, developers often fail to update their pages to accommodate this improving standard conformance, leaving their pages using prefixed properties, but not including equivalent unprefixed code. In this case, the solution is typically to remove the prefixes. Sometimes, the spec still isn't stable and the different browsers implement mutually incompatible versions of the spec, each with their own prefixes. In this case, the properties must be translated from one dialect to the other.
There are also some cases where the translation is more complex still, particularly when it comes to handling touch input. Apple pioneered work in this field in Safari, and a specification called Touch Events based on Safari (but created without Apple's involvement) is currently a Candidate Recommendation from the World Wide Web Consortium (W3C), the body that works on producing Web standards. Microsoft has proposed an alternative system called Pointer Events which would handle not just touch but also mouse and pen input in a consistent way. For both technical and legal reasons, W3C has decided that rather than work on Touch Events version 2, all future development in this area will be to Pointer Events.
The problem for developers is that WebKit supports Touch Events; Internet Explorer 10 supports a prefixed version of Pointer Events. Translating between the two should be broadly possible, but there are nuances to this; it's not simply a case of doing a quick search and replace.
For those who remember the Internet Explorer of the late 1990s and early 2000s, Microsoft's stance may seem a little amusing—the company wasn't so bullish on following standards back when it commanded more than 90 percent of the browser market share. Redmond has been banging the "use standards" drum for some years now, and has been actively participating in standard development and stabilization.
reader comments
255