In my first post on "Same Markup", I described the effort as an "n-way street". Each browser has a part to play by supporting the right features with the right behavior. Web developers also have a part to play in how they code for cross-browser differences where they unfortunately still exist. The most important part of working across browsers for web developers is to detect features, not browsers. So in this post I'll outline how to use feature detection for <canvas>, <audio>, and <video>.

Detecting Support from HTML Markup

Unlike other features, support for <canvas>, <audio>, and <video> can be detected directly from HTML markup. This involves simply using the desired element, then placing fallback content inside of it intended for browsers that don't have support for these elements. Browsers with support will hide this content from the user and display only the <canvas>, <audio>, or <video> element itself.

<!-- Example 1: Basic <canvas> fallback -->
<canvas> This text only displays in browsers without canvas support.
</canvas>

<!-- Example 2: Basic <audio> fallback -->
<audio> This text only displays in browsers without audio support.
</audio>

<!-- Example 3: Basic <video> fallback -->
<video> This text only displays in browsers without video support.
</video>

One caveat to keep in mind is that fallback content is only hidden visually. <script> blocks and other items in fallback content will always execute, even in browsers that support these elements.

<!-- Example 4: <script> always executes in fallback content -->
<canvas> <script> alert("This always runs, even when canvas is supported."); </script>
</canvas>

Of course, fallback content should also be useful. Exactly what qualifies as useful can vary depending on what you are trying to do. One approach is to point the user at a download for an upgrade, but in most cases it is a better experience for consumers to fall back to alternative approaches for delivering the content. For example, if you're drawing something that doesn't change much to a canvas, you may be able to fall back to an image that gets generated server-side. A better alternative could involve including a framework which implements canvas on top of existing web technologies or using a widely deployed plug-in.

The <audio> and <video> elements tend to have more options for fallback via plug-ins, whether through a media player or an app built on top of a widely deployed technology such as Flash or Silverlight. At the very least you can provide the user with a link to download the file so they can play it locally. The examples below provide a rough view of this type of fallback, though the <object> tag generally requires a number of varying parameters specific to the chosen plug-in.

<!-- Example 5: Provide useful fallback content for <audio> -->
<audio src="myaudio"> <object type="audio-plugin-mime-type" data="myaudio"> <a href="myaudio">Download the audio file</a> </object>
</audio>

<!-- Example 6: Provide useful fallback content for <video> -->
<video src="myvideo"> <object type="video-plugin-mime-type" data="myvideo"> <a href="myvideo">Download the video file</a> </object>
</video>

Detecting Support from Script

In addition to HTML markup, support for <canvas>, <audio>, and <video> can also be detected from script. This detection can be performed many ways, but one of the simplest is to check for the existence of the appropriate interface object off of window.

// Example 7: Simple feature detection for <canvas>
if(window.HTMLCanvasElement) { // Code requiring canvas support
}

// Example 8: Simple feature detection for <audio>
if(window.HTMLAudioElement) { // Code requiring audio support
}

// Example 9: Simple feature detection for <video>
if(window.HTMLVideoElement) { // Code requiring video support
}

An alternative approach for detecting <audio> and <video> involves checking for the existence of the canPlayType method on a dynamically created <audio> or <video> element. This is used by a number of frameworks and is generally preferred if you also intend to use the canPlayType method to test for supported codecs (which will be covered in a future post). If you simply need to test whether <audio> or <video> is supported, then I find the approach outlined above in examples 8 and 9 to be more obvious and equally as effective.

// Example 10: Alternate feature detection for <audio>
if(document.createElement("audio").canPlayType) { // Code requiring audio support
}

// Example 11: Alternate feature detection for <video>
if(document.createElement("video").canPlayType) { // Code requiring video support
}

A similar alternative approach can be used for detecting <canvas> support. In this case, most frameworks have settled on checking for the existence of the getContext method. This makes sense for <canvas> given that this method is required in order to retrieve a context for rendering.

// Example 12: Alternate feature detection for <canvas>
if(document.createElement("canvas").getContext) { // Code requiring canvas support
}

Next Steps

If you have previously used browser detection to decide whether to use <canvas>, <audio>, or <video>, now is the time to update to use feature detection instead. Also, make sure you have a DOCTYPE at the top of your page (e.g. <!DOCTYPE html>) so your content doesn't render in Quirks Mode. In IE9, Quirks Mode is used for compatibility and consequently the <canvas>, <audio>, and <video> elements will not work there.

Stay tuned for future posts covering how to detect supported codecs and specify multiple sources using the <audio> and <video> elements.

Tony Ross
Program Manager

Edit 9/3 - added link to earlier blog post in second paragraph

In my first post on "Same Markup", I described the effort as an "n-way street". Each browser has a part to play by supporting the right features with the right behavior. Web developers also have a part to play in how they code for cross-browser differences where they unfortunately still exist. The most important part of working across browsers for web developers is to detect features, not browsers. So in this post I'll outline how to use feature detection for <canvas>, <audio>, and <video>.

Detecting Support from HTML Markup

Unlike other features, support for <canvas>, <audio>, and <video> can be detected directly from HTML markup. This involves simply using the desired element, then placing fallback content inside of it intended for browsers that don't have support for these elements. Browsers with support will hide this content from the user and display only the <canvas>, <audio>, or <video> element itself.

<!-- Example 1: Basic <canvas> fallback -->
<canvas> This text only displays in browsers without canvas support.
</canvas>

<!-- Example 2: Basic <audio> fallback -->
<audio> This text only displays in browsers without audio support.
</audio>

<!-- Example 3: Basic <video> fallback -->
<video> This text only displays in browsers without video support.
</video>

One caveat to keep in mind is that fallback content is only hidden visually. <script> blocks and other items in fallback content will always execute, even in browsers that support these elements.

<!-- Example 4: <script> always executes in fallback content -->
<canvas> <script> alert("This always runs, even when canvas is supported."); </script>
</canvas>

Of course, fallback content should also be useful. Exactly what qualifies as useful can vary depending on what you are trying to do. One approach is to point the user at a download for an upgrade, but in most cases it is a better experience for consumers to fall back to alternative approaches for delivering the content. For example, if you're drawing something that doesn't change much to a canvas, you may be able to fall back to an image that gets generated server-side. A better alternative could involve including a framework which implements canvas on top of existing web technologies or using a widely deployed plug-in.

The <audio> and <video> elements tend to have more options for fallback via plug-ins, whether through a media player or an app built on top of a widely deployed technology such as Flash or Silverlight. At the very least you can provide the user with a link to download the file so they can play it locally. The examples below provide a rough view of this type of fallback, though the <object> tag generally requires a number of varying parameters specific to the chosen plug-in.

<!-- Example 5: Provide useful fallback content for <audio> -->
<audio src="myaudio"> <object type="audio-plugin-mime-type" data="myaudio"> <a href="myaudio">Download the audio file</a> </object>
</audio>

<!-- Example 6: Provide useful fallback content for <video> -->
<video src="myvideo"> <object type="video-plugin-mime-type" data="myvideo"> <a href="myvideo">Download the video file</a> </object>
</video>

Detecting Support from Script

In addition to HTML markup, support for <canvas>, <audio>, and <video> can also be detected from script. This detection can be performed many ways, but one of the simplest is to check for the existence of the appropriate interface object off of window.

// Example 7: Simple feature detection for <canvas>
if(window.HTMLCanvasElement) { // Code requiring canvas support
}

// Example 8: Simple feature detection for <audio>
if(window.HTMLAudioElement) { // Code requiring audio support
}

// Example 9: Simple feature detection for <video>
if(window.HTMLVideoElement) { // Code requiring video support
}

An alternative approach for detecting <audio> and <video> involves checking for the existence of the canPlayType method on a dynamically created <audio> or <video> element. This is used by a number of frameworks and is generally preferred if you also intend to use the canPlayType method to test for supported codecs (which will be covered in a future post). If you simply need to test whether <audio> or <video> is supported, then I find the approach outlined above in examples 8 and 9 to be more obvious and equally as effective.

// Example 10: Alternate feature detection for <audio>
if(document.createElement("audio").canPlayType) { // Code requiring audio support
}

// Example 11: Alternate feature detection for <video>
if(document.createElement("video").canPlayType) { // Code requiring video support
}

A similar alternative approach can be used for detecting <canvas> support. In this case, most frameworks have settled on checking for the existence of the getContext method. This makes sense for <canvas> given that this method is required in order to retrieve a context for rendering.

// Example 12: Alternate feature detection for <canvas>
if(document.createElement("canvas").getContext) { // Code requiring canvas support
}

Next Steps

If you have previously used browser detection to decide whether to use <canvas>, <audio>, or <video>, now is the time to update to use feature detection instead. Also, make sure you have a DOCTYPE at the top of your page (e.g. <!DOCTYPE html>) so your content doesn't render in Quirks Mode. In IE9, Quirks Mode is used for compatibility and consequently the <canvas>, <audio>, and <video> elements will not work there.

Stay tuned for future posts covering how to detect supported codecs and specify multiple sources using the <audio> and <video> elements.

Tony Ross
Program Manager

Edit 9/3 - added link to earlier blog post in second paragraph

First, let’s look at mark-up based add-ons in IE. These add-ons describe their functionality without any executable code, typically using XML. Examples are OpenSearch providers, Web Slices, and Accelerators. There is no code in the add-on itself and no code involved when the add-on is installed. Consumers install these add-ons from within the browser. There is clear consumer consent as part of that in-browser installation experience:

Binary add-ons, like Toolbars and BHOs, are full Windows programs that run within the browser. The installers for these Windows programs are other Windows programs that run outside the browser. Some add-on installations are the result of a user explicitly seeking them out and installing them. Other add-on installations are bundled with other software. These can be a surprise to users, and are often installed without explicit consent.  Technically, browsers can only detect that an add-on was installed, not what consent the user gave during installation. We hope you’ll share your favorite examples of software installation surprises in the comments. It is not clear from within the browser what consent (if any) a consumer has given when one of these add-ons is installed. It is clear that the next time the user starts IE, the new add-ons will affect browser performance and reliability, and possibly privacy.

Add-ons can also affect privacy. Additional code running in the browser can send user information to websites. (You can read more about an add-on that sent user information inappropriately here.) For this reason, when users start IE8’s InPrivate Browsing feature, IE runs without toolbars and BHOs. The user expects an InPrivate session to be private, and there is no way for IE to know what information add-ons save on the user’s system or send to websites. 

Because many add-on setup experiences surprise users, some browsers today seek user conformation before they run newly installed add-ons. For example, here’s the dialog that Firefox 3.6 shows the first time the user starts it after installing an add-on:

Note that before seeing this prompt, the user initiated the add-on installation explicitly and clicked two prompts within the browser to install the add-on.

On today’s web, consumers face many different threats to browser security, reliability, performance, and privacy. We work closely with other software vendors to make experiences within IE better for consumers. For example, we exchange feedback with toolbar vendors about their work and the IE Add-on Guidelines and Requirements. Many times, these conversations result in improvements to add-ons. Microsoft treats all add-ons and software vendors consistently with respect to these guidelines and requirements. Given the ambiguities and risks around add-ons, consumers benefit from having more information and more control over how add-ons are installed.

Herman Ng

Program Manager, Internet Explorer

• Windows MSI / Windows Classic
  
• Mac (Universal) / Mac (Intel-only)
  
• Linux/FreeBSD

In this post I want to dive into the details of some of these programming model changes. You can take advantage of these enhanced DOM capabilities in the latest platform preview build. To highlight these changes, I’ll reference the Enhanced DOM Capabilities demo page that we released with the fourth Platform Preview.

That demo tests 24 capabilities that span 4 general categories:

• DOM object inheritance from native JavaScript objects
• JavaScript functional harmony with DOM objects
• Interoperable programming features
• New ECMAScript 5 support applied to DOM objects

The first two are closely related, so I’ll discuss them together:

DOM object inheritance from native JavaScript objects and JavaScript functional harmony with DOM objects.

Prior to IE9, the JavaScript engine was connected to the DOM via classic COM bindings. These legacy bindings allowed for only primitive object and function representations of the DOM to the JavaScript engine. Consequently, many basic JavaScript features that developers expected to be available to all objects and functions (including DOM objects like Window, Document, NodeList, etc.) were only available to native JavaScript objects (Array, Number, etc.).

The ECMAScript standard specifies basic operations that should work uniformly on all JavaScript objects, but allows “host objects” to deviate from those standard specifications. IE’s old JavaScript engine treated DOM objects as “host objects” which meant that basic JavaScript operations such as property access could behave oddly. While allowed by ECMAScript, inconsistent behavior between DOM objects and JavaScript objects created differences web developers had to account for.

For example, one common puzzler for many web developers was why IE DOM functions were reported as “object” to the typeof JavaScript operator rather than "function" (this capability is specifically checked in the demo as piece #10).

In IE9’s Standards Mode, we build our DOM as native JavaScript objects and functions rather than as “host objects,” thus enabling the features that web developers expect from native objects.

Interoperable programming features

The third group of capabilities showcase unique IE programming model behaviors that web developers commonly stumbled over. Because these behaviors were unique to the IE programming model, web developers found that their code didn't work the same across different browsers.

As part of our new integration architecture, we removed many of the inconsistencies that kept the same script from working the same way across browsers. The programming model changes may cause sites that have conditional code written for IE to behave differently in IE9 than it did before. Therefore, it is worthwhile describing these changes in more depth.

Functions now enumerated

In IE8 and before, enumerating a DOM object did not include any of that DOM object’s member functions. IE9 now enumerates any property on a DOM object that has its “enumerable” property descriptor value set to ‘true’. (In other words, enumeration can be programmatically altered.) Functions are now enumerated by default to be consistent with other browsers.

Removed implicit function invocation

DOM functions in previous versions of IE were quite special. Not only did they claim to be typeof “object”, but they also retained a static ‘this’ value which referred to the object to which they belonged. Consequently, it was possible to cache a reference to a DOM function, and invoke it without explicitly passing the ‘this’ value:

// Works in IE8 and earlier versions
// Doesn't work in IE9 or other browsers
var cachedGetElementById = document.getElementById;
cachedGetElementById('value');

In IE9, this now throws an exception, as it does in other browsers. Code that formerly depended on this IE behavior may use the “.call” workaround:

// Works in IE8/IE9 and other browsers
// Doesn't work in IE7 and earlier versions;
var cachedGetElementById = document.getElementById;
cachedGetElementById.call(document, 'value');

ECMAScript 5 provides a “bind” method for functions which allows them to take on the programming characteristics formerly supported by IE:

// Works natively in IE9 because of ECMAScript 5's 'bind' API
var cachedGetElementById = document.getElementById.bind(document);
cachedGetElementById('value');

Support for DOM exceptions and ‘const’ properties

The IE9 enhanced DOM now includes W3C-specified DOM exception objects and standardized error codes that web developers can use to determine (generally) the nature of a DOM API failure. These codes are commonly compared against well-defined 'const' properties to aid in code readability:

…
catch(ex) {
   if (ex.code == DOMException.INDEX_SIZE_ERR)
      …
}

The enhanced DOM provides the pre-defined 'const' properties as well as the architecture to throw and catch DOM exceptions.

Consistent toString behavior

With Chakra and the DOM fully integrated, the DOM does not have its own implementation of toString (a function that converts any object into a string form). While the old DOM’s toString implementation was similar to the JavaScript built-in version, it was not the same and often returned inconsistent or puzzling results. IE9 DOM objects now inherit and use the JavaScript built-in toString for more uniform results.

Separation of property and attribute storage

In the previous architecture, DOM objects had their own property storage. This property storage was the same as the storage location for attributes (those found in the HTML markup). With IE9's new architecture, an element’s attribute storage is now separate from the dynamic properties assigned to an element's script object. To illustrate this separation, consider the following example markup:

<div id="myId" class="c" user-defined-attribute="test">

In the above example, “id”, “class”, and “user-defined-attribute” are attributes. The div element's JavaScript object also exposes similar properties:

// Get the JavaScript object representing the body
var divOb = document.getElementById(‘myId’);
divOb.id;        // "myId"
divOb.className; // "c"

These JavaScript properties retrieve the values stored in an element’s attribute list. For example, “id” retrieves the value of the “id” attribute. “className” retrieves the value of the “class” attribute.

In previous versions of IE, any dynamically-added properties would “magically” appear in the element’s attribute list and vice-versa due to the shared storage location. This could lead to unexpected results:

<div id="myId" class="c" user-defined-attribute="test">
…
var divOb = document.getElementById("myId");
// The next statement unexpectedly adds "userProperty" as
// an attribute to the element.
divOb.userProperty = "test"

// How many attributes?
alert("Total attributes = " + divOb.attributes.length);

IE9 and other browsers alert three total attributes ("id", "class", and "user-defined-attribute"), whereas previous versions of IE alert 4, adding "userProperty" to the list. The reverse example is more common—code that expects user-defined attributes to appear as dynamic properties:

<div id="myId" class="c" user-defined-attribute="test" userAttribute="test">
…
var divOb = document.getElementById("myId");
// Get the "userAttribute" and "user-defined-attribute" value
// (only worked in IE8 and previous versions)
var value1 = divOb.userAttribute;
var value2 = divOb["user-defined-attribute"];

We’ve seen a lot of code that expects this legacy IE behavior. The interoperable way to retrieve unknown attributes is to use “getAttribute,”

var value1 = divOb.getAttribute("userAttribute");
var value2 = divOb.getAttribute("user-defined-attribute");

and dynamic properties should not be queried through the attributes collection.

New ECMAScript 5 capabilities

In the last group of capability tests, new functionality provided by Chakra’s implementation of ECMAScript 5 is applied to the DOM. One of the primary goals for the enhanced DOM in IE9 was to provide a representation of the DOM that made logical sense within the context of the ECMAScript 5 language semantics. This was made much easier because one of the primary goals of ECMAScript 5 is to better support the functionality needed by DOM objects! In our implementation, we represented the DOM using as many native ECMAScript 5 language features as possible, including extensive use of accessor (getter/setter) properties.

This native integration allows all of the new ECMAScript5 features to work equally well with native objects as with DOM objects.

The enhanced DOM capabilities demo shows only 24 samples of what is possible when the DOM is fully integrated with an ECMAScript 5-capable JavaScript engine like Chakra. We are very excited about this support in IE9 and want to help get better interoperability for ECMAScript language bindings across browsers. An important step is standardizing these binding within the W3C, and we’re happy to contribute to that effort.

W3C web standards have always supplied a language binding for ECMAScript implementations as a way to translate the standard IDL (Interface Definition Language) into JavaScript objects. However, these bindings lacked sufficient detail to create much more than a simple “host object” binding (a binding without consideration of the full spectrum of ECMAScript language features). While other browsers have a much more comprehensive language binding than simply “host objects,” integration inconsistencies remain. These inconsistencies can really frustrate JavaScript framework developers who wish to write abstraction layers and features on top of the basic language support. The need for consistency led to a proposed standard called WebIDL (Web Interface Definition Language). The WebIDL specification describes in much more precise detail, how to translate a given W3C spec written using WebIDL into JavaScript objects.

In a follow-up post, I will describe in more detail how we used WebIDL to inform and guide the development of the IE9 enhanced DOM.

Please testdrive the IE9 enhanced DOM. We look forward to your comments and feedback.

Travis Leithead
IE Program Manager