Internet Explorer 8 Beta 2 delivers a better developer platform and the tools to back it up. With advancements in support for Ajax (Asynchronous JavaScript and XML) applications, as well as improvements that simplify the process of building cross-browser applications, Internet Explorer 8 Beta 2 enables developers to be more productive when building the most robust Web applications possible.
Integrated Developer Tools
Internet Explorer 7 supported a Developer Toolbar, which developers could download separately and run as an extension to the browser. Although many developers found it to be highly useful for testing, debugging, profiling, or rapidly prototyping a Web page, because it ran as an extension its performance was limited and it required a substantial memory footprint. Internet Explorer 8 Beta 2 replaces the Developer Toolbar with an integrated set of integrated developer tools that can be accessed by pressing F12 or by clicking Developer Tools on the Tools menu. Because the Developer Tools are an integral component of the browser, performance is improved and no memory is used when the tools are not running. The integrated Developer Tools make it faster and easier for developers to develop and troubleshoot rich content sites.
Developer Tools to edit and debug CSS and HTML, test and debug script, profile script performance, view or change the document object model (DOM), examine applied rules, and trace the origin of style values—all within a rich, visual environment that exposes the browser’s internal representation of a Web page as it runs, instead of just its source code. In this way, you can rapidly iterate within Internet Explorer 8—for example, changing an attribute or a style rule and immediately viewing the results—and then save the HTML tree and CSS files to disk as text files for integration back into the original application. The Developer Tools also make it easy to toggle between the different layout engines included in Internet Explorer 8, enabling you to quickly and easily identify changes that must be made for sites to work well with older versions of Internet Explorer.
By eliminating the need to tweak source code in one program, save it, and then refresh the browser to view the results, the Developer Tools enable Web developers to rapidly prototype and test a new page, debug a problem, or just learn more about Web development.
The Developer Tools contain new JavaScript debugging tools with advanced features that allow developers to set breakpoints, step in/over code, watch variables, check locals, enter commands in the immediate window, and so on. It is just like a traditional code debugger but with JavaScript.
For more information the Internet Explorer 8 Developer Tools, see Discovering the Internet Explorer 8 Developer Tools.
CSS 2.1 Compliance
CSS is a simple mechanism for adding styles (such as fonts, colors, spacing, and positioning) to Web documents. Before the introduction of CSS, style-related properties were set directly within HTML, which produced many challenges for Web authors. Today, CSS has evolved to include a series of design patterns that allow authors to separate data from the display logic, thus improving markup organization and facilitating easier site maintenance.
Enabling Web developers and designers to write their pages once and have them render properly across all browsers is the main goal of CSS compliance. The CSS 2.1 Specification reached W3C Candidate Recommendation status as of July 17, 2007. The Internet Explorer 8 Standards mode layout engine was built with the CSS 2.1 spec in hand and full compliance in mind.
By shipping multiple engines and defaulting to Internet Explorer 8 Standards mode, Internet Explorer 8 Beta 2 will encourage developers to support the latest standards while allowing authors to fall back to Internet Explorer 7- compatible (or earlier) behavior if necessary.
Note that while Internet Explorer 8 Beta 2 is not fully CSS 2.1 compliant, the final release is planned to fully comply with the standard. For more information on CSS compliance in Internet Explorer 8 Beta 2 and changes since Beta 1, see “CSS Improvements in Internet Explorer 8” on MSDN.
Acid2 Test Compliance
Compliance with accepted standards in Internet Explorer 8 Beta 2 is evidenced by its passing the Web Standards Project’s Acid2 test, which uses a broad array of HTML and CSS commands to expose layout errors. However, in working to pass this test, Microsoft has encountered instances where the standards seem ambiguous or confusing. As part of its commitment to supporting Web standards, Microsoft has provided more than 1,000 certification test cases to the W3C for use by Web developers and other Web browser providers. The test cases are available for all to view in the “Windows Internet Explorer Testing Center.” By sharing its interpretation of specifications for Web standards with the community in such a way, Microsoft is inviting discussion and advancing the goals of standardized tests and a fully standardized Web.
More information on Internet Explorer 8 and the Acid2 test can be found in the following post to the Internet Explorer Team Blog: “Internet Explorer 8 and Acid2: A Milestone.”
HTML and DOM Improvements
The HTML language uses elements to represent structure and meaning in a document. To assist developers in taking full advantage of the elements offered by HTML 4, Internet Explorer 8 Beta 2 provides upgraded support for several presentational elements. For example, the Q element represents an inline quoted string, and the object element may now represent any “object,” including images. Through improved support for these and other HTML elements, Web developers can deliver more expressive and accessible HTML markup.
Some of the feedback regarding DOM functionality in Internet Explorer has been related to its attribute handling, which has not traditionally been compatible with the implementations used by other browsers. Internet Explorer 8 Beta 2 fixes many of the cross-browser inconsistencies, such as:
Separate URL handing for attributes and properties such that relative URLs can be retrieved by using the attribute and absolute URLs can be retrieved by using the property.
The element’s attribute array modifiers have been fixed so that the get/set/removeAttribute implementations are now compatible with those of other browsers.
The behavior of the attributes object reports the correct number of “attributes” associated with an element.
Default attributes for HTML are supported so that they always exist on elements whether specified in the markup or not, which aligns with the XHTML 1.1 DTD.
For more information on improvements to HTML and DOM support in Internet Explorer 8 Beta 2, see “HTML Enhancements in Internet Explorer 8” on MSDN.
Ajax Navigations
One of the significant benefits of using Ajax is the ability to update page content without traditional page navigations. This can be problematic in some scenarios because components like the Address bar, Back and Forward buttons, and the travelog (browser history) only update after page navigation. As a result, Ajax content updates don’t get saved as navigations, browser components don’t get updated, and end users are sometimes left confused as to why browser features are stuck on older content. While some Web sites work around this limitation by navigating a hidden iframe element while updating content through Ajax, this can result in degraded performance.
Pages rendered in Internet Explorer 8 Standards mode can handle navigations within their Ajax applications and update the travelog and Address bar by taking advantage of functionality added to the window.location.hash property.
For more information on Ajax navigations, see “Introducing Ajax Navigations” on MSDN, and download the Ajax Hands-on Lab on MSDN Code Gallery.
Today, Web pages use the document.cookie property to store data on the local machine. Cookies are limited in capability by the fact that only 50 key/value pairs can be stored per domain. Furthermore, the cookie programming model is cumbersome and requires that you to parse the entire cookie string for data.
Specified in the W3C’s HTML 5 Draft, DOM Storage objects provide a much simpler global and session storage model for structured data on the client side.
For more information on DOM Storage, see “Introduction to DOM Storage” on MSDN, and download the Ajax Hands-on Lab on MSDN Code Gallery.
Connection Events
As outlined in the W3C’s HTML 5 Draft, connection events allow Web sites to check whether the user is connected to the network. These events can be useful to the developers of dynamic applications because they enable the seamless handling of network connection changes. For example, if the network connection is lost, the application can use local cached data and inform users that it is unable to connect to network sources. When network access is restored the application can smoothly apply data updates and refresh current data.
Connection events can be raised on the body element of a document. In addition, the status may be checked at any time in script.
For more information on connection events, see “Connectivity Enhancements in Internet Explorer 8” on MSDN, and download the Ajax Hands-on Lab on MSDN Code Gallery.
Cross-domain Requests (XDR)
Cross-domain communication is an integral part of Ajax development and mashup applications. Making requests for data across domains can be challenging with today’s browsers, partly due to the prevailing interest of protecting users from cross-site attacks.
In Internet Explorer 8 Beta 2, Web pages can simply make a cross-domain data request (XDR) within the browser by using the new XDomainRequest object and without server-to-server requests. XDRs require mutual consent between the Web page and the server. You can initiate a cross-domain request in your Web page by creating an XDomainRequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending an Origin header with the value of the origin. It will only complete the connection if the server responds with an Access-Control-Allow-Origin: * header. These semantics are part of the W3C’s Web Application Working Group’s draft framework on client side cross domain that XDomainRequest integrates with.
For more information on cross-domain requests the Ajax Hands-on Lab on MSDN Code Gallery, the reference page for the XDomainRequest object on MSDN, and the Client-side Cross-domain Security Whitepaper on MSDN Code Gallery.
Cross-document Messaging (XDM)
Cross-document Messaging (XDM) provides the window.postMessage method, which allows different domains to communicate with each other given mutual consent. This feature can be used to help guarantee that application mashups are safer. XDM provides you with a simpler, more performant mechanism for two-way cross-domain communication than embedding iframe objects or hosting scripts from another domain.
For more information on cross-document messaging, see the reference page for the postMessage method on MSDN, and download the Ajax Hands-on Lab on MSDN Code Gallery.
Safer Mashups: HTML Sanitization
Internet Explorer 8 Beta 2 exposes a new method on the window object named toStaticHTML. When a string of HTML is passed to this function, any potentially executable script constructs are removed before the string is returned. Internally, this function is based on the same technologies as the server-side Microsoft Anti-Cross Site Scripting Library.
For more information on safer mashups with JSON sanitization in Internet Explorer 8 Beta 2, see this post on the Internet Explorer Team Blog, plus the reference page for the toStaticHTML method on MSDN.
Safer Mashups: JSON Sanitization
JavaScript Object Notation (JSON) is a lightweight string-serialization of a JavaScript object that is often used to pass data between components of a mashup. Unfortunately, many mashups use JSON insecurely, relying on the JavaScript eval method to “revive” JSON strings back into JavaScript objects, potentially executing script functions in the process. Security-conscious developers instead use a JSON parser to ensure that the JSON object does not contain executable script, but there’s a performance penalty for this.
Internet Explorer 8 implements the ECMAScript 3.1 proposal for native JSON-handling functions (which uses Douglas Crockford’s json2.js API). The JSON.stringify method accepts a script object and returns a JSON string, while the JSON.parse method accepts a string and safely revives it into a JavaScript object. The new native JSON methods are based on the same code used by the script engine itself, and thus have significantly improved performance over non-native implementations. If the resulting object contains strings bound for injection into the DOM, the previously described toStaticHTML function can be used to prevent script injection.
For more information on safer mashups with JSON sanitization in Internet Explorer 8 Beta 2, see this post on the Internet Explorer Team Blog.
Selectors are a query language for searching and “selecting” tags (elements) within a Web page. They are most commonly seen in CSS to “select” a group of elements to which certain properties will be applied.
In Internet Explorer 7, there is no way of “executing” a selector independently of CSS. The Selectors API in Internet Explorer 8 Beta 2 puts the power and flexibility of CSS selectors into the hands of the Web developer for rapid element lookups.
The Selectors API provides increased performance for non-linear element traversals and filters, an optimal choice considering the alternative of independent element lookups and manual script traversal of the DOM. This API also significantly reduces the amount of code required for lookups.
Internet Explorer 8’s implementation of the Selectors API is based on the W3C Working Draft for Selectors at http://www.w3.org/TR/selectors-api.
For more information on the Selectors API in Internet Explorer 8 Beta 2, see “Selecting Objects with JavaScript” on MSDN.
Data URI Support
Data URIs offer Web developers the opportunity to embed small external resources (like CSS files or images) directly into a URL on a Web page.
The primary use case for data URIs is the encapsulation of a binary file inside of a reference URL for a style sheet or image. Because the binary file can be represented inline as a string, it may be saved to the local store and retrieved at a later time without needing to fetch anything from the network.
Data URIs also offer an alternative to traditional URIs in that they don’t require a separate download. This is advantageous in scenarios where sub-downloads are blocked or unavailable. Data URIs may be up to 32kb in length and may not be used as the source of a frame, iframe, or script element.
For information on Data URI support in Internet Explorer 8 Beta 2, see the reference page for the data protocol on MSDN.
Improved Namespace Support
Internet Explorer 5 through Internet Explorer 7 provided limited element namespace support, but that was primarily used to remove an element from being treated as native HTML by the parser. Through element namespacing, Web developers have the ability to apply “behaviors” to those elements through special HTML markup known as HTCs (HTML Components) and COM developers the ability to apply “binary behaviors,” which are a type of ActiveX control. Only elements within a namespace can have a binary behavior applied to them.
Internet Explorer 8 Beta 2 improves its namespace support by reducing the amount of code necessary to instantiate and use a binary behavior. Once a user installs a namespace handler provided by a vendor, the handlers can be appropriately invoked and displayed as designed.
For more information on improved namespace support in Internet Explorer 8 Beta 2, see the Improved Namespace Support whitepaper on MSDN Code Gallery.
MIME-Handling Changes
Each type of file delivered from a Web server has an associated MIME type (also called a “content-type”) that describes the nature of the content (for instance, image, text, or application). For compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the content-type for each downloaded resource. In some cases, Internet Explorer reports a MIME type different from the type specified by the Web server. For example, if Internet Explorer finds HTML content in a file delivered with the HTTP response header Content-Type: text/plain, Internet Explorer determines that the content should be rendered as HTML. Because of the number of legacy servers on the Web (such as those that serve all files as text/plain) MIME-sniffing is an important compatibility feature.
Unfortunately, MIME-sniffing also can lead to security problems for servers hosting untrusted content. Consider, for instance, the case of a picture-sharing Web service which hosts pictures uploaded by anonymous users. An attacker could upload a specially crafted JPEG file that contained script content, and then send a link to the file to unsuspecting victims. When the victims visited the server, the malicious file would be downloaded, the script would be detected, and it would run in the context of the picture-sharing site. This script could then steal the victim’s cookies, generate a phony page, and so on.
To combat this problem, Internet Explorer 8 has a number of changes to the MIME-type determination code. These include restricting “upsniff” of files served with image/* content types into HTML and script, the ability to opt-out of MIME-sniffing, and a new mechanism to prevent untrusted content from compromising your site’s security.
For more information on changes to MIME handling in Internet Explorer 8 Beta 2, see this post on the Internet Explorer Team Blog.
Reach Beyond the Page
In addition to the improvements made to the underlying platform and developer experience, Internet Explorer 8 Beta 2 introduces new features that deliver new opportunities for Web developers to extend their experience beyond the Web page. These new features are enabled declaratively through community standards rather than building custom client code that is not interoperable across browsers.
Accelerators
Whether finding directions, posting blog entries, or performing other common actions, today’s Web users often find themselves copying and pasting information from one Web page to another. While the experience has been “good enough” so far, Internet Explorer 8 Beta 2 brings these powerful Web services one step closer through a new feature called Accelerators.
Accelerators are contextual services that provide quick access to external site services from any Web page. They typically involve one of two types of actions:
“Look up” information related to data in the current Web page.
“Send” content from the current Web page to another application.
For example, a user may be interested in the location of a venue displayed on the current page. In the past, the user would need to copy the address and paste it into a new browser window, unless the site’s developer had gone through the effort of integrating with a mapping service. By supporting the new “map” Accelerator, the user would get an in-place view of the map using his favorite mapping service on hover from any Web page, and can navigate to the Web page by clicking on the Accelerator.
|
