Working under the Eolas settlement in Internet Explorer

I'm leaving this page up in the offchance someone cares to read it, but as of the moment, everything written here is no longer necessary since IE has held off on their changes to enforce the Eolas workaround Read More Here. Instead I'm rewriting this article to re-explain a method that originally showed up here, which is how to embed media online using standards compliance html and discussing the benefits of throwing away that old <embed> tag. You can see progress on the technique in my tests folder.

 

 

By now, many readers are aware of the court rulings that affect embedding media in Internet Explorer. The solutions that exist so far are going to be a pain to implement in old files. There is however an easy fix to this whole mess that will leave your html more standards compliant and cleaner than it ever was before. The solution outlined below was originally intended for another article on XHTML but this seems more fitting.

What's Changing

If you've worked with embedding Flash or Quicktime media then this code probably looks familiar. This code will no longer seamlessly load in IE, instead the browser will force a dialog box over the object asking if the user would like to load the data.

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,79,0" width="550" height="400">
	<param name="movie" value="flashmovie.swf">
	<embed src="flashmovie.swf" width="550" height="400" type="application/x-shockwave-flash" pluginspace="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"></embed>
</object>
Official Fixes

As I understand it, the Eolas patent restricts IE from having inline code create a control that accesses external data. That means that either the control must be created from external code, or the control can be created from inline code only if it accesses inline data. More info here

Now, the only way to avoid getting a popup dialog is to: 1. Use a custom built external javascript file to create the control, which most people will probably find easiest 2. base64 encode their files and inline embed them into the object tag, which most people wont use because it balloons the html file size to an unacceptable level. You can see both these examples in use here. Personally I dislike both ways and would hate to go back through old files to implement either of them.

HTC Behaviors

When coming up with the solutions above, Microsoft seems to have overlooked it's own stepchild to javascript: behaviors. Behaviors were introduced in IE 5 as a way for html objects to inherit scripts through runtime parsing. They have a distinct advantage over regular javascript implementations by being able to execute methods on a tag as soon as it's parsed, as well as the ability to immediately listen to tag events. One of the better all-purpose .htc behaviors floating around the web is located at http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html. This behavior provides true alpha support for PNG files in IE. Overall, behaviors offer a much better way of implementing advanced dhtml functionality over waiting for a body.onload event to fire and then scouring the document tree to add methods and properties to html objects. The downside to using behaviors is that only IE supports them. I remember reading that Microsoft was pitching the idea to include them into the W3C spec with no success, maybe the W3C will start listening if Eolas goes after other browser makers.

If you would like to know more about how to create .htc files, please visit msdn.

HTC Implementation

Before getting into the actual implementation of the .htc file, I want to go over a bit about media in other browsers. The majority of media developers still think that they need to use an <embed> tag to get media elements to show in non-IE browsers. This hasn't been true for a quite a while now, and using the embed tag requires that you fall back on old html standards. Almost every current browser on the market supports loading plugin controls and other external data through an <object>. The W3C spec goes into more detail about all the options available for using <object> as well as good examples illustrating the power they offer for web developers. So, going forward, this script is focused on providing an <object> only implementation of embedding media.

Our new code

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XHTML/Eolas Compliant Media</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css"> object { behavior:url('activex_switch.htc') } </style>
<script type="text/javascript" src="activex_switch.js"></script>
</head>
<body>
	<object id="flashmovie" data="standards.swf" width="300" height="200" type="application/x-shockwave-flash;"></object>
</body>
</html>

NOTE: IE DOES NOT RENDER THE ABOVE OBJECT TAG, NO ACTIVEX CONTROL IS CREATED FROM THE HTML CODE. At first it might look like the code above would create a popup, but a closer look at the shortfalls of IE reveal why everything checks out. All you need to do is point to the behavior "activex_switch.htc" in the style definition for object tags and include the file "activex_switch.js" for now. I'll discuss below why we can hopefully get rid of that .js include.


Why everything works out

The object tag above simply doesn't register with IE because of the trailing semicolon place in the type attribute. This method should look familiar to java users who are used to putting the version number inside the type attribute (type="application/x-java-applet;version=1.4") In effect, the activex control is not initialized by the html code. Even though IE has ignored the object tag above, it still applies behaviors and other runtimeStyles to the object. When the behavior executes it determines if a proper external control should be created to display the media type. This is important for forward compatability in the case where Microsoft can use objects to display images and iframe data that have proper element types like "image/jpg" or "text/html". Once the media type checks out, the behavior sets out to overwrite the current dead object with a new one, this is where the included .js file comes in to play. Microsoft is playing it safe at the moment and only letting external .js files dynamically create activex controls. Technically, Microsoft can expose behaviors to this functionality as well cause they operate as an external file, but whether they've specifically excluded behaviors, or just forgot to include them for the test browser remains to be seen. If this can be brought to their attention before the official patch is released, we can discard the .js file, but for now it must be included.

As for the rest of the browsers on the market, most of them don't mind dealing with a semicolon when defining the mime type of an object. Most non-IE browsers parse the object tag exactly as they should and display the media element.

Tackling non-IE issues

In the example above, we've set the type attribute with an appended semicolon in the object to trick IE. This also tricks some of the other browsers on the market into not rendering the object. Fortunately, these browsers don't mind being fed a skewed codetype attribute to render the object. This method will allow PC/Mac Netscape, Camino, and Mac Opera to render the object too.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XHTML/Eolas Compliant Media</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css"> object { behavior:url('activex_switch.htc') } </style>
<script type="text/javascript" src="activex_switch.js"></script>
</head>
<body>
	<object id="flashmovie1" data="standards.swf" width="300" height="200" type="application/x-shockwave-flash;">
		<object id="flashmovie2" data="standards.swf" width="300" height="200" codetype="application/x-shockwave-flash;">&#09;</object>
	</object>
</body>
</html>

USE THIS CODE TO EMBED ALL YOUR MEDIA


Mac IE still can't render the object above because of appended semi-colon, and there is no way of getting an <object> to show on Mac IE that doesn't also cause it to show on PC IE, so unfortunately we have to drop support for this browser. Luckily, that browser has been on it's way out the door and by the time we need to start fixing our pages, Mac IE might be all but dead. Please note in this example the inclusion of the empty character &#09; inside the innerHTML of the second object tag. This covers a two part bug: 1. IE renders all objects nested inside an object, even though the W3C spec says it shouldn't 2. IE renders out a broken image tag unless there is content to swap out. Make sure you don't add this character inside the first object tag.

Not Done Yet

Ideally we should be able to use the new attribute NOEXTERNALDATA="true" to keep IE from acknowledging the object. There are still a lot of bugs regarding this attribute. Microsoft treats object tags differently then the rest of the browsers, when an activex control is started, it sweeps the param tags for a source file. This is actually wrong and IE should be using the data attribute instead. Since we are using the data attribute above, IE gets confused and still tries to load it even with NOEXTERNALDATA="true" set.

Additionally, when using the attribute NOEXTERNALDATA="true" the object tag fails to load in all non-IE browsers, which pretty much rules out any use of it. It is still an important attribute because it could allow us to do away with the type/codetype hacks above to stop IE from rendering.

Taking this into to consideration as well as exposing behaviors to dynamically create controls, the new proposed method of building object tags would be:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>XHTML/Eolas Compliant Media</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">
object {
	behavior:url('activex_switch.htc');
}
</style>
</head>
<body>
	<object id="flashmovie" data="standards.swf" width="300" height="200" type="application/x-shockwave-flash">
		<param name="MSnoexternaldata" value="true" />
		Alternate Content
	</object>
</body>
</html>

Render events in this proposed method

The above scenario meets two requirements

1. If the user doesn't have a plugin that can correctly render the supplied mime type, the object isn't rendered, and thus the behavior isn't applied; also the browser renders the alternate content. This is exactly how IE currently operates.

2. If the user does have a plugin registered to that mime type, the object is rendered and most likely, the activex control is started. The param "MSnoexternaldata" would then force the activex control to close. At this point, since the object has successfully rendered, the external behavior file would kick in and write a new object tag minus the MSnoexternaldata param. The param "MSnoexternaldata" must act differently then the current attribute implementation of noexternaldata="true" which simply forces the control to not recieve data, but keeps the control open and hanging while waiting for data to arrive.

This propsed method would allow us to render the object in Mac IE as well as shorten up the amount of code necessary to display the object in other browsers. Also notice with this implementation we would only need an .htc behavior to create the control. For backwards compatability on IE browsers without the patch, we would need to add <param name="movie" value="standards.swf" /> back into the method above, I didn't add this into the example code because I didn't want to highlight the use of this param tag in an official workaround, IE should start reading the data attribute from here forward.

 

The only way to make this happen though is to call Microsofts attention to these requests before the patch is officially released.

Examples

Passing <param>'s into the object

Embedding Flash, Quicktime, and WAV files on the same page

Testing Notes
Additional Notes

I've done a ridiculous amount of research trying to write this article and would be happy to work with Macromedia, the W3C, or Microsoft to get the flurry of information I have about object tags and IE out of my head and into the official IE patch.

I need more mime types and plugins to add to the translation table inside the script that writes the control, right now I only know a few proprietary mime types for Media Player and Quicktime, but found a whole list for Real Player. If you have a list of these mime types, please send them to me.

If you have any information or corrections to add to this page, please email me at developer@mustardlab.com.

Download

Behavior File: activex_switch.htc

Javascript File: activex_switch.js

Total Size: 8 kb

Last Updated: 2003-10-09


Testing Files ONLY

Behavior File: TESTING_activex_switch.htc

This is the behavior file that would be used if Microsoft exposed external behaviors to create activex controls. Use it like shown in the proposed implementation above without including the javascript file. At the moment it will cause a popup dialogue to appear.