Archive

Posts Tagged ‘ie’

Conditional Comments cause CSS to block

November 13th, 2012 skotfred No comments

Here’s an odd one…. I’ve found that if you use the common method of using Conditional Comments to separate MSIE specific CSS, you’ve likely added a performance problem without knowing it… that is, in addition to the network connection and time required for the different CSS files.

It turns out that the standard use of this approach blocks the other downloads until the main CSS is loaded.

The solution is both simple and painless to implement…. just add an empty condition above all of the other content. This works for all approaches, such as those where comments surround the <body> or various <link>, <style> or <script> tags.


<!DOCTYPE html>
<!--[if IE]><![endif]-->
<html lang="en">
...

REFERENCES:

Categories: MSIE bugs, WebStandards, Work Tags: , , , , , , , , , , , , , , ,

Overriding MSIE’s Friendly Error Message screens

January 31st, 2012 skotfred No comments

IE overrides several HTTP error status pages but it has a size threshold. Only if the error page send by the server has a large enough body then IE decides it’s meaningful and displays it.

Usually to be safe you should make error pages that are larger then 512 bytes. The threshold varies per HTTP status code. You can look at what your thresholds are currently set to. In IE 5 and greater the settings are stored in the registry under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\ErrorThresholds]

Err Size(bytes):

  • 400 512
  • 403 256
  • 404 512
  • 405 256
  • 406 512
  • 408 512
  • 409 512
  • 410 256
  • 500 512
  • 501 512
  • 505 512

REFERENCES:

Categories: MSIE bugs, WebStandards, Work Tags: , , , , , , , , , ,

MSIE Conditional Comments

December 12th, 2011 skotfred No comments

This approach is useful in building standards based websites and allows you to prevent it from being “polluted” by various hacks used to support MSIE. MSIE5 and newer support the use of Conditional Comments and thus allow the developer to include additional files or markup for specific versions of the browser. Other browsers will see the content as an HTML comment and thus ignore it.


<!--[if IE]><style type="text/css">@import "/css/IE=Fixes.css";</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 IE 8]><style type="text/css">@import "/css/IE80Fixes.css";</style><![endif]-->
<!--[if IE 9]><style type="text/css">@import "/css/IE90Fixes.css";</style><![endif]-->
<!--[if lt IE 7]><script type="text/javascript" src="/wiki/skins/common/IEFixes.js"></script><![endif]-->

REFERENCES:

Categories: MSIE bugs, WebStandards, Work Tags: , , , , , , , , , , , , , , , ,

Dynamic HTML style tag with JavaScript

December 5th, 2011 skotfred No comments

I recently got into some heavy refactoring of legacy code and in an effort to “fix” some JavaScript that was directly manipulating ’style’ attributes on a DOM element and thus introducing maintenance and specificity issues I found that it would be “easier” to add a CSS class that I would write dynamically… leading to many headaches along the way and this bit of knowledge.

“For MSIE, you cannot simply write a ‘textNode’ into the DOM for HTML STYLE tags, you must use ‘cssText’”


function createClass(cls,txt){
var obj = document.createElement('style');
if(obj){
var head = document.getElementsByTagName('head')[0];
if(head){
obj.setAttribute('type','text/css');
obj.setAttribute('media','all');
var val = '.' + cls + '{' + txt + '}';
var nod = document.createTextNode(val);
if(obj.styleSheet){// MSIE
obj.styleSheet.cssText = nod.nodeValue;
} else {
obj.appendChild(nod);
}
head.appendChild(obj);
}
}

USAGE:

createClass('noshow','display:none;');

REFERENCES:

Categories: MSIE bugs, WebStandards, Work Tags: , , , , , , , , , , , ,

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

December 5th, 2006 skotfred No comments

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:

Categories: MSIE bugs, WebStandards Tags: , , , , , ,