Sharovatov’s Weblog

Windows Phone 7 Internet Explorer IEMobile 7.0

Posted in browsers, IE7, IE8, web-development by sharovatov on 15 March 2010

I’ve just watched MIX keynotes and as soon as MSFT announced there was free VS2010 Express for Windows Phone 7 with proper emulator, I downloaded, installed it, created sample app and ran the debugger.

Here’s some screenshots:

VS2010 Express for Windows Phone IDE:

Untitled-2

Windows Phone 7 Emulator running in the debug mode:

Untitled-1

The most interesting thing for me was to find out which IE version Microsoft decided to ship with Windows Phone 7. They said it wouldn’t be IE9, but would be something between IE7 and IE8. They also assured that the Windows Phone emulator (which comes bundled into the VS2010 Express for Windows Phone 7) is a proper virtual machine, a real copy of Windows Phone OS sandboxed in the VM engine.

So bearing this in mind I thought that I’d test the WP7 IE in emulator.

And here’s interesting stuff:

  1. navigator.appVersion on Windows Phone 7 IE returns
    4.0 (compatible; MSIE 7.0; Windows Phone OS 7.0; Trident/3.1; IEMobile/7.0
  2. User-Agent string is
    Mozilla/4.0 (compatible; MSIE 7.0; Windows Phone Os 7.0; Trident/3.1; IEMobile/7.0
  3. @_jscript_version reports 5.8 (as IE8 does)
  4. [if IE 7] conditional comments section gets applied
  5. *+html selector { rules } hack works

So at this moment IEMobile/7.0 seems to be a slightly adjusted Trident (layout engine) of IE7 and jscript of version 5.8. (as it turns out below, some features are either disabled or not accessible now, or will not be supported at all)

To dive deeper into the details, I’ve tested several things and prepared the following table:

Feature Supports
native XMLHttpRequest Yes
XDomainRequest No
Selectors API Yes
clipboardData No
data URI No
maxConnectionsPerServer No
sessionStorage/localStorage No
offscreenBuffering No
native JSON No
DOM Objects prototypes No
getters/setters No

 

So from the CSS prospective Windows Phone IEMobile 7.0 is indistinguishable from desktop IE7, it applies the same conditional comments rules, supports the same subset of CSS selectors, same hacks work and same bugs are there. If you know how to support desktop IE7 Trident, you won’t have a problem with IEMobile 7.0.

Completely different situation is with javascript – jscript version is 5.8 (same that IE8 has), but many features that IE8 supports via COM wrappers do not exist on IEMobile 7.0 (does it have COM at all?). Also it lacks support for some native features of jscript 5.8 (e.g. native JSON, DOM objs prototypes, getters/settters). The only feature I can see from IE8 is Selectors API support, which is great, but really – is that what we really expected?

So from what I see now, Microsoft took IE7 Trident (3.1), took jscript 5.8 and cut off as much as possible (all COM wrappers and some native features), put IE8 icon on top and shipped it to Windows Phone 7.

I really hoped it would have IE9 or at least IE8.

The only hope is that it’s still beta and all the IE8 stuff will be shipped with the final version. Hope it’s not just a wishful thinking.

It’s such a frustration to see a beautiful and free VS2010 Express for Windows Phone 7, awesome SL4 which runs everywhere, and then look at this crippled “IE7.234”. If this is a marketing choice to make web-developers write in Silverlight, then it’s silly because it breaks the most important feature Microsoft provided – backwards compatibility. Old sites and current sites which Windows Phone users will want to visit will break in this browser. Gmail works in html-only mode. Surely, some will adapt. But not all.

And by the way, Apple got it right on iPhone.

P.S. Todd Brix said there will be a Windows Update-like service in Windows Phone 7, so let’s hope that IEMobile will get updated.

Share :

Tagged with: ,

IE8 Rendering Modes theory and practice

Posted in browsers, css, http, IE7, IE8, web-development by sharovatov on 18 May 2009

Many web-developers moan about the Rendering Modes switch that’s been introduced in IE8. I’ve got some thoughts on this.

Rendering modes switches history

As you may know, IE5 on Mac (followed by IE6 on Windows) introduced Quirks and Standards compliancy modes with a DOCTYPE switcher. All other browsers followed the move and introduced similar approach – they tried to mimic IE behaviour in quirks mode and tried supporting CSS as close to the W3C standard as they could.

DOCTYPE switch approach was really straight forward – if you put a valid DOCTYPE for your HTML page, browser switches to the standards compliancy mode; if DOCTYPE is omitted, quirks mode is used.

This switch was required because many sites were built at the time when even CSS1 was a draft, and for browsers to evolve safely (and add newer standards’ support) without breaking the existing web these old websites were to be rendered properly.

At the time the idea of using DOCTYPE as a rendering mode switcher was fine – almost all pages that had been built without standards support in mind didn’t have DOCTYPE. And if developers wanted to use modern standards, they added HTML or XHTML DOCTYPE and the page was rendered using standard-compliant parser.

Quirks mode and DOCTYPE switch locked old web with old rendering engine, IE5 engine.

I’m not wrong – after IE4 won first browsers war (BW I) nearly all sites were built for IE4 and IE5 only, so all other browsers had nothing to do but copy IE5 behaviour.

It’s important to note that DOCTYPE can only toggle standards compliancy on and off.

Therefore DOCTYPE switch only solves backwards compatibility issue and does nothing to prevent future compatibility issues.

When developers started using DOCTYPE switch, IE6 was a major browser and all the sites were build around its CSS support level. So when IE7 was shipped, it had better support for CSS2.1 but had the same DOCTYPE rendering modes switch.

That’s why many of these websites had rendering issues and had to fix CSS/JS for IE7 specifically. Conditional comments and conditional compilation came to rescue. However, with XP SP3 update IE6 started showing @jscript_version equal to that of IE7 and conditional compilation became pretty useless.

In IE7 old web-sites in quirks mode continued being rendered by IE5 rendering engine, and standards compliancy engine was just an updated version of IE6 standards compliancy rendering engine with some bugs fixed. And while IE7 was a minor update to IE6 but still caused so much trouble, one could imagine what IE8 with proper CSS2.1 support would do to websites. Basically, all the websites with DOCTYPES that were just fixed for IE7 Standards Compliancy mode would break in IE8 again.

Other browsers didn’t have a similar problem, and there’re many reasons to this. First of all, by the time when first IE7 beta was shipped, other browsers had really insignificant market share (so their developers could change anything and wouldn’t be blamed for “breaking the web”), were updated really often and were mostly installed by IT-related people who knew how to update the browser. So DOCTYPE rendering switch was and still is fine for non-IE browsers.

And Microsoft had to solve interesting problem in IE8 – support CSS2.1, support IE7 standards compliancy mode and support IE5 quirks mode. But DOCTYPE can only toggle standards compliancy on or off! They couldn’t drop support for very old but still existing sites build in quirks mode, couldn’t drop IE6 and IE7 support, and couldn’t leave IE8 without proper CSS2.1 support.

So we see that if any browser is locked at some version and this version gains noticeable market share, DOCTYPE switching will not work as vendors will have to choose what to support – older sites or newer features.

And Microsoft found a way – they gave web-developers and users a way to control in which mode sites are rendered.

IE8 Rendering Modes Theory

In IE8 there’re 6 rendering modes:

  • “Edge” Standard compliancy mode
  • IE8 Standards mode
  • “Emulate IE8” mode
  • IE7 Standards mode
  • “Emulate IE7” mode
  • IE5 – Quirks mode

Edge Standard compliancy mode basically tells the browser that it should use the most recent rendering mode – in IE8 it’s “IE8 Standards mode”, in IE9 it will hopefully be “IE9 Standards mode”.

IE8 Standards mode makes browser render a page using IE8 standards compliancy parser and renderer.

Emulate IE8 – DOCTYPE switch will be used to determine whether to use IE8 Standards compliancy mode or IE5 Mode.

IE7 Standards mode

makes browser render a page using IE7 Standards compliancy parser and renderer.

Emulate IE7 – DOCTYPE switch will be used to determine whether to use IE7 Standards compliancy mode or IE5 Mode. If you have a site that’s been built with IE7 Standards compliant mode support and you don’t want to change anything there, just add this META tag or HTTP header and IE8 (and all future versions of IE) will emulate IE7 behaviour, i.e. use IE7 Standards Compliant renderer when DOCTYPE is present and use IE5 mode when there’s no DOCTYPE. So you virtually “lock” your website to a current browser version behaviour. “Emulate IE7 mode” even sets User Agent string to IE7 string and report Version Vector as IE7 (so conditional comments will be evaluated as for IE7).

IE5 Mode – basically, it’s Quirks Mode. If we compare this to DOCTYPE switch approach, Edge mode is similar to a mode when DOCTYPE is set, and IE5 mode – to a mode when DOCTYPE is not present.

To explain modes in more details, I need to show how they are applied.

IE8 Rendering Modes Practice

As I’ve shown above, the whole idea of using DOCTYPE as a rendering mode switch failed because there were more than two types of documents on the web – those that should work in quirks mode, those that should work in IE7 standards mode, those that should work in IE8 standards compliancy mode and those that should work even with future versions of IE. So instead of two types we have three and a half :)

To give a proper way to control this, Microsoft and WaSP invented X-UA-Compatible http header, so you can either configure your server to send this header with corresponding value or add it as META HTTP-EQUIV to your page. For example:

<meta http-equiv="X-UA-Compatible" content="IE=8">

This declaration will tell IE8 to toggle IE8 Standards compliancy mode to render the page.

Here’s a list of modes:

Rendering mode X-UA-Compatible value
Edge Standard compliancy IE=edge
IE8 Standards compliancy IE=8
IE8 Emulation IE=EmulateIE8
IE7 Standards compliancy IE=7
IE7 Emulation IE=EmulateIE7
IE5 Quirks IE=5

 

IE8 Rendering Modes Switches Priority

First and main rule – if you specify X-UA-Compatible header or meta tag, IE8 will use the rendering engine you set.

If it’s EmulateIE7, DOCTYPE switch will be used to determine whether to use IE7 Standards mode or IE5 Quirks mode. See test case with DTD and without DTD.

If it’s EmulateIE8, DOCTYPE switch will be used to determine if it should use IE8 Standards mode or IE5 Quirks mode. See test case with DTD and without DTD.

If it’s IE=8, IE8 Standards Compliancy mode will be used regardless of presence or absence of DOCTYPE. See test case with DTD and without DTD.

If it’s IE=7, IE7 Standards Compliancy mode will be used regardless of presence or absence of DOCTYPE. See test case with DTD and without DTD.

If it’s IE=5, IE5 Quirks mode is used even if there is a DOCTYPE (actually it didn’t matter for IE5 if there was DOCTYPE or not – quirks mode was the only mode it had). See test case.

If it’s Edge, most modern rendering engine is used. For example, IE8 uses IE=8 mode regardless if there’s a DOCTYPE or not and IE9 will use IE=9. See test case with DTD and without DTD.

It’s worthy to note that X-UA-Compatible META overwrites X-UA-Compatible HTTP header, so you can set X-UA-Compatible HTTP header for the whole website and then have X-UA-Compatible META with a different value on some pages.

If website doesn’t have X-UA-Compatible META tag or HTTP header, IE8 uses EmulateIE8 mode i.e. DOCTYPE is used to switch between IE8 standards compliancy mode and IE5 Quirks mode.

This means that everybody needs to add to add X-UA-Compatible header or META to their websites.

Accepting the fact that web-developers wouldn’t update all the websites that were built around IE6/IE7 standards compliancy mode, Microsoft decision to take standards compliancy mode as a default would certainly “break the web”.

So Microsoft had to find a way around this which they successfully did by introducing a bunch of Compatibility View settings.

Compatibility View

As I’ve already said, when developer didn’t care about adding X-UA-Compatible header or META, IE8 works in EmulateIE8 mode and uses DOCTYPE switch to determine which rendering mode to use. If the site hasn’t got a DOCTYPE set, IE5 Quirks mode will be used, so backwards compatibility is not an issue. But if there’s a DOCTYPE, which Standards compliant mode to use? IE7? IE8? IE9 Standards Compliancy mode when IE9 it’s shipped? There’s no automatic way to choose.

And as IE8 Standards mode is a default one, there might be issues on sites that only supported IE6/IE7 Standard modes. Apparently, only user can see if the site he’s viewing has rendering issues. And Microsoft gave users an easy way to switch back to IE7 Standards Compliancy mode if required by clicking on a Compatibility View button (located to the left of refresh button).

image

IE8 will switch to EmulateIE7 mode and save the setting for the domain so all the pages from this domain will be rendered using IE7 engine.

Compatibility View button is shown only when X-UA-Compatible HTTP header or META is not set.

Also during IE8 install a user can specify if he wants to use Compatibility View List feature. Basically, when this feature is turned and user clicks Compatibility View button while browsing, IE8 reports to Microsoft that the website on this domain required user to press the Compatibility View button.

If statistics show that users tend to press Compatibility View button for the site, it’s included in iecompatdata.xml file which fresh copy is distributed with Windows Update. It can be viewed by typing res://iecompat.dll/iecompatdata.xml into the address bar.

So when Compatibility View List feature is enabled and there’s no X-UA-Compatible HTTP header or META, and DOCTYPE is present, IE8 will look if the site is in the res://iecompat.dll/iecompatdata.xml file and make Compatibility View button pressed by default.

As soon as the site gets X-UA-Compatible header or META tag, IE8 will use the rendering mode from its value and won’t even check Compatibility View List and also Compatibility View button won’t show at all.

Local Intranet security zone

Intranet differs from Internet a lot.

If Compatibility View List feature will work fine for public internet websites, Intranet sites should not be reported anywhere. So what rendering engine to use when there’s no X-UA-Compatible value and DOCTYPE is present? IE7 Standards Compliancy? IE8 Standards Compliancy?

Intranet a controlled environment where to decrease support costs IT pros usually set everybody with same set of software. As most successful companies use Microsoft technologies as a core of their IT infrastructure and because only IE has been providing a decent platform for building powerful intranet web applications, IE was always a de-facto standard browser in companies.

Many intranet web applications were targeting IE5.5/6.0 and nobody cared to refactor to get standards compliancy – why bother if there was always only one browser supporting a well-known list of technologies so cross-browser interoperability was never an issue? We can argue if this approach is good or not – but IE8 team had thousands of intranet applications they had to support. That’s why compatibility view was the only option for sites from Local Intranet security zone.

If the site is in the Local Intranet zone and there’s no X-UA-Compatible header or meta tag, DOCTYPE switch is used to determine which rendering engine to take – IE7 Standards compliancy or IE5 quirks mode.

If there’s no X-UA-Compatible value and site is in Local Intranet security zone, it will be rendered in EmulateIE7 mode by default.

Compatibility View button is not displayed at all.

But as soon as a developer adds X-UA-Compatible header or META, site will start working in the specified mode.

Developer Tools

With great set of developer tools that Microsoft provided for IE8 you can also view what rendering is being used and change it if required. This is useful for developers only and overrides any other settings. It’s very useful for testing – you don’t need IE7 in a virtual machine to test how a page looks in IE7 – just press F12 to get the developer tools and play with Browser modes or Document modes :)

Hope I managed to cover all the modes. In future posts I’ll write more on this topic.

P.S. As SelenIT pointed in comments, it’s very important that X-UA-Compatible meta tag must be put before any other elements in the head section, otherwise it might not work!

Share:

Weird bug with hiding columns in IE7

Posted in css, IE7, IE8, javascript by sharovatov on 14 April 2009

Sometimes when you create a table, you need to dynamically toggle certain columns visibility. I usually use the following approach:

  1. Set those columns that are supposed to be hidden and shown with a className, e.g. tohide
  2. Set their parent with some className, say, hiddenChildren.
  3. Define the following CSS rule: .hiddenChildren .tohide { display: none }, which basically says that if there is a parent node with className="hiddenChildren" and it has child nodes with className="tohide", all these child nodes will be hidden.
  4. When I need to show cells, I remove this hiddenChildren class from parent’s className, and when I need to hide them again, I add it back.

This is a very common scenario and it’s much more efficient than the approach where you go through all the elements in javascript and toggle their personal display mode.

There’s also an inverted approach where by default elements are hidden and assigned class specifies positive display – table-cell for CSS2.1-compliant browsers and block for IE6. But my approach is better as it’s cleaner – there’s no need for IE6-specific code (usually assigned by star hack).

However, in IE7 with both of the approaches the cells’ display is not switched as you may notice by viewing the testcase.

But as in most cases, there’s a workaround – you have to “poke” any TH of your table. In this testcase I added the following code:

/*@cc_on if (!document.querySelector)
    document.getElementsByTagName('th')[0].className = 'wt2'; @*/

to the toggling function. As you may know, js code within /*@cc_on … @*/ block will be executed only by IE, and only IE8 has support for document.querySelector interface, so chances are that this code will be executed only in IE with version earlier than 8, which is precisely what we need (as IE8 doesn’t have this problem).

It’s interesting to know, that YUI Team in their DataTable control in order to implement hiding/showing functionality choosed to loop through all the cells and set their display individually (see hideColumn/showColumn functions here). I understand that this is the bulletproof approach ready to use in any environment, but it can be rather ineffective when your table has a significant amount of rows as it will have to go through all the TR’s. And it will do the loop twice if you choose to hide two columns :) Of course, using my approach requires setting classes for those cells that you were going to hide, so it’s not that flexible, but in the controlled environment it’s definitely the best option.