Hi, Travis here, a program manager for Trident/OM. In Beta3, you may have noticed that modal or modeless dialogs created from script seem to be slightly bigger than their IE6 counterparts. This is due to a recent change to bring the behavior of these dialogs closer to their window.open cousins. In essence, we want to free developers from worrying about how much content size they are going to get when they request a modal or modeless dialog (from IE7 and onward). Note: our definition of content size is the actual window area available in which to display web content (see Figure 3).
To see the size difference, consider the following script that fires a new window via window.open and a dialog via window.showModalDialog.
In IE6, the window.open window is created with 300 x 200 pixels of useable content area (this is good). The modal dialog is created with slightly less useable area. Why is that?
IE6 gives web developers control over the frame size of dialogs (also known as the ‘chrome’). The frame includes visual elements such as the title bar, status bar, borders, etc. This is a problem for web developers because the dialog’s frame size varies according to whatever windows theme is applied (this is bad). With Windows Vista on the horizon, new user themes compound this problem (see figure 1).
Figure 1 - Various themes in Windows XP and Vista and their content area
In Windows XP Service Pack 2, IE’s security improvements added window restrictions that forced the status bar onto windows and dialogs (in certain security zones); developers adapted by subtracting the height of the status bar from their dialogs.
Enter IE7. We bring you another security feature—an address bar for identifying a dialog’s URL (see figure 2). This address bar also encroaches upon a dialog’s content area.
Before the guesswork for sizing the content area gets any worse for developers, we felt it was time to set things right by focusing on delivering HTML content area instead of total frame size.
Here’s how we changed it. In IE7, the meaning of window.dialogHeight and dialogWidth now refers to the content area. Essentially, the area (height/width) that you specify is what we try to deliver in the content area of the dialog (barring window restrictions on scriptable minimum sizes: 250px wide x 150px high*). It will no longer be necessary to calculate the area lost by components of a dialog’s frame.
Based on these changes, websites that must continue to support IE6 and want IE7 dialogs to look identical must either provide special case code for IE6 and previous versions, or special case code for IE7 and beyond. My browser detection code (below) borrows from an article on effective browser detection techniques.
Method 1: For IE6 code that previously adapted window size to meet the requested content area dimensions--before calling the new window
Method 2: For new IE7 code to work backward with IE6--adjusting the size after the dialog is created
IE7 no longer provides a method for script to retrieve the dialog’s frame dimensions (‘chrome’ area included). This was formerly available through window.dialogHeight/Width, which now returns the content area. Future versions of IE may provide this functionality. In IE7, if the total window dimension is desired, it must be estimated using the same techniques from IE6 used to estimate the content area (but in reverse).
At this risk of complicating this post, I also want to enumerate two security settings that may affect how developers design for new windows and dialogs in IE7 (figure 4).
Window Restrictions Setting
What changed: This setting controlled both windows sizing constraints (minimum sizes), and the forcing of the status bar in SP2. IE7 has combined the forcing of the status bar and the new address bar into a new setting, as the two visual elements are important for security and should be considered together (see below). The window restrictions setting now applies only to sizing constraints. Restrictions are turned on for the Internet, Restricted Sites, and Lockdown zones.
Status and Address Bar Control
This new setting allows users to enable or disable the forcing of the status bar together with the forcing of the address bar on a per-zone basis. If enabled, the address bar and status bar will display on dialogs despite the developer’s scripted code (status:on or status:off will be overridden by this setting). Disabling this setting allows developers to continue to specify the presence or absence of the status bar and address bar independently of each other. Restrictions are enabled for the Internet, Restricted Sites, and Lockdown zones.
We think that the transition to this new sizing model (content area vs. total frame size) will benefit web developers in the long run by making it simpler to code pages that will display in dialogs or windows.
*As many customers have pointed out, the minimum sizes for dialogs across IE have been adjusted in IE7 from their previous limits. In IE6 new windows via window.open had a limit of approximately 100x100 pixels of content area. New dialogs via window.showModal/ModelessDialog had a total frame height and width limit of approximately 100x100 (the width value was always approximate because Windows itself enforces additional minimums based on current theme). IE7 changed the width minimum to ensure that the newly-added address bar displays enough URL text to make informed trust decisions, to allow the status bar to fully print “Internet | Protected Mode: XX” without truncation (in Vista), and to avoid truncating the address bar widget (the widget starts to truncate at 204 pixels). The height was adjusted to match new window.open minimums. Thus in IE7, usable content area minimums are uniform across both window.open and window.showModal/ModelessDialogs.
Edit: Please see the update blog post on IE7 dialog sizes for the most current information on minimum dialog height restrictions