MSIE Conditional code

This is not so much as a MSIE bug, but rather a non-standard “feature” (added in MSIE 5.5) that is often helpful when constructing websites that you try to build with valid XHTML and CSS. As all non-Microsoft browsers will see these as simple
HTML markup comments, it gives you the flexibility to deal with the inconsistencies and quicks in the various versions of MSIE. This is particularly important for the numerous changes introduced with MSIE7.

I’ve tested this with <style />, <script /> and <meta /> tags, but wouldn’t doubt that it works anywhere (but don’t see any typical situations for that!)

Some simple instructions:

  1. Start with an HTML comment
  2. Add the opening brackets, so it resembles <!–[if …]>
  3. Add the closing brackets too… <![endif]–> (don’t forget that extra less than and bang/exclamation point!)
  4. Add the versioning info, this should be pretty obvious, but i’ll list the most common ones.
    IE 7 = MSIE7
    IE 6 = MSIE6
    IE 5.5000 = MSIE 5.5
  5. Some modifiers, (should you want a range of versions):
    lt = Less Than
    gt = Greater Than
  6. Make sure that the body content of the tag (which now resembles an HTML comment) is coded.
  7. That’s it, now be sure to test for expected behaviors!

Some Examples:

<!–[if IE 6]>
<style type=”text/css”>
/* <![CDATA[ */
html {
overflow-y: scroll;
}
/* ]]> */
</style>
<![endif]–><!–[if lt IE 5.5000]><style type=”text/css”>@import “/css/IE50Fixes.css”;</style><![endif]–>
<!–[if IE 5.5000]><style type=”text/css”>@import “/css/IE55Fixes.css”;</style><![endif]–>
<!–[if IE 6]><style type=”text/css”>@import “/css/IE60Fixes.css”;</style><![endif]–>
<!–[if IE 7]><style type=”text/css”>@import “/css/IE70Fixes.css”;</style><![endif]–>
<!–[if lt IE 7]><script type=”text/javascript” src=”/js/IEFixes.js”></script>
<meta http-equiv=”imagetoolbar” content=”no” /><![endif]–>

Cheers!

MSIE6 javascript memory leaks

Argh…. yet again, this crappy product has another bug that developers must work around!

It seems that Microsoft doesn’t release memory to javascript objects from memory when created on a page… even when the page is unloaded.

Let’s think about this one for a second, why would you want to keep a javascript variable or DOM reference in memory after the user has navigated away from that page? This violates the stateless paradigm that web applications generally work with, besides… how would a developer be able to get that information (memory) back on the next page anyways? Perhaps, it was some genious that tried to keep state in javascript when the ‘BACK’ button was pressed… we’ll probably never know.

There’s a great quote I found while researching this…

“IE has an issue where it leaks memory when a circular reference is created between a COM object and a javascript object. In IE, the DOM is implemented via COM ….. This memory is not reclaimed until the browser closes. The simplest solution is to pretend there is no garbage collector for objects and make sure you always clean-up after yourself.”

References:

Microsoft ‘chimes in’:

Tools to help:

Cheers!

MSIE6 background-image caching (or lack of it…) and flickering

This has been an annoyance of this (IMHO very buggy) browser since it was first beta tested. Earlier (5.x) and newer (7.x) versions do not exhibit this problem.
For some reason Microsoft developers broke the caching mechanism for background images, particularly when defined in CSS. This makes for slow screen painting as well as wasted network traffic as each occurrence of the image becomes a new HTTP request to the webserver. This also causes a notable delay in those images painting on the screen and ‘flicker’ when the images are used in CSS rollover effects. Since the image obviously isn’t changed it results in many ‘HTTP 304 Not Modified‘ entries in the server logs.

Fixes…

1. You CAN/SHOULD set the Expiry for the images, however this can be problematic. Since I typically run Apache HTTPD, those instructions follow:

a) Set an explicit expiry time based on MIME types in the http.conf file.

[instructions in separate post]

b) Enable .htaccess for the server and allow its usage in individual folders on the server.

[instructions in separate post]

c) Use client-side technologies to hack around the problem…. you can use many CSS tricks, but I’ve found that JavaScript is the easiest (most compatible) method.

Add the following to a method executed in the onload event of the page…

<script type=”text/javascript”>
try {
document.execCommand(‘BackgroundImageCache’, false, true);
} catch(e) {}
</script>
NOTE: MSIE will execute the Javascript, Mozilla and other browsers will throw an exception and wind up in the catch block… which ignores the problem.

UPDATE:
With the use of conditional comments, this can be added to an MSIE specific JS file, or even better an MSIE specific CSS file containing the following:


html {
filter: expression(document.execCommand("BackgroundImageCache", false, true));
}

REFERENCES:

<option disabled=”disabled”>?</option> not implemented in MSIE

This was a complete shock to me recently, even after years of ‘assuming’ that something this simple would be well supported… after all, this is pretty basic.

All modern browsers Mozilla (Firefox), Safari, Opera, even old Netscape (eg: 4.x) browsers work properly with the following code and comply with the W3C HTML specification making the value “Two” unable to be selected by the user within the browser… MSIE doesn’t comply and allows the user to select it!

<form name="example" action="#" method="get">
<select name="test">
<option value="1">One</option>
<option value="2" disabled="disabled">Two</option>
<option value="3" selected="selected">Three</option>
<option value="4" style="color:green;">Four</option>
</select>

</form>

This ‘failure’ to support standards actually seems to be due to the way the <select> tag is handled by the browser… it passes off control to the operating system (Windows). Obviously, Microsoft was able to pass along ‘other’ attributes, like ‘style’ in the example above, but chose to not support ‘disabled’.

In this case, the developer is left to find a solution… easiest is to just remove the unwanted value from the list of options, otherwise it requires extensive amounts of JavaScript.

Good luck!

NOTE: Tested on MSIE 6.0 (WinXP), hopefully Microsoft will fix this in MSIE7.

NOTE: this process is obsolete, from what I can gather it was only supported in MSIE6, and possibly MSIE7.

Use of this tag will disable the Image Toolbar (normally accessed via right-click) within MSIE. Typically it is enabled whenever an image larger than 130×130 is displayed.

Implementation:
Add the following to the <head> section of your webpage(s):
<meta http-equiv="imagetoolbar" content="false" />

Alternately, you COULD use some proprietary MSIE attributes on the <img /> tag.
<img src="..." galleryimg="false" />

Even when you use the META tag to disable this feature for all images, you can explicitly re-enable it with the following proprietary tag…
<img src="..." galleryimg="true" />

References:

NOTE: this is an obsolete practice, and should be removed unless you plan to support beta versions of MSIE6.

The story behind this tag is one of virtue. Microsoft, as they do TOO often, added a ‘feature’ in beta versions of Windows XP (MSIE 6.0) that enabled the browser itself to analyze the content on a given page, and insert links to other websites. This was "e;spun" as being good the the visitors of your website, because they could be exposed to related products or services. Unfortunately, the webmaster and site owners had no say in what content was being linked or to where… which could be a competitor!

This tag was added as a method to prevent these "Smart Tags" from operating on websites… in the end, Microsoft did not leave this feature (enabled?) in the released version of Internet Explorer 6!

BTW, there are some JavaScript libraries today that offer similar functionality, but they are not related to this tag.

Implementation:
Add the following to the <head> section of your webpage(s):
<meta name="MSSmartTagsPreventParsing" content="TRUE" />

REFERENCES: