IEBlog

IE Compatibility List Pruning

2009-07-01T21:31:00Z

Hi, I am Michael Benny, a tester on networking in Internet Explorer. During the Internet Explorer 8 development cycle I was responsible for verifying many of the pieces of Compatibility View. We have discussed earlier about how the Compatibility View feature works and the steps a site author can take to ensure the Compatibility View button never displays for IE8 users visiting your site. There is another scenario that we have not yet covered, if my site was already added by an End-user to their Compatibility View list before my site was updated, and now it’s ready, how would I get the site off of that user’s list? I wanted to share one particular feature that we haven’t blogged about before – the ability to “trim” domains from a user’s Compatibility View list.

As a quick refresher on Compatibility View, Internet Explorer 8 uses its most standards-compliant rendering behavior by default. This configuration may cause problems with websites that expect the older, less interoperable behavior from IE. As a site administrator, you have a number of tools at your disposal to ensure IE8 clients have a compatible experience with your website – taking advantage of the standards improvements in IE8 or using the X-UA-Compatible header to tell IE8 “display content as IE7 would have” being the two most common options site authors have requested.

End-users also have a way to mitigate compatibility issues they may encounter in the course of normal browsing on sites that do not have the X-UA-Compatible option explicitly set. They can choose to view a site in Compatibility View, an IE7 emulation mode, by toggling a button on the browser’s address bar. Internet Explorer 8 remembers Compatibility Button presses on a per-domain basis in order to provide a more seamless return-visit experience. These domains are stored in a registry location on the client at HKCU\Software\Microsoft\Internet Explorer\Browser Emulation.

When a site is in a user’s Compatibility View list, the default document rendering behavior will be set to IE7 Emulation mode and it will affect the User Agent String used to request pages. As a site admin, you are always in control of how your site is displayed. Using the X-UA-Compatible tag, you can override Compatibility View on the client and dictate the exact rendering mode your site should be displayed in. Site admins also have the option to deploy the X-UA-Compatible header for a large section of pages as an HTTP header (Example: IIS and Apache). You can take this one step further by using the X-UA-Compatible to also remove your domain’s entry from the user’s Compatibility View list. Here’s how…

For a domain to be trimmed, the End-user must first land on a page with the X-UA-Compatible Meta tag or HTTP Header. The presence of an IE8 <META> tag does indeed trigger the list clean-up process, but that’s not all there is to it. The next step is to look for a file called ‘IEStandards.xml’ placed at the domain root. IE will first make an HTTP HEAD request for this file looking for its presence. Absence of the file means that the domain remains in the user list. If the HEAD request is returned successfully, then IE will perform an HTTP GET request for the file. In the file, a tag called ‘IE8StandardsMode’ signals the list entry is really ready to be trimmed. Here is an example of the correct server configuration for ‘example.com’:

Set the page X-UA-Compatible header set to a value indicating IE8 mode
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8">
Place a file at the root of the domain ‘example.com’
http://example.com/IEStandards.xml
The file should have a root XML element called IE8StandardsMode:
<IE8StandardsMode/>

Site admins should be aware that this affects all sub-domains. So if a user visits a page at ‘support.example.com’, which is configured as shown here, but there is another sub-domain like ‘mail.example.com’, which would still like to respect the user’s choice to put the site into Compatibility View, then the ‘mail’ sub-domain will use IE8 Standards mode rendering.

The entries on the Compatibility View list reflect an entire domain, example: ‘example.com’, rather than subdomains like ‘mail.example.com’ and ‘support.example.com’. IE must process the request to trim the domain entry from a source that represents the entire domain, otherwise side effects to subdomains may occur. As an example, suppose the entire ‘example.com’ domain is on the user’s Compatibility View list. Later, ‘support.example.com’ does great work to update their site to support IE8 and includes a HTTP header / <META> tag indicating that portion of the site is best viewed in IE8 Standards Mode. ‘example.com’ and ‘mail.example.com’ have still not been updated. If IE were to remove the entry for ‘example.com’ from the user’s list based solely on the presence of the HTTP header / <META> tag value found at ‘support.example.com’, the user could encounter a compatibility failure when they visit non-updated content at ‘example.com’ or ‘mail.example.com’. Checking for the ‘IE8StandardsMode’ file at the root domain level solves this case by requiring that someone “authoritative” for the domain signal list cleanup. That way, IE users can be assured of a consistent compatibility experience on the domain.

Getting the IEStandards.xml file follows a very similar model to how IE will request favorite icons for domains, but we wanted to address the issue of server overhead. To avoid IE8 making multiple and unnecessary requests to a server for this file on every page navigation with the X-UA-Compatible option set, there exists a 30 day timeout period since the last request. This 30 day timeout period is also set when a user adds a domain to their user list, so do not be alarmed if you still see IE8 Compatibility View requests after deploying the file to the domain root.

Thanks,
Michael Benny
IE Test

Update 6/4/09: Correcting a reference to IESettings.xml which should be IEStandards.xml

IT Professionals: Prepare for Internet Explorer 8 availability via Windows Server Update Services (WSUS) in August 2009

2009-06-29T20:01:00Z

For those of you who manage your organization’s desktops using Windows Server Update Services (WSUS) Internet Explorer 8 will be made available via this technology starting August 25, 2009. Internet Explorer 8 will be made available as an “Update rollup” and will be applicable to all supported languages.

Is my organization affected?

If your organization uses WSUS and has it configured to auto-approve Update rollup packages, upon acceptance of the Internet Explorer 8 End User License Agreement (EULA) by the WSUS administrator, Internet Explorer 8 will install automatically on computers running Internet Explorer 6 or 7 on supported operating systems.

What should I do if I auto-approve Update rollups but want to control when I deploy Internet Explorer 8?

To give you control over how and when Internet Explorer 8 is deployed in your environment, perform the following steps:

Before August 25, 2009:

Turn off auto-approve for “Update rollup” packages in WSUS, and approve the updates manually. Note: Even if Auto-Approve for “Update rollup” is on, you will still be required to approve the Internet Explorer 8 EULA before Internet Explorer 8 is deployed to downstream clients.

After August 25, 2009:

Synchronize your WSUS server.
Decline the Internet Explorer 8 update packages.
If you typically auto-approve update rollup packages, you can re-enable automatic approval for “Update rollups.”

What other Internet Explorer 8 updates will be available via WSUS?

Cumulative security updates for Internet Explorer 8 and Internet Explorer 8 Compatibility View List updates will also be released via WSUS as they become available.

To deploy Internet Explorer 8 today, visit the Internet Explorer TechNet Center – among other useful resources you’ll find an Internet Explorer Deployment Guide and information about the Internet Explorer Administration Kit which explains how to generate a MSI installer and distribute it using Systems Management Server or Group Policy.

Eric Hebenstreit
Lead Program Manager

IE8 is now available on Windows XP for 5 more languages

2009-06-26T21:27:00Z

We are pleased to announce the availability of Internet Explorer 8 on Windows XP for 5 additional languages today. These languages were tagged as “Coming Soon” in our blog post early June. Please visit our World wide sites page to download Internet Explorer in your preferred locale/ language.

Languages newly available on Windows XP:

For reference, here’s a table with the full list of IE8 availability:

LANGUAGE	Windows Vista		Windows XP		Windows Server 2008		Windows Server 2003
	x86	x64	x86	x64 PRO	x86	x64	x86	x64
	x86	x64	x86	x64 PRO	x86	x64	x86	x64
Arabic	Available	Available	Available	-	Available	Available	Available	-
Chinese (Traditional)	Available	Available	Available	Available	Available	Available	Available	Available
Chinese (Simplified)	Available	Available	Available	Available	Available	Available	Available	Available
Chinese (Hong Kong)	Available	Available	-	-	Available	Available	-	-
Czech	Available	Available	Available	-	Available	Available	Available	-
Danish	Available	Available	Available	-	Available	Available	Available	-
Dutch	Available	Available	Available	-	Available	Available	Available	-
English	Available	Available	Available	Available	Available	Available	Available	Available
Finnish	Available	Available	Available	-	Available	Available	Available	-
French	Available	Available	Available	Available	Available	Available	Available	Available
German	Available	Available	Available	Available	Available	Available	Available	Available
Greek	Available	Available	Available	-	Available	Available	Available	-
Hebrew	Available	Available	Available	-	Available	Available	Available	-
Hungarian	Available	Available	Available	-	Available	Available	Available	-
Italian	Available	Available	Available	Available	Available	Available	Available	Available
Japanese	Available	Available	Available	Available	Available	Available	Available	Available
Korean	Available	Available	Available	Available	Available	Available	Available	Available
Norwegian	Available	Available	Available	-	Available	Available	Available	-
Polish	Available	Available	Available	-	Available	Available	Available	-
Portuguese (Portugal)	Available	Available	Available	-	Available	Available	Available	-
Portuguese (Brazil)	Available	Available	Available	-	Available	Available	Available	Available
Russian	Available	Available	Available	-	Available	Available	Available	Available
Spanish	Available	Available	Available	Available	Available	Available	Available	Available
Swedish	Available	Available	Available	Available	Available	Available	Available	Available
Turkish	Available	Available	Available	-	Available	Available	Available	-
Bulgarian	Available	Available	Available	-	Available	Available	-	-
Croatian	Available	Available	Available	-	Available	Available	-	-
Estonian	Available	Available	Available	-	Available	Available	-	-
Latvian	Available	Available	Available	-	Available	Available	-	-
Lithuanian	Available	Available	Available	-	Available	Available	-	-
Romanian	Available	Available	Available	-	Available	Available	-	-
Serbian (Latin)	Available	Available	Available	-	Available	Available	-	-
Slovenian	Available	Available	Available	-	Available	Available	-	-
Slovak	Available	Available	Available	-	Available	Available	-	-
Thai	Available	Available	Available	-	Available	Available	-	-
Ukrainian	Available	Available	Available	-	Available	Available	-	-
Albanian	Available	-	Available	-	-	-	-	-
Assamese	Available	-	-	-	-	-	-	-
Basque	Available	-	Available	-	-	-	-	-
Bengali (Bangladesh)	Available	-	-	-	-	-	-	-
Bengali (India)	Available	-	Available	-	-	-	-	-
Bosnian (Cyrillic)	Available	-	Available	-	-	-	-	-
Bosnian (Latin)	Available	-	Available	-	-	-	-	-
Catalan	Available	-	Available	-	-	-	-	-
Gujarati	Available	-	Available	-	-	-	-	-
Hindi	Available	-	Available	-	-	-	-	-
Indonesian	Available	-	Available	-	-	-	-	-
Kannada	Available	-	Available	-	-	-	-	-
Kazakh	Available	-	Available	-	-	-	-	-
Konkani	Available	-	Available	-	-	-	-	-
Kyrgyz	Available	-	-	-	-	-	-	-
Macedonian	Available	-	Available	-	-	-	-	-
Malay (Brunei Darussalam)	Available	-	-	-	-	-	-	-
Malay (Malaysia)	Available	-	Available	-	-	-	-	-
Malayalam	Available	-	Available	-	-	-	-	-
Marathi	Available	-	Available	-	-	-	-	-
Oriya	Available	-	-	-	-	-	-	-
Punjabi	Available	-	Available	-	-	-	-	-
Serbian (Cyrillic)	Available	-	Available	-	-	-	-	-
Tamil	Available	-	Available	-	-	-	-	-
Telugu	Available	-	Available	-	-	-	-	-
Uzbek (Latin)	Available	-	-	-	-	-	-	-
Vietnamese	Available	-	Available	-	-	-	-	-

Thanks,
Vishwac Sena Kannan,
International Program Manager | Internet Explorer.

Declaring Security

2009-06-25T18:45:00Z

Recently, a number of people have asked me what I think about Mozilla’s Content Security Policy draft spec. Back in January, I went on record as being someone who thinks that CSP is a good idea.

CSP is a mechanism for declarative security, whereby a site communicates its intent and leaves it up to the user-agent to determine how to enforce it.

There are a number of benefits to declarative security mechanisms:

Reduced compatibility risks. Because sites must opt-in and declare what, if any, restrictions they want, new security features may be added to the user-agent with decreased compatibility fallout.
Clear intent. By plainly declaring which restrictions are desired, browsers need not try to “guess” the site’s intent. For instance, when explaining that frame-breaking JavaScript cannot be relied upon to prevent ClickJacking, Kymberlee noted:

If you don’t design something to prevent a security vulnerability, odds are that it doesn’t do a very good job of doing it.

Because declarative security features are designed solely to mitigate security threats, browsers may implement the restrictions however they want, and can patch any holes found in the restrictions without unexpectedly breaking unrelated functionality.
Usability. By allowing a site to declare its security policy, browsers can make some security decisions on the user’s behalf.
Auditability. It is straightforward to build tools that scan content for policies and determine if they meet the publishing organization’s expectations.

Internet Explorer has a rich history in this space: HTTPOnly, SECURITY=RESTRICTED frames, X-Content-Type-Options, X-Download-Options, X-Frame-Options are all declarative security mechanisms first implemented in IE, and now supported by other browsers to varying degrees.

The ideas behind the CSP draft are not new, and it is but one of many proposals for declarative security, from BEEP to HTML5 sandboxing. In some respects it overlaps with other mechanisms for restricting script, although if CSP is successful, new directives will likely be created to provide uniform specification of the available policies.

While valuable, declarative security mechanisms are not without their challenges:

Plugins. Unless plugins have been blocked outright, they must be aware of, and enforce, the declared security policies. Because plugins are provided by many different vendors, this requirement may prove challenging in real-world deployments.
Misconfiguration. CSP is only as valuable as the policies configured by the developer or administrator, and a number of major sites have suffered breaches due to misconfiguration of security policy files. Ira Winkler claims [p143] that government studies indicate that 70% of computer intrusions are a result of configuration problems.
New attack surface. The very mechanisms used to implement CSP will be probed by hackers, and comprehensive fuzzing and penetration testing will be required to help mitigate the attack surface added. Furthermore, if a hole is found that enables an attacker to circumvent a given policy within a given user-agent, that user-agent’s reputation may be harmed-- even if other user-agents do not attempt to support that policy.
Debuggability. Web developers already face significant challenges in developing their pages, and introducing new security policies will require that tools be updated to clearly indicate when content has been blocked due to security policies. Sites might inadvertently set overly restrictive policies and failure to catch mistakes via comprehensive testing could lead to a confusing user experience.
Dynamic content. It may prove difficult to author workable policies for some dynamic-content scenarios (e.g. email composition, blog authoring, etc) because the user may herself add content to a given page from origins unknown to the web developer.
Adoption. Perhaps the biggest challenge for CSP and competing proposals is related to the fact that they offer “off-by-default” security. While this is great for compatibility, it’s not-so-great for protecting sites and users, because benefits are only attained after web developers update their sites. To succeed, CSP must balance power/flexibility against simplicity/understandability.

No security technology is a panacea, and for comprehensive protection, I think browsers need to offer both:

Rich security APIs that enable sites to prevent XSS attacks.
Automated protections to shield sites that can’t/won’t update their code immediately / ever.

To combat XSS attacks, IE8 introduced a number of attack-surface-reductions, a few new APIs, as well as the declarative security mechanisms (X-* headers) mentioned above. But we knew that sites wouldn’t immediately adopt these APIs and declarative security features, so we built the XSS Filter, an on-by-default, no-questions-asked, no-code-changes required mechanism which helps mitigate the most common types of XSS attacks in the wild today.

I’m eager to see the progress on CSP, which I believe is a promising approach to helping websites secure themselves against the growing alphabet soup of web threats. You can provide feedback on the CSP draft spec using Mozilla’s Talk page.

-Eric Lawrence

How we used user research data to help design Compatibility View

2009-06-19T21:00:00Z

There have already been a few posts on Compatibility View in Internet Explorer 8 (here, here, here, here, here, and here), but none have gone into detail about the user research data we used to help design this feature. We collected data on Compatibility View throughout the IE8 beta releases and have made multiple decisions about its design based on our data from lab studies, field studies, instrumentation, and community feedback. What I’d like to do is go through some common questions we’ve received about the user experience of Compatibility View, and explain how user data has influenced our decisions. Hopefully, this will give you some insight into our design process and how we use data to make feature design decisions.

Current design

So that we’re on the same page, let’s do a quick review. The current design places the Compatibility View button at the end of the Address Bar, next to the Refresh button in the default layout, on sites that do not include the compatibility meta tag or HTTP header. The button has a “page” icon on it. The first two times a user is on a page with the button visible and refreshes the page, a notification balloon will pop pointing to Compatibility View.

Now that we’ve reviewed the design, let’s look at some of our top questions.

Why put the icon next to the Refresh button?

One of our top concerns with Compatibility View has always been its discoverability. If users can’t find this feature, they could have a severely compromised experience. When we first tested Compatibility View in our user research labs, it was a button on the Command Bar named “Emulate IE7.”

To test it, we created a task in which participants were asked to use a site that we knew would be unusable before switching to Compatibility View. When they arrived at the site and found it unusable, we asked them, “What would you do if you came to a site that looked like this?” The most common response by far was to click the Refresh button. After probing deeper into why people would try to “fix” a page in this way, most responses focused on a specific incident in the past where the participant had seen a page that was “off” somehow and refreshing the page had fixed the issue. Another common response was to look for something in the Tools menu.

Side note: We use the term “fix” a page in this article a lot because that is how our participants referred to what they were doing. We know the technical accurateness of this term is debatable in a lot of cases but we’re sticking with how our participants thought about the scenarios.

Almost no one thought to use the “Emulate IE7” button, even though they had seen an explanation of it earlier in the session. The main problem was that the word “Emulate” had little to nothing to do with “fixing” sites to our participants. It was a technical description of the feature instead of describing what the user was looking for in these situations. Also, we knew that the problem wasn’t that it didn’t stand out enough. I mean, it was a BIG button that was totally new in the Command Bar. Our problem wasn’t that it didn’t catch user’s eyes, it was that it didn’t fit into user’s mental models.

Based on this data, we knew that the majority of users will likely look to the Refresh button when they encounter a page that needs to be “fixed.” To take advantage of this natural tendency, we place the Compatibility View button next to the Refresh button – next to the most likely place a user will look when a page looks “off.” Additionally, to catch the small percentage of users who we expected to look in the Tools menu, we added a link there as well.

Why use that icon?

We knew that having a button with a name as long as “Emulate IE7” was not going to work being placed next to the Refresh button. It would take up too much space and we already knew that the idea of emulating IE7 in IE8 was strange for most users. We brainstormed and developed a series of potential icons that could work for Compatibility View. One challenge we faced was that communicating what Compatibility View does with only an icon is quite difficult. We tried various iterations such as showing blocks misaligned, representing areas of the page that could be out of alignment. These versions were too abstract to communicate the general idea and often it’s not a case of elements being misaligned (e.g., menus might have the wrong background color). We decided on the “page” icon because this correlated best with how participants were describing the pages that were not rendering correctly (e.g., “broken”, “screwed up”).

In refining the final design, we worked to make it fit as part of our family of icons in the address bar, including stop, refresh and go. We tried options that had different colors and textures for the page but found the page white design was most recognizable as a “web page”. We used the same colors, line weights and gradients present in the other icons to “ground” the icon to the overall address bar design.

When we tested the icon in the lab, we found that the majority of participants understood that the icon had something to do with the page with a problem they were looking at. Seeing the icon led most people to read the tooltip that explains the feature. After reading the tooltip, we saw many positive reactions to the icon and that it made sense given what the feature does.

Some reviewers felt that showing this icon on pages that were potentially fine would confuse users and make them think that the page was broken somehow, but we saw no indication of that in our studies. Participants did not even look toward the Compatibility View button unless they were in situations where it could potentially help them, which was one of our design goals.

Will people understand what it’s for?

We expect most users to understand Compatibility View and when to use it. Of our lab participants who read the Compatibility View tooltip, the notification balloon, or tried the feature, all have understood the feature’s purpose. Most importantly, everyone who understood the the feature, continued to use it on the sites they encountered that had issues. This was true for our lab participants and also for our field research participants.

Why have balloon notifications?

After a few rounds of testing in the lab, and getting feedback from participants in our field research, we still saw some participants didn’t notice the Compatibility View button, even after they hit Refresh on a page with layout issues. Quite naturally, they got into an automatic pattern of quickly clicking Refresh and then putting their eyes right back to the page content to see if it fixed their problem. We had an important decision to make--do we add some kind of notification that lets the user know about Compatibility View when it could help them? The upside is that more people who would benefit from Compatibility View will find it. The downside is that we are adding another notification to the system.

We tested a build with the notification balloons in the lab and in our field research and found that displaying a balloon did in fact help more people discover Compatibility View. We didn’t take the decision lightly but felt the added awareness was worth the added notification.

Why have two balloon notifications?

Originally the balloon notification only showed once when a user refreshed a page displaying the Compatibility View icon for the first time. As I mentioned above, even showing this once was a strongly-debated decision. But, there were many concerns that once was not enough so we tested the possibility of showing the notification up to three times (after the first three times someone refreshed a page displaying the Compatibility View icon).

In the lab, we showed participants from one to three different sites with layout or content problems. At each site we asked them what they would do if they came to a site like this. Most clicked Refresh as we expected. What we found was that of people who saw the notifications, about two thirds reacted to the first notification and the other third reacted to the second notification. Showing the second notification caught the attention of a group of people who were very focused on the content of the page at the first site but were more likely to notice things outside of their normal pattern at the second site.

There was also a group who saw all three notifications and dismissed or ignored them all. We believe these users would not pay attention to the notification no matter how many times we showed it. This lead us to not show the notification three times “to be safe” because we had no evidence that showing the notification more than two times will catch any additional users and there is a real cost to over communicating with users (e.g., data in the recent e7 blog post about Action Center).

Conclusion

I hope this gives you some insight into how we as an engineering team use user research data to make some of our design decisions. As you can see, a lot of time, research, and deliberation can go into a feature (and this was just a summary, I didn’t even get into our instrumentation data). We always want to base important decisions on the best data possible and that includes data from the lab, field, instrumentation, and community feedback. If you’d like to find out more about user research at Microsoft, please check out our user research website.

Jess Holbrook
User Experience Researcher

Ben Truelove
User Experience Designer

Compatibility View and "Smart Defaults"

2009-06-18T01:39:00Z

I’ve mentioned in several previous posts how Internet Explorer 8 displays pages in its most standards compliant mode by default – a configuration that emphasizes interoperability. This creates some challenges with regards to compatibility with existing web content.

Some of today’s web pages expect the older, less interoperable behavior from IE and, as a result, don’t necessarily work as expected in IE8’s standards-by-default mode. To address this, we built features like Compatibility View and the ‘EmulateIE7’ X-UA-Compatible tag – features that users and web developers can enable to make the browser more compatible with existing content. This post is about some situations where IE uses smart defaults to provide users with a more compatible out-of-box experience.

Many sites found on corporate intranets (read: the local network, like http://myPortalSite) are Internet Explorer 7 capable today and expect “IE” to act like IE7. In order to preserve compatibility with these line-of-business websites and applications, IE8 defaults to Compatibility View when displaying content in the ‘local intranet’ zone. An exception to this is ‘Localhost’ and the loopback address (e.g. 127.0.0.1 + IPv6 equivalent). These addresses display in IE8 Standards Mode by default in order to meet the needs of web developers and designers who often test pages meant for Internet consumption (where IE8 Standards is the default) on local web servers.

Users can override the ‘local intranet’ setting by un-checking ‘Display intranet sites in Compatibility View’ at Tools -> Compatibility View Settings.

IT Admins can configure this setting via Group Policy. IT Admins can also configure and maintain a list of sites, both intranet and extranet, that are best viewed in Compatibility View. Using that policy in conjunction with the ‘local intranet’ policy configured to “off”, e.g. IE8 Standards on the intranet, enables organizations to gradually transition infrastructure pieces from IE7 Standards to IE8 Standards.

Another place where IE uses smart defaults is WebOC layout modes. There are many Windows applications both past and present that use the WebBrowser control, aka Trident. CorelDraw Graphics Suite, Encarta, Microsoft Office, and Nero are just a few examples. As you might expect, updating software that the user has installed on their machine is complex (e.g. developer has to write an updating system, user has to opt-in, user has to get and install the update, etc…). This can be particularly hard for “boxed” software, which often times is even more costly to update than a “live” web application due to the software distribution method - CDs / DVDs on store shelves vs web download. Like web applications, these Windows applications may assume a particular behavior set from Internet Explorer. In order to maintain compatibility, applications using the IE8 WebOC display pages in Compatibility View by default. Applications can enable IE8 Standards Mode by setting the following registry value:

[(HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE)\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"MyApplication.exe" = dword 8000 (Hex: 0x1F40)

Finally, there are cases around “hard asserts” that cause IE to switch into Compatibility View. For those not familiar with the concept, Wikipedia does a good job covering the basics -

An assertion may be used to verify that an assumption made by the programmer during the implementation of the program remains valid when the program is executed.

…

A major advantage of this technique is that when an error does occur it is detected immediately and directly, rather than later through its often obscure side-effects. Since an assertion failure usually reports the code location, one can often pin-point the error without further debugging.

When we built the brand-new layout engine included in IE8, we used a standard practice of instrumenting common code paths with assertion logic. This instrumentation was invaluable during IE8 development as it served to highlight areas of faulty logic or invalid assumptions made during the implementation of the new layout engine. As an example, the original implementation of some sizing algorithms assumed ‘consumed height’, an internal construct tracking the actual height taken up by an object, could not be negative. This assumption turned out to be false as one can reach the condition through certain top margin values. An assertion that bounded consumed height’s acceptable values allowed us to identify and correct the error.

For the most part, we’ve removed assertions from our retail code. That said, there are particular code paths within the new layout engine where, should an error occur, the layout process can’t gracefully recover and we’ve kept assertions around these paths. In the IE8 Beta builds, encountering one of these layout “hard asserts” caused IE to display a blank page - the thought process being that it was better to show the user nothing at all than allow interaction with a corrupt or otherwise obviously incorrectly displayed page. We refined this experience further in the released version of IE8 by recovering layout “hard asserts” using Compatibility View. In other words, we believe that showing a page the way IE7 would have offers a better user experience than showing no content at all.

A new InetCPL setting at Tools -> Internet Options -> Advanced -> Browsing enables / disables auto-recovery.

On error, the entire domain recovers into Compatibility View, not just the page or sub-section of the site. This mirrors the current experience when users press the Compatibility View button and prevents a case where the user has repetitious “blank pages” while browsing a site (imagine a case where an ad banner present on all of a site’s pages triggers the assertion). A new balloon tip message indicates that the page has been switched to Compatibility View and why.

Compatibility View triggered by automatic recovery persists only for the life of the IE session - a behavior that mirrors the current experience when toggling Compatibility View while in InPrivate mode but contrasts with toggling Compatibility View in a normal browsing session (where Compatibility View information for a domain persists across browser restarts). In other words, each subsequent visit to the site (in a new session) will result in a return to IE8 Standards behavior.

When a domain has been auto-recovered, the Compatibility View button shows as pressed (as opposed to hidden or not pressed). Pressing the Compatibility View button on a recovered domain forces a page reload into IE8 mode. The catch here is that toggling in and out of Compatibility View on content that triggers an assertion can cause a recovery loop: site content triggers auto-recovery to Compatibility View, user presses Compatibility View button which takes the page back to IE8 Standards Mode, site content when put through the IE8 layout engine again triggers auto-recovery to Compatibility View…

Auto-recovered domains are shown in the user’s Compatibility View list (Tools -> Compatibility View Settings) in parenthesis.

The parenthesis denotes non-permanence. These “temporary” domains can be removed, though doing an ‘add’ operation for an auto-recovered domain in the list replaces the auto-recovered domain with a “persistent” entry (e.g. one without parenthesis).

The presence of an IE8 X-UA-Compatible tag / HTTP header (e.g. ‘IE=8’ or ‘IE=EmulateIE8’ + a Standards DOCTYPE) forces a page to stay in IE8 mode regardless of the auto-recovery setting value on the client (users will see a blank page in the event of a layout ‘hard assert’). Developers can debug blank page issues by forcing the page into an IE8 document mode via the Developer Toolbar, which will also prevent auto-recovery.

We worked hard to fix known causes of unrecoverable errors in our layout engine before we shipped. For issues that do crop up “in the wild”, IE generates error reporting via Windows Error Reporting (WER). That way, we can get a call stack of the failure and, ultimately, repro, triage, and fix assertions just as we do reported crashes and hangs.

Recap

IE8’s standards-by-default configuration supports developers and designers as they create the next wave of web pages, applications, and experiences. At the same time, we recognize the near term consequence of this decision, namely challenges around compatibility with existing content designed to work with older versions of IE. The behaviors described here enable both interoperability and compatibility, benefitting both developers and end-users.

We’re interested to hear your compatibility feedback. Please drop us a line in the comments section to let us know your experience with IE8 and the content and apps you visit / use.

Scott Dickens
Program Manager

June Chat with the Internet Explorer team on Thursday

2009-06-15T22:54:00Z

Join members of the Internet Explorer team for an Expert Zone chat this Thursday, June 18^th at 10.00 PST/17.00 UTC. These chats are a great opportunity to have your questions answered by members of the IE product team. Thank you to all who have attended our previous chats!

If you can’t join us live, the transcript for all chats are available here.

Thanks! See you Thursday.

Allison Burnett
Program Manager

IE8 Smart Address bar: What’s new

2009-06-12T21:28:00Z

During the IE8 beta periods, we unveiled a bunch of exciting new changes to the address bar. Throughout the beta period, we observed how the feature was being used and listened to your feedback. Two major themes developed from this feedback: performance, and control.

Performance

Although the Smart Address bar performance during the beta periods was acceptable for the most part, in some cases the address bar performed a bit slowly, and sometimes incredibly slowly. We made several changes under the hood with the net result of improved performance by 50% on average, and over 98% in some scenarios. Most of these changes don’t affect the actual behavior of the address bar, but I’m going to call out two that do.

First, when you type a single character into the address bar, you will now see only typed addresses:

Second, when you type two or more characters, we look for results from typed addresses and other local data (history and favorites by default) just like we did before. The difference is that you may see typed addresses first, followed shortly by the other results.

This is due to the fact that typed addresses are stored in the registry while history, favorites, and feeds are indexed using Windows Search. Accessing data from a small, fixed list of registry keys is quicker than querying a database such as Windows Search. Instead of waiting for all the returned results, results are now shown dynamically as they become available. In most cases you will still see all results populate in the address bar simultaneously. Depending on your machine configuration and the size of your Windows Search index, there may be times where you see typed addresses first follow by a slight pause and then items from history and favorites.

Control

The second major theme we heard in Beta 2 feedback was the desire for more control over the contents of the address bar. I’m pleased to announce that we now offer much greater control over what you see in your address bar. The AutoComplete settings dialog in Internet Options has changed to provide these new settings:

Feeds off by default

As part of this change, we chose to turn Feeds off by default. We saw that most users preferred to interact with feeds through the Favorites Center instead of the address bar, and turning Feeds off in the address bar allowed us to provide a more streamlined experience. If you really like to see feeds in your address bar, you can quickly turn them back on. Just open Tools -> Internet Options -> Content tab -> AutoComplete settings.

If you have Windows Search installed (it comes with Vista and later by default), you can now explicitly control whether Windows Search is used to index your data. Please see our earlier post to read the benefits of using Windows Search. Note: once again, if you disable Windows Search, you will not be able to view feeds in the address bar.

If you do not have Windows Search installed, you’ll now see an install link in the address bar which will let you take advantage of this technology.

More typed addresses

As part of the request for more control, many of you desired to see more typed addresses. The other sections (History, Favorites, and Feeds) are expandable to show 5-20 items, but in Beta 2 we limited typed addresses to 5. I’m excited to announce that we now offer the option to see more typed addresses.

Turning off one address bar section (ex: feeds) will increase the number of typed addresses from 5 to 12. If you decide you really just want typed addresses and turn off all the other sections, you will now see up to 25 typed addresses. Coupled with the change to turn feeds off by default, you will now see up to 12 typed addresses in the default case.

Enhanced SHIFT+ENTER shortcut

The Shift+Enter shortcut was designed to give you fast access to our “suggestion” – the item in the address bar we thought you’d most likely want to go to. In Beta 2, we gave preference to history items. Throughout the Beta, however, we observed that it was more common for users to pick a typed address than a history item. So we made the obvious change to prefer typed addresses. You’ll notice we also removed the section header “AutoComplete Suggestion” to reduce noise and streamline the UI.

Revamped TAB key behavior

Since there are multiple sections within the Smart Address bar, we initially thought it would be best to use the TAB to let users quickly jump down the list, from section to section. This fit with general Windows UI principles (TAB should cycle between UI controls) and seemed like it would speed up access to items in the address bar dropdown list. The arrow keys function to move through each item, line by line, in the address bar dropdown list. This was a change from previous releases and other similar products - in Internet Explorer 7 (and Windows Explorer), pressing TAB allows users to cycle through each item in the address bar dropdown.

The feedback we heard centered around two main points: “I’m used to TAB working one way, why did it change” and “I prefer using TAB instead of the arrow keys because I don’t have to take my hands off the keyboard home row – it’s just faster”. We carefully considered this feedback and weighed it against real usage data which helps us see which items in the address bar users select most often. The usage patterns that emerged from this data supported the feedback – users are most interested in getting to items at the top of the list, and TAB should help speed this up.

With the feedback and usage data in hand, the decision was clear. We changed the TAB behavior back to function as it did in Internet Explorer 7 and other, similar products.

Conclusion

In Internet Explorer 8, we improved performance and provided greater control over what you see in YOUR address bar. We’d like to personally thank everyone for sharing their thoughts and opinions on the Beta 2 and RC1 releases – your feedback was invaluable for implementing these changes. Happy browsing!

Seth McLaughlin
User Experience Program Manager
Internet Explorer

IE June Security Update Now Available

2009-06-09T19:31:00Z

The IE Cumulative Security Update for June 2009 is now available via Windows Update or Microsoft Update.

This update addresses seven privately reported vulnerabilities and one publicly disclosed vulnerability. The security update addresses these vulnerabilities by modifying the way that Internet Explorer handles scripts, cached content, and initializes memory. For detailed information on the contents of this update, please see the following documentation:

This security update is rated Critical for Internet Explorer 5.01 on Windows 2000, Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8 on supported editions of Windows XP and Windows Vista. The security update is rated Important for Internet Explorer 6 Service Pack 1 on support editions of Windows 2000. The security update is rated Moderate for Internet Explorer 6, Internet Explorer 7, and Internet Explorer 8 on supported editions of Windows Server 2003 and Windows Server 2008. For Internet Explorer Beta products, download locations are available in the Knowledge Base Article.

IE security updates are cumulative and contain all previously released updates for each version of Internet Explorer.

I encourage everybody to download this security update and other non-IE security updates via Windows Update or Microsoft Update. Windows users are also strongly encouraged to configure their systems for automatic updates to keep their systems current with the latest updates from Microsoft.

Terry McCoy
Program Manager
Internet Explorer Security

Update 6/9 - typo correction in the second paragraph.

Internet Explorer 8 is now available in 20 additional languages

2009-06-01T20:34:00Z

We are pleased to announce the availability of Internet Explorer 8 in 20 additional languages today. Internet Explorer 8 is now available in a total of 63 languages! Please visit our World wide sites page to download Internet Explorer in your preferred locale/ language.

List of NEW IE8 languages

Language	Code	Windows Vista x86	Windows XP x86
Albanian	SQI	Yes	Yes
Assamese	ASM	Yes	-
Basque	EUQ	Yes	Yes
Bengali (Bangladesh)	BGD	Yes	-
Bengali (India)	BNG	Yes	Coming soon
Gujarati	GUJ	Yes	Yes
Indonesian	IND	Yes	Yes
Kannada	KDI	Yes	Coming soon
Kazakh	KKZ	Yes	Yes
Konkani	KNK	Yes	Yes
Kyrgyz	KYR	Yes	-
Malay (Brunei Darussalam)	MSB	Yes	-
Malay (Malaysia)	MSL	Yes	Yes
Malayalam	MYM	Yes	Coming soon
Marathi	MAR	Yes	Yes
Oriya	ORI	Yes	-
Punjabi	PAN	Yes	Coming soon
Tamil	TAM	Yes	Yes
Telugu	TEL	Yes	Coming soon
Uzbek (Latin)	UZB	Yes	-

You can also download Windows Vista/ Windows Server 2008 Language Packs for these languages here.

Please visit our previous blog post for information on Internet Explorer 8 MUI packs for Windows XP and Windows Server 2003.

Thanks,
Vishwac Sena Kannan
International Program Manager | Internet Explorer.

The CSS Corner: writing-mode

2009-05-29T22:09:00Z

Introduction

The writing-mode property enables text layout for non-Latin languages like Japanese and Arabic. Supported in IE since release 5.5, this property has been significantly updated in IE8. Our goals were threefold:

To make its behavior more predictable for developers
To align with relatively newer CSS concepts like shrink-to-fit sizing
To further the CSS3 Text Layout module by providing the first implementation.

This post walks through the basics of the new implementation and the background you need to start experimenting. We’re looking forward to your feedback!

The Basics – properties and values

The writing-mode property, as defined in CSS3 Text Layout, is a shorthand for the ‘direction’ and ‘block-progression’ properties. Direction can be thought of as the flow of characters on a line; ‘block-progression’ can be thought of as the direction of line flow. The following table (mostly borrowed from the spec) shows its eight possible values:

writing-mode	direction	block-progression	Common Usage:
lr-tb	ltr	Tb	Latin-based, Greek, Cyrillic writing systems (and many others)
rl-tb	rtl	Tb	Arabic, Hebrew writing systems
tb-rl	ltr	Rl	East Asian writing systems in vertical mode
bt-rl	rtl	Rl	Arabic script block quote embedded in East Asian vertical text
tb-lr	ltr	Lr	Mongolian script writing system
bt-lr	rtl	Lr	Arabic script block quote embedded in Mongolian script document
lr-bt	ltr	Bt	None
rl-bt	rtl	Bt	None

(Note that the last two rows refer to combinations that are currently undefined because they are not used by the world’s scripts and languages. For completeness they are implemented in IE8.)

In understanding vertical text layout it is important to agree on terminology as the meaning of width and height can change based on context. We always refer to width and height as physical properties i.e. width is always horizontal and height is always vertical. In addition left, top, right and bottom are also considered physical.

The best way to understand writing-mode and vertical text layout is through examples. The simple scenarios below will help you understand sizing, overflow and tables.

Block dimensions

Vertical sizing algorithms swap width and height calculations, so the algorithm which was used for width in horizontal layout is now used for height in vertical layout.

Consider this example:

Here no widths and heights are specified for the two div elements; the first is parallel to the parent body, the second is orthogonal with writing-mode set to tb-lr.

Notice how the first div is as wide as the viewport and its height fits its content. This is as per the normal rules of CSS.

The sizing of the second div is exactly analogous with width and height swapped – the height is now the same as that of the viewport, and the width is sized to fit the content.

Note, viewport is used in this example, but if the body’s height was specified then its value would be used to compute the auto height as expected. The reasoning behind this behavior is that the user can scroll to the vertical content (if the first horizontal div was very long) and then start scrolling horizontally while all content still fits the vertical landscape of the viewport.

This example becomes more interesting as one adds a second orthogonal div, this time with a relative size:

The second vertical div has width set to 50%; notice how its physical width is 50% of that of viewport (body).

Note that the last block appears below the previous one because the block flow of the parent (body) is top to bottom. It may be natural to assume that the writing-mode of an element affects the block progression of the element itself but that is not the case. Changing block progression on the body to LR would place the blocks side by side. However, if BODY was to overflow horizontally it would do so in the writing direction of its parent. In this case the HTML element which is LR-TB, thus, overflow will be to the right thus hiding the beginning of the content. This is a subtle yet very important point since most users would expect that the origin point (where the first letter of the content appears) will be visible regardless of overflow. The reason is that overflow to the left and top (assuming LR-TB direction) is not a scrollable and hence clip-able area (see next section).

Overflow in vertical layout

Handling overflow in vertical layout is still under debate. IE8 positions scrollbars according to the direction of overflow i.e. if content overflows to the left of the element then the vertical scrollbar will be on the left side.

Consider an example where a fixed-sized element has writing-mode:bt-rl and overflowing content.

Notice the position of the scrollbars and also their initial state. Since the start of the content is the physical bottom of the element, that is the initial position of the vertical scroller.

Another interesting case is when the element is too wide for the window, thus forcing viewport scrollbars:

The start of the text is off the screen and the user must scroll right to see it. In addition the vertical scroller is not accessible after the user has scrolled to the right. This may seem odd but it is the expected result as the direction of the parent (body) is LR-TB. When developing pages in mixed mode layout, consider the effects of overflow.

Vertical layout and tables

In the case of vertical tables, rows become vertical and columns become horizontal. Using the following mark-up…

<body writing-mode=”??-??”>
     ABCDEF
     <table>
          <tr> 
              <td> 1 </td> <td> 2 </td> <td> 3 </td>
          </tr>
          <tr>
              <td> 4 </td> <td> 5 </td> <td> 6 </td>
          </tr>
          <tr>
              <td> 7 </td> <td> 8 </td> <td> 9 </td>
          </tr>
     </table>
</body>

…these are the results in all eight modes:

Table sizing follows the same principle as box sizing: height and width calculations are swapped. The cell width / column width / table width calculation algorithms now use all height values. The cell height / row height / table height calculation algorithms now use all width values.

Padding, Margins and Percentage values

Most web authors who use CSS to design their web sites know that understanding margin collapsing takes time. This is why one of our goals while designing and implementing multiple writing directions was to limit any added complexity to margin collapsing logic. In essence, margin collapsing follows the same rules as in CSS 2.1 – 8.3.1. The only difference is that margins are collapsed in the direction of block-progression. The reason for that is that when an orthogonal change of direction (vertical inside of horizontal) occurs, the element changing direction becomes a Block Formatting Context. Hence, no margins of its nested elements (vertical ones) are collapsed with it. This is illustrated in the following example – note that none of nested blocks are collapsing their margins with the container (the dark-blue block) even thought the container has no borders.

Percentage values for padding and margins are computed based on the logical width. That is, the computed value of width if parent element is in horizontal or computed value of height if parent element is in vertical block-progression.

Thanks for reading. We will be following the comments for feedback and look forward to hearing from you.

Saloni Mira Rai – Program Manager and
Rossen Atanassov – Software Developer

Rescheduled: May Chat with the Internet Explorer

2009-05-20T22:15:00Z

The May IE Chat has been rescheduled for Thursday, May 28^st at 10.00 PST/17.00 UTC. We apologize for any inconveniences.

As always transcripts of previous chats are available here.

See you next week!

Allison Burnett
Program Manager

Making the Web Bigger Part 1: Improvements to Zoom

2009-05-18T17:48:00Z

As display technologies advance and the world begins to fully embrace accessibility on the web, the Zoom and High DPI experience of all browsers has become increasingly important. This is the first in a series of posts describing changes and improvements to Internet Explorer 8 to enable a more readable web on today’s displays. In this post, we’ll focus on enhancements to the Zoom user experience.

How to Use Zoom

First, let’s review how to take advantage of Zoom in Internet Explorer 8. Internet Explorer 7’s zoom was closer to optical zoom, where every element on the page was scaled relative to its size as rendered at 100% or ‘normal’ view. This led to a number of issues for users, such as the overabundance of horizontal scrollbars. The new zoom in Internet Explorer 8 scales elements that are defined in absolute units, such as pixels, while not affecting the size of elements defined in relative units, such as percentages. For a full description of the zoom layout and rendering behavior in Internet Explorer 8, please see Saloni’s blog post from Beta 1. Preferences for individual users differ greatly, so there are four ways to zoom in and out on web pages:

Via the user interface
Via keyboard shortcuts
Via the mouse wheel
Via touch gestures (available on Windows 7)

User Interface

The most common and visible method of zooming pages is by clicking on the zoom icon in the bottom right corner of the browser window:

Clicking on the magnifying glass toggles zoom between 100%, 125%, and 150%. Clicking on the down arrow to the right of the magnifying glass gives you more granular options for zooming:

You can access the same options as those illustrated above by clicking on ‘Page’ in the Command Bar, and then the ‘Zoom’ menu item.

Keyboard Shortcuts

Using keyboard shortcuts is probably the fastest way to zoom in and out on webpages you are reading.

Increment zoom by 25% by hitting the Control Key and the ‘Plus’ key together
Decrement zoom by 25% by hitting the Control Key and the ‘Minus’ key together
Set zoom to 100% by hitting the Control Key and the ‘Zero’ key together

When you use the keyboard shortcuts to increment and decrement zoom, you will also notice that the zoom value will snap to 100%. For example, let’s say your zoom is set to 115%. If you hit the shortcut combination for zoom decrement twice, zoom will go from 115% to 100%, and then from 100% to 75%.

Mouse Wheel

You can also rapidly zoom in and out a webpage using a mouse wheel, if your mouse is equipped with one. While viewing a webpage, hold the Control Key while scrolling the mouse wheel. If you scroll the wheel away from you, the page will zoom in, and conversely, if you scroll the wheel towards you, the page will zoom out. Each notch on the scroll wheel increments/decrements zoom by 5%.

Touch Gesture

I discuss how to use touch gestures to zoom farther down in the post, so keep reading!

Zoom Persistence

Internet Explorer 8 remembers your zoom choice across new tabs and new windows. For example, let’s say you are viewing a web page and decide that 125% works better for you than your current zoom setting of 100%. Clicking the magnifying glass in the bottom right bumps your page up to 125% zoom. Internet Explorer 8 remembers this preference and opens up all future windows and tabs at 125%. In fact, any method of setting the zoom level as described above is remembered by Internet Explorer 8 until you change it again. Internet Explorer 7 had a different behavior – zoom was reset to the default value for all new windows and tabs. If you prefer that behavior you can adjust the setting:

‘Tools’ in the Command Bar
‘Internet Options’ menu item
‘Advanced’ Tab

Check the option ‘Reset zoom level for new windows and tabs’ and then click ‘Ok:

Never Lose Your Place While Zooming Again

Beta feedback showed that many IE users lost their place in the document when zooming in and out on a webpage. Thanks to collaboration with the Internet Explorer Touch feature team and Windows 7 Touch team, we’ve implemented a feature called Focal Point Zoom that addresses this problem.

What is Focal Point Zoom?

Focal Point Zoom allows Internet Explorer to zoom in and out on any webpage while retaining a specified focal point within an element. This way, you get a way more intuitive zooming experience and are less likely to lose your bearings. An example… Let’s say you’re reading www.msn.com and want to zoom in around President Obama’s ear. The focal point can be defined as right over the President’s ear as in the screenshot below:

You can then zoom in as much as you like and the browser will retain the same focal point:

Notice how the focal point hasn’t changed location relative to the viewport and hasn’t changed relative to the element content (The President’s ear).

How do I use Focal Point Zoom?

Actually, all our methods of zooming now take advantage of Focal Point Zoom, but determine the focal point in different ways:

Mouse Wheel Zoom - The location of the mouse cursor defines the focal point. This allows for very precise zooming in and out.
Keyboard Zoom - The focal point is defined as the center of the viewport (see diagram below)
User Interface Zoom - The focal point is defined as the center of the viewport (see diagram below)

Windows 7 RC, Multi-touch Hardware, and Focal Point Zoom

If you are one of the lucky ones who owns a multi-touch enabled PC with the latest Release Candidate of Windows 7 installed, you will be able to use our specific touch-enabled zoom features that leverage Focal Point Zoom technology.

Pinch Zoom

The first feature, which might be familiar to you, is ‘pinch zoom’. When you begin a pinch gesture by placing two fingers down on your touch surface, the focal point is defined as the distance halfway between your two fingers:

As you move your fingers farther apart, Internet Explorer will zoom the page in (zoom percentage increases) and conversely, as you move your fingers closer together, Internet Explorer will zoom the page out (zoom percentage decreases), all the while retaining the focal point. The amount of zooming that occurs is directly proportional to the change in distance relative to the current zoom level.

‘Two Finger Tap’ Zoom

The second feature uses the Two Finger Tap gesture from Windows 7 to allow you to quickly zoom in on a screen element by tapping it with two fingers. (On the IE team, we like to call this the “cobra tap”.) The focal point is once again defined as the distance halfway between your two fingers, and the target element is defined as the element below the focal point. In the diagram above, the President’s picture would be the target element. Internet Explorer 8 will do its best to zoom in on the target element as much as possible without pushing it off the viewport. If you perform a second cobra tap on the same page prior to navigating, the page will be returned to your default zoom setting.

It is important to note that any zoom level changes due to touch gestures do not persist across navigations, new tabs, or new windows. We found from user testing that most people utilized touch zoom features primarily for quick inspection and link pressing. You can change your default zoom setting by changing zoom via the UI, keyboard, or mouse as described previously.

When Focal Point Zoom Doesn’t Work As Expected

There are times when Focal Point Zoom may not work as you might expect. The first thing to keep in mind is that in order for Internet Explorer 8 to be able to retain a focal point, the webpage must have scrollbars. If you are at lower zoom levels or the webpage author goes to great lengths to prevent scrollbars at all window sizes, Internet Explorer 8 might be unable to pan the page in order to keep the focal point due to lack of scrollbars. One example of such a page is www.wikipedia.org, where most element dimensions are defined in terms of relative units, such as percentages. For example, when an element is sized as a percentage of the viewport, that element itself will never cause the appearance of scrollbars , which are needed in order for focal point zoom to pan properly.

Additionally, if a webpage reflows its layout during window size changes because the majority of elements are defined relatively or through the usage of JavaScript, the focal point retention may not appear to be as accurate as expected. Here, the problem isn’t that the focal point is wrong, but rather that the content within the element that has the focal point moves significantly.

Matching Zoom to Windows DPI Setting

In order to make the web browsing experience congruent with the Windows experience, Internet Explorer matches its zoom setting to your Windows DPI setting. For example, if your Windows DPI Scaling is set to 120 DPI, Internet Explorer 8 zooms the content of webpages by 125%, because scaling is done relative to 96 DPI, and 120/96 equals 1.25, or 125%. For more details on High DPI and Internet Explorer 8, please see the ‘DPI Scaling’ section of the ‘Making the Web Bigger’ whitepaper on MSDN. Of course, if you prefer to view webpages at another zoom level by default, you can simply change the zoom level, as described at the top of this post, and Internet Explorer 8 will remember your last choice.

Until Next Time

We hope you enjoy the improvements made to Zoom over the past couple of months and we would be glad to hear your feedback. Please look out for part 2 of this series over the next few of weeks, which will focus more on the technical aspects of Zoom, High DPI, and the developer platform. In the meantime, hopefully the Zoom and High DPI whitepaper referenced above will tide you over. See you soon!

-Harel Williams, User Experience PM

Update 11:10 am: Changing 'Power Tap' to 'Two Finger Tap'

Now Available: Internet Explorer 8 MUI packs for Windows XP, Windows Server 03

2009-05-14T19:05:00Z

We are pleased to announce the availability of Internet Explorer 8 Multilingual User Interface (MUI) packs for Windows XP SP2, Windows XP SP3, and Windows Server 2003 SP2. The MUI packs can be downloaded from here :

As detailed in our previous blog post, the following Internet Explorer MUI packs shipped today –

Internet Explorer 8 MUI pack applicable to Windows XP x86 and Windows Server 2003 x86 for the following languages –
- Arabic, Chinese (Traditional), Chinese (Hong Kong), Czech, Danish, Dutch, Finnish, French, German, Greek, Hebrew, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Portuguese (Portugal), Portuguese (Brazil), Russian, Spanish, Swedish, Turkish, Bulgarian, Croatian, Estonian, Latvian, Lithuanian, Romanian, Slovenian, Slovakian, Thai
Internet Explorer 8 MUI pack applicable to Windows Server 2003 x64 and Windows XP x64 PRO for the following languages –
- Chinese (Traditional), Chinese (Simplified, German, French, Italian, Japanese, Korean, Russian, Spanish, Swedish, Portuguese (Brazil)

Note: If you have Windows XP or Windows Server 2003 and OS MUI pack installed, you need to install the English version of Internet Explorer 8 and then install the Internet Explorer 8 MUI pack for Windows XP and Windows Server 2003 (matching your Operating system and architecture).

Thanks,
Vishwac Sena Kannan – IE International Program Manager
Jatinder Mann – IE Setup Program Manager

The tastiest dog food yet

2009-05-13T18:24:00Z

This post is intended for IT administrators, but more technical users might also find it useful.

During Internet Explorer 8 development we paid very close attention to Line of Business (LOB) application compatibility for large enterprises. We want IE8 to be an easy drop-in replacement for earlier versions of IE, so that all users can benefit from the improved speed, security and ease of use of IE8.

Like Microsoft, your organization probably depends on a very large number of Line of Business applications – some commercial, some developed in-house – and the browser is an integral part of your IT infrastructure.

During the past year of IE8 development, we tested thousands of LOB applications here at Microsoft to ensure that an IE8 rollout in your organization will be easy – and we think that we’ve succeeded in making IE8 one of the easiest enterprise upgrades yet.

Starting at IE8 Beta 1, we rolled out IE8 to thousands of Microsoft employees and debugged any issues they encountered – a process known as dogfooding (as in eating your own dog food…). It wasn’t without glitches. At some points, Microsoft employees could not view their pay stubs online or schedule an office move. That let us work out the kinks before we shipped, and IE8 is now being rolled out to all employees at Microsoft.

What you need to know

Of course, you want to roll out new software only once your organization is ready. Use the IE8 Blocker Tool to block the IE8 auto-update while you test IE8.

Once you are ready to roll out IE8 via Microsoft Update, remember to roll out Compatibility View List update package along with the actual IE8 package. The Compatibility View package pre-populates the Compatibility View list, so your users will not have to manually set Compatibility View themselves if they encounter issues when browsing popular sites.

As noted previously, Microsoft will update and rerelease the Compatibility View list as needed - be on the lookout for updates to the Compatibility View list.

As for your intranet:
Internet Explorer will render websites in your intranet in IE7 compatibility view mode by default (unless, of course, the site itself or group policy sets a different mode).

This means that compared to IE7, IE8 should not have any major rendering differences on intranet pages. There are some differences, but they should be minor.

Of course, not all LOB applications are on the intranet anymore. If your users use an extranet site that only works in IE7 Compatibility View mode, you have two ways of fixing it:

If you own the site: You could change the site itself, and use the meta tag or the http header to tell IE8 to render the site in IE7 Compatibility View mode.

- or -

If you do not own the site: You could also use group policy to set the site to IE7 Compatibility View mode: Add the TLD of the site to the 'Use Policy List of Internet Explorer 7 sites' setting.

This setting is found in 'Administrative templates, Windows Components, Internet Explorer, Compatibility View' in the Computer or User section of the GPO.

Configuring IE settings

During your rollout testing, you might discover that you have to do some IE configuration to fix some issues.

In general, make as small a change as possible - Don't change IE's global settings for the intranet or Internet zone, as it could have a major impact on IE security or performance on a lot of sites.

The first thing to try is adding the site to the trusted sites zone - this fixes most issues with LOB applications that require more access to your machine. You can use group policy to add sites in your organization to the user’s trusted sites list.

Other things to know:

Sharepoint

If you are admin of an Office SharePoint 2007 server, you'll need to install Service Pack 2. (IE8 uses more connections than IE7 when downloading a site, and this may cause issues when you log out of Sharepoint and log in as another user.)

Session management

IE8 now shares session details between windows - so you can't open two IE windows and log into the same site with different credentials.

If you want to do this, use File - New Session to open a new IE window and start a new IE session where you can use different credentials.

File upload control

For security reasons, IE no longer sends the full file path when you upload a file via the file upload control. To get this behavior back for example.com, add it to the trusted sites list.

Intranet zone

Protected mode is now off for the Intranet zone in IE8 (this is similar to IE6 behavior). If this was an issue for your IE7 rollout, IE8 should be easier in this regard.

asp:menu (ASP.NET WebControls)

If you are using ASP.NET on a web page that is rendering in standards mode (in other words: not on your intranet) - remember to patch the ASP.NET control to work in standards mode. See this blog entry for more details.

Microsoft Office Publisher

If your organization is using Microsoft Office Publisher 2003 or Office Publisher 2007 to generate web content, you’ll need to republish some pages to make them render correctly in IE8. For example, navigation bars and other content might be missing on the page when viewed in IE8. See KB969705 for a workaround.

Visual Studio 2005/2008 wizards

Some Visual C++ wizards do not function correctly after IE8 is installed. To fix this issue, see this Visual C++ Team blog post.

Please let us know about your experiences with rolling out IE8 in your organization.

Thanks,
Frank Olivier
Internet Explorer Compatibility Program Manager