The evolution of the Internet has introduced new sources of rich information and more ways to access it. That growth has introduced a new set of opportunities, immersive experiences, online services, and standards to the Web. With this intensity and reliance, Web developers and designers face an evolving set of needs. To that end, the development process of Windows® Internet Explorer® 8 Beta 2 focused on three major themes:
Provide real-world interoperability with other browsers and compatibility for existing sites
Make Web development faster and easier thanks to built-in developer tools
Enable experiences that reach beyond the page through new browser features that effortlessly connect users to innovative Web services
Internet Explorer 8 Beta 2 includes a host of new features and enhancements—all driven from real-world scenarios and customer feedback—that puts the Web at your service. This document provides a high-level overview of new and enhanced features in Internet Explorer 8 Beta 2, and is tailored for Web developers and designers like you.
Real World Interoperability and Compatibility
Each version of Internet Explorer has delivered better performance, more reliability, bug fixes, and improved security. Internet Explorer 8 Beta 2 brings even more enhancements to the core platform and architecture, offering improved performance, safety, reliability, and compatibility.
Standards Improvements
With past versions of Internet Explorer, developers and designers have sometimes noted that Internet Explorer has had its own interpretation of Web standards and the way the browser handles HTML, Cascading Style Sheets (CSS), scripting, and so on. In some cases, interpretations were decided upon because Internet Explorer supported certain features before corresponding standards were finalized. If those standards change as they are finalized, Internet Explorer’s implementation can vary from what the standard specifies.
The Internet Explorer team has stood behind our application compatibility commitments whenever possible because we know there are customers with critical dependencies on legacy behavior. For that reason, we have supported the legacy Internet Explorer model whenever feasible so that sites developed to it would continue to behave as expected in newer versions of Internet Explorer. Moving forward, the decision to support legacy behaviors versus strict standards will be put in the hands of Web developers by enabling you to select the rendering mode on a page-by-page basis.
Internet Explorer 8 Beta 2 ships with multiple rendering modes that may be set by using the X-UA-Compatible header. The modes are summarized in Table 1.
Table 1. The compatibility modes in Internet Explorer 8 Beta 2.
Compatibility Mode Value
|
Render Behavior
|
IE=5
|
“Quirks” mode
|
IE=7
|
Internet Explorer 7 Strict mode
|
IE=EmulateIE7
|
Use the !DOCTYPE declaration to determine mode:
Quirks mode !DOCTYPEs result in Quirks mode
Standards mode !DOCTYPEs result in Internet Explorer 7 Strict mode
|
IE=8
|
Internet Explorer 8 Standards mode
|
IE=EmulateIE8
|
Use the !DOCTYPE to determine mode:
Quirks mode !DOCTYPEs result in Quirks mode
Standards mode !DOCTYPEs result in Internet Explorer 8 Standards mode.
|
IE=edge
|
Uses latest standards that Internet Explorer 8 and any future versions of the browser support. Not recommended for production sites.
|
This value may be set as an HTTP response header or by adding it to the head tag, such as:
By default, Internet Explorer 8 Beta 2 renders content in Internet Explorer 8 Standards mode. However, you can have multiple values in the content attribute to support multiple standards. Developers who want to continue to have their sites render in Internet Explorer 7’s Strict mode should add the following to their head block.
Note that the setting in the document always overrides the HTTP header. For more information, see the following Microsoft® Help and Support article: Some Web sites may not be displayed correctly or work correctly in Windows Internet Explorer 8 Beta 2.
For more information on document compatibility, see “Defining Document Compatibility” on MSDN.
Internet Explorer 8 is planned to ship with multiple layout modes. The choice of layout modes is based on official Web standards and enables developers to select the most appropriate standard so that content will display correctly in the browser and applications will behave as expected. The behavior is as specified in Table 2.
Table 2. Internet Explorer 8 layout modes.
Page Content Declaration
|
Layout Mode
|
Known standards !DOCTYPEs and unknown !DOCTYPEs
|
IE8 Standards
Note Content will display using Internet Explorer 7 Strict mode if IE=7 or IE=EmulateIE7 is declared.
|
public identifier "-//W3C//DTD XHTML 1.0 Transitional//EN"
public identifier "-//W3C//DTD XHTML 1.0 Frameset//EN"
public identifier "-//W3C//DTD HTML 4.01 Transitional//EN", with a system identifier
public identifier "-//W3C//DTD HTML 4.01 Frameset//EN", with a system identifier
|
“Almost” Standards
All content is interpreted as in Internet Explorer 8 Standards mode except for line heights; particularly important for legacy sites that contain images within table cells and expect no whitespace around the images.
Note These !DOCTYPEs trigger Internet Explorer 7 Strict mode if IE=7 or IE=EmulateIE7 is declared.
|
Quirks mode !DOCTYPEs (includes the absence of a !DOCTYPE)
|
Quirks Mode
|
Note For more information on !DOCTYPEs, see the !DOCTYPE element reference article on MSDN.
Displaying Web pages in standards mode brings developers closer to the point content will be written once and work consistently across modern browsers.
The meta compatibility tag attempts to solve backward compatibility problems by providing Web developers a way to signal the desired layout mode regardless of !DOCTYPE.
ActiveX
Internet Explorer 8 Beta 2 enables better management of Microsoft® ActiveX® controls, such as where and how they can load, as well as which users can load them.
Internet Explorer 8 Beta 2 on Windows Vista® and Windows Server® 2008 introduces the ability to package ActiveX controls for installation to users’ own profiles without administrator involvement. This solution addresses concerns raised by customers of previous versions of Internet Explorer in which the administration of controls was inconvenient. In the event that a user unknowingly installs a malicious ActiveX control, the impact is limited to that user’s profile. Additionally, most existing ActiveX controls will not have to be rewritten to benefit from this feature, although they will require repackaging.
ActiveX controls embedded as Web objects are presented to the user as add-ons that may be restricted for use on specific Web sites. When a Web site requests the loading of an add-on, the Information Bar provides users the ability to restrict the control to only the current Web site, or allow any Web site to use the control. Users can easily make changes to this behavior through the new Internet Explorer Add-ons Manager.
For more information on ActiveX improvements in Internet Explorer 8 Beta 2, see this post on the Internet Explorer Team Blog.
Per-user (Non-admin) ActiveX
Running Internet Explorer 8 in Windows Vista, a standard user may install specially packaged ActiveX controls in their own user profile without requiring administrative privileges. This improvement makes it easier for an organization to realize the full benefit of User Account Control (UAC) by enabling standard users to install ActiveX controls used in their day-to-day browsing. If a user happens to install a malicious ActiveX control, the overall system will be unaffected, as the control was installed only under the user’s account.
Per-user ActiveX was designed with compatibility in mind. Most existing ActiveX controls will not need to be rewritten to benefit from this feature; only a change to the ActiveX control’s .INF file within the .CAB is required. As in Internet Explorer 7, when a Web page attempts to install a control, an Information Bar is displayed to the user. By clicking the Information Bar, users can choose to either install the control machine-wide, or install it only for their own user account. The available options depend on Group Policy settings for per-user ActiveX installations and whether the control has been packaged to allow per-user installation.
Per-site ActiveX
When a user navigates to a Web site containing an ActiveX control, Internet Explorer 8 performs a number of checks, including a determination of where the control is permitted to run. This check is referred to as Per-site ActiveX, a defense mechanism to help prevent malicious repurposing of controls. Using Per-site ActiveX security hardens the browser. By default, an ActiveX control may only run from the domain in which it was installed. If a control is installed, but is not permitted to run on a specific Web site, an Information Bar appears asking the user whether or not the control should be permitted to run on the current Web site.
Adaptive Page Zoom
Adaptive Page Zoom in Internet Explorer 8 Beta 2 enables users to enlarge or reduce the view of a Web page to improve readability. This feature is particularly useful on very large and very small displays because it allows for scaling of content while maintaining the intended layout of the page.
While the initial Internet Explorer 7 version of zoom was a “digital” page zoom, zoom in Internet Explorer 8 Beta 2 provides a higher quality, more predictable zooming experience known as an “adaptive” page zoom. While zooming, Internet Explorer 8 will resize the text and images and reflow the page to make it easier to read. This will eliminate horizontal scroll bars for the majority of scenarios and allows for persistent zoom states. As a developer, you may wish to understand the behavior of Adaptive Page Zoom and how it might affect your site’s design.
Internet Explorer 8 Adaptive Page Zoom is accomplished by scaling elements pre-layout. This is significantly different from Internet Explorer 7 Zoom behavior, which was analogous to “magnifying” the Web page–elements were scaled post layout, and then re-drawn on screen. Due to this important change, horizontal scrollbars are introduced only when the fixed width of the scaled content is greater than the width of the viewport. This is exactly like resizing regular layout on an un-zoomed Web page.
Text wrapping is also affected by this change. In Internet Explorer 7 Zoom, line lengths and line breaks were not recalculated as the zoom factor increased or decreased. This led to situations where text lines were either too small (resulting in too much white space) or too large (resulting in text runs that would go off the screen, requiring horizontal scrollbars). In Internet Explorer 8 Beta 2, line lengths are recalculated based on available space before the text is rendered on screen. Then, line breaks are inserted, taking the new lengths into account.
In addition, it is important to understand how common page elements and properties respond to zoom.
Fonts and text: The glyph itself is not scaled. Rather, the font size is scaled and then the appropriate glyph is used. The important thing to note is that fonts do not scale linearly by design. For example, if text at 12pt is scaled to 110%, the resulting font size is calculated as 13.2pts. Since this font size does not exist, it is therefore rounded to the nearest available size, 13pt.
Fixed, auto, and relative sizing: Dimension scaling is one of the most important improvements in Adaptive Page Zoom. Dimensions specified using absolute units (for example, in, cm, mm) or device and font dependent units (for example, px, ex, em) are scaled as per the zoom level. Therefore, at 200%, 100px becomes 200px and 20pt becomes 40pt. Content-dependent dimensions (percent and auto) are not scaled, as they are computed during layout. Therefore, at 200%, a width of 50% of the viewport does not become 100% of the same. This is a marked change from Zoom in Internet Explorer 7.
Positioning: Positioned elements grow and shrink like in-flow elements. However, their new position is determined by the properties set and the offsets used. An absolutely positioned element, if offset to the left by 100px, will shift towards the right when zoomed in. It is possible for the element to go off the screen. Similarly, floats will be positioned with respect to their container, per the normal rules of CSS. If the width of the container changes with zoom, then the position of the float will change. Zooming of adjacent floats is exactly like resizing the window—if the width of the viewport is not large enough to accommodate the floats, the last one in markup will drop to the next line.
DHTML properties: In Internet Explorer 7 Zoom, some properties were treated as physical (such as mouse coordinates), while others were logical (offset). This implementation essentially required Web developers to be aware of or manually calculate the zoom state based on the property being used. With Internet Explorer 8 Beta 2 Adaptive Page Zoom, all DHTML properties are now assumed to be logical. This enables some key scenarios such as fly-out menus and “drag-and-drop.”
Getting Your Site Ready for Internet Explorer 8 Adaptive Page Zoom
Web developers should not expect to write any special code for Adaptive Page Zoom; all properties are logical, and scaling is purely internal. For developers who are interested in improving their site user experience with zoom, Microsoft recommends that you test the site with different zoom factors, resolutions, and window dimensions. Think about the following during testing:
At what point do horizontal scrollbars appear? Does the user need to scroll to read a single line of text?
Does content quickly go off screen because of fixed sizing and positioning?
Does the overflow:hidden value on any elements make content inaccessible?
Do fly-out menus adapt to available screen real estate, or do options go off the screen, making them inaccessible to the user?
For more information on zoom in Internet Explorer 8 Beta 2, see “Making the Web Bigger: DPI Scaling and Internet Explorer 8” on MSDN.
Improved Printing
There are new printing features in Internet Explorer 8 Beta 2. Improved compliance with the CSS 2.1 specification in Internet Explorer 8 Beta 2 provides enhanced functionality and control in the print medium, giving developers greater control over how content is printed. In particular, support has been added for the following printing constructs:
Correct behavior for avoid, left, and right values for page-break-after and page-break-before properties
page-break-inside property
widows property
orphans property
By using these CSS features, you can specify the margin area, portions of content that must be kept together, and much more, enabling you to greatly improve the readability of printed Web pages.
For more information on improved printing with CSS in Internet Explorer 8 Beta 2, see the “Printing” section of “CSS Compatibility and Internet Explorer” on MSDN.
W3C ARIA Support
Accessible Rich Internet Applications (ARIA) constitutes a syntax for defining how Web developers can mark up content with roles, states, and properties that browsers use when communicating with assistive technology. Thanks to ARIA, users with impairments can access Web sites with a rich interaction comparable to the originally intended experience.
Many third-party assistive technologies (ATs), such as Window-Eyes, implement Microsoft Active Accessibility (MSAA) application programming interfaces (APIs) to get and expose information about the user interface to end users. By exposing ARIA through MSAA in Internet Explorer 8 Beta 2, ATs that already use MSAA can also easily support ARIA. Note that only a portion of ARIA can be supported through MSAA’s functionality.
For more information on ARIA support in Internet Explorer 8 Beta 2, see “Mapping ARIA Roles, States, and Properties to UI Automation” on MSDN.
File Upload Control
In the past, the HTML file upload control (input type=file) has been the source of a significant number of information disclosure vulnerabilities. To resolve these issues, two changes have been made to the behavior of the control. Internet Explorer 8 Beta 2 controls information exposed during file upload with its expanded file upload control and file locking on the Internet zone.
To block attacks that rely on “stealing” keystrokes to surreptitiously trick the user into typing a local file path into the control, the file path edit box is now read-only. The user must explicitly select a file for upload using the File Browse dialog box.
Figure 1. The file path edit box is now read-only. Users must click the Browse button to select a file.
Additionally, the Include local directory path when uploading files URLAction has been set to Disable for the Internet zone. This change prevents leakage of potentially sensitive local file-system information to the Internet. For instance, rather than submitting the full path, such as the following:
C:\users\seanpurcell\documents\secret\image.png
Internet Explorer 8 will now submit only the filename:
image.png
|
