The Eolas Patent Decision: What it Means for Web Designers

Quick Tip: Page (1) of 1 - 03/28/06

The problem and its background

My pappy always said to know your limitations, and in keeping with that time-worn wisdom, I am aware that I am most certainly not a lawyer. With that as the stated case, I'm not interested in attempting to provide a blow-by-blow synopsis of why Internet Explorer is being patched. After all, we're here to deal with how IE has been patched and what can be done to make sure embedded content keeps working the way it always has. That said, however, here is a quick 'n dirty rundown of the events as they currently stand, presented here in handy, bite-sized bullet list format:

Eolas, which claims to have created the first browser to support plugins, sues Microsoft for patent infringement over the display of embedded content (specifically, ActiveX controls) in Internet Explorer
Eolas wins a $500+ million judgment in 2003
Rather than pay, Microsoft plans an IE update for early 2004 to get around the patent
The US Patent Office (USPTO) agrees to re-examine the patent after an outcry from the Web community over the validity of the patent; the IE update is put on hold
After reviewing the case, the USPTO upholds Eolas' patent
Microsoft appeals; the Supreme Court punts on hearing the case
Again, rather than pay, Microsoft finally patches IE

I've left some details out, but that's the gist of it. The upshot is that last month, and with very little fanfare, Microsoft started pushing out an update to Internet Explorer (IE6 on Windows XP SP2 as well as the forthcoming IE7) that doesn't infringe upon the Eolas patent. This update makes all pages that use EMBED and/or OBJECT code (read: any page that makes use of a plug-in/ActiveX object) require a click from the user to "activate" the content, after which it will work normally. Figure 1 shows one example of what this looks like in the wild:

Figure 1

Well, isn't that just positively annoying. Now, in other cases, IE will throw up something a little less intrusive, but still irksome:

Figure 2

So, just to recap, we've got a spectrum that runs from "irksome" to "positively annoying," which is a cruddy spectrum any way you look at it. Fortunately, the issue can be worked around, restoring IE to what passed for normal behavior before the patent-avoiding update was issued. There are several ways to do it, but in general the answer lies in removing the "embedded" from "embedded content" using JavaScript, which seems to be at the heart of the litigation. As I mentioned, there is more than one way to skin this particular cat, but I'm going to go with the most straightforward method in the interest of making things real simple and quick to fix.

The workaround

Here it is in a nutshell:

Take the object/embed code out of the HTML file and put it into an external JavaScript file
Call the JS file from the HTML file

In the words of a TV ad that was making the rounds near the end of the last century, there's no step three. Of course, there are some details to work out, so allow me to break it down a bit. Let's say we're aiming to embed a QuickTime movie into a Web page. The typical code to do that would look a little like this:

<objectclassid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B"codebase="http://www.apple.com/qtactivex/qtplugin.cab" width="320" height="256"> <param name="src" value="test.mov" /> <param name="autoplay" value="false" /> <param name="controller" value="true" /> <embed src="test.mov" width="320" height="256" type="video/quicktime" pluginspage="http://www.apple.com/quicktime/download/" autoplay="false" controller="true" /> </object>

There are other parameters available, of course, but this is a simple, no-frills example here. Now, if this were left as-is in a HTML page, anyone who attempts to load said page in the Eolas-friendly IE6 will see something akin to what we saw in Figure 1. Since that's no good, it's time to move this code off of the HTML page and into a JavaScript document. So, let's cut and paste the code into a new document in a text editor, and save the document with a .js extension (e.g., test.js). I suppose we now have to convert this code into actual JavaScript so it works, huh?

Now, even if you've never written a single line of JavaScript, don't freak. All we're going to do is wrap each line in just a bit of extra code so JavaScript will actually be writing out the HTML, which means that we have to put document.write(' at the beginning of every line and '); at the end of every line. That's it. So, if we look at the new code in our test.js document, it should now look like this:

document.write('<objectclassid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" codebase="http://www.apple.com/qtactivex/qtplugin.cab" width="320" height="256">'); document.write('<param name="src" value="test.mov" />'); document.write('<param name="autoplay" value="false" />'); document.write('<param name="controller" value="true" />'); document.write('<embed src="test.mov" width="320" height="256" type="video/quicktime" pluginspage="http://www.apple.com/quicktime/download/" autoplay="false" controller="true" />'); document.write('</object>');

Doesn't look too different from the first version, does it? Told you it was easy. Anyway, one more step and we're done. We've got to do something about the gaping hole in the HTML file where the object/embed code used to be. So, let's go back to the spot in the HTML file where we cut out the original code, and let's put this line in its place:

<script language="javascript" type="text/js" src="test.js"></script>

Of course, the src path will need to be tweak if the test.js file isn't in the same directory as the HTML page, but you get the idea. Now, when someone looks at the HTML page using the patched version of IE6, they won't be greeted with any activation prompts. Problem solved.

But JavaScript?

Now, some may be a little dismayed that JavaScript becomes a necessity to work around this issue, because what if the user doesn't have JavaScript enabled? The answer, which the already dismayed among us really won't like, is "tough noogies." Right now, it's the cost of doing business to ensure that the extra activating click doesn't come into play. Microsoft didn't want to pay, so we all have to play. Besides, you can always make use of the <noscript> tag to warn users that JavaScript is required.

Anyway, that's it in a nutshell. It's not a great situation, but it is what it is and fortunately, the workaround isn't too painful (unless you already have a bunch of live sites that need the fix, in which case it just becomes an exercise in patience). And while Eolas got the last laugh when it came to Microsoft, the company has stated that it has no plans to go after other browser makers such as the Mozilla Foundation. Regardless, this fix is browser-agnostic, so if Eolas ever decides that other browsers are, in fact, fair game, you should already have the situation covered.

Page: 1

Though the fame, riches, and notoriety of being a DMN contributor are both tantalizing and substantial, Kevin Schmitt still stubbornly insists on continuing his work as the Director of Interactive Services at EFX Media, a production house located just outside of Washington, D.C. Feel free to follow his updates and contact him through Twitter if you have something to share - he's ready to believe you!

Related Sites: Digital Producer , Digital Webcast , Audio Video Producer , Corporate Media News , Digital Media Designer , Oceania , BN - Webcast , Flash
Related Newsletter: DMN Newsletter , CMN Newsletter , Pixels Newsletter , Streamline Newsletter , Digital Media Net , DMNForums , Tutorial Finder