Taming the OBJECT in Internet Explorer

last modified 2004-08-13 by jon

Introduction

This article and accompanying code are obsolete. While the script does work as advertised, there is now a more efficient approach. It is recommended that users migrate to the new version.

The following HTC file can be used to achieve correct support for <object type="image/*"> in Internet Explorer See IE Objectifier for a detailed analysis of the problem and the recommended solution.

The problem

To see Internet Explorer's problem, compare these two versions of the BBC news web site—one that uses images and the other that uses objects.

  1. BBC News <img> | screenshot
  2. BBC News <object> | screenshot

What happens is that Internet Explorer essentially renders objects of type image as if they were iframes having their own body and properties. This means that they have borders, margins and scrollbars which cannot be removed via CSS because they are part of a subdocument which is rendered independently of the parent window. The only way to remove them is to programatically access the body element of each object and restyle it.

The solution

Simply altering some of the display properties of the objects is inadequate. Internet Explorer needs to unlearn what it has learned about objects, and simply render them as if they were images. For the solution, we will write a basic HTC file. An HTC file is a special type of document that, among other things, allows us to define additional behaviors for standard HTML elements. Our HTC file will essentially hide each object and render an img instead. The objects are repaired as the document is parsed rather than when it is done loading.

The code

For each object of type image, we will essentially clone it with an equivalent img, hide the object, and insert the img in its place. While we could accomplish this in JavaScript, the HTC file offers two advantages: 1. We only need to reference it once (in our CSS) rather than from every page, and 2. HTC files are applied as the document is loaded, so the images will all be replaced before the page has finished loading.

<public:component>
  <script type="text/javascript"><!--
    if(element.type.substring(0,6) == "image/"){
      node = document.createElement("IMG");
      node.src = element.data;
      node.className = element.className;
      if(element.align)
        node.align = element.align;
      if(element.border)
        node.border = element.border;
      if(element.width)
        node.width = element.width;
      if(element.height)
        node.height = element.height;
      if(element.vspace)
        node.vspace = element.vspace;
      if(element.hspace)
        node.hspace = element.hspace;
      if(element.style.cssText)
        node.style.cssText = element.style.cssText;
      node.alt = element.innerHTML;
      node.alt = node.alt.replace(/^\s*(.*[^\s])\s*/,"$1").replace(/<[^>]+>/g,"");
      element.style.display = "none";
      element.insertAdjacentElement("afterEnd",node);
    }//-->
  </script>
</public:component>

Save this page as "object.htc". The last step is to link to it in our CSS via Microsoft's behavior property. Other browsers should ignore the non-standard property, but just to be safe we can use an IE-specific CSS hack—the star html hack. Place the following ruleset anywhere in your CSS. /path/ is the location of the HTC file.

* html object {
  behavior: url(/path/object.htc);
}

And that's it! Here's how it looks on an image-heavy page (80+ images). While it is noticeably slower than the original, it's not much worse than the one with objects. To be quite frank, speed is almost a non-issue. Unless it's a page of thumbnails, there is no good reason to have even 1/10 this number of images on a single page. Use CSS! Spacer gifs are so last century.

Unlike the scripting solution mentioned earlier, images are linkable, and the HTC file will respect browsers such as screen readers that have images turned off. Another nice feature is that the behaviors will be applied to the objects as they are parsed by the browser, rather than waiting for the document to finish loading. And because the images are being rendered as true images and not subdocuments, we will not experience any rendering delays when scrolling down the page.

End Notes

And with that we've achieved proper object support in IE by simply adding a rule to our stylesheet. Moral of the story: standards compliance is possible even with the unlikeliest of browsers.

Questions? Corrections? Suggestions? Email me. Feel free to use these scripts throughout your site with or without modification or acknowledgement, although a link to me is always appreciated. Email me if you would like permission to reproduce this article.

Additional Notes

  • Because IE does not support objects of type image/png, this does not work with PNG images. Also, IE is picky about JPEGs: image/jpeg will work but image/jpg will not.

Compatibility

Related Pages