No, you are not going crazy… MSIE 6 and 7 are case sensitive for the ‘frameBorder‘ (and a few other attributes).
It seems that the JavaScript attribute names are expected to be used in the HTML, should you expect them to behave and look properly you’ll have to make some small changes to support, this is even more important when using JavaScript to update or change attributes.
<iframe... frameBorder="0"></iframe>
Categories: MSIE bugs, WebStandards, Work Tags: attr, attributes, border, case, css, frame, frameBorder, html, iframe, javascript, sensitive, xhtml
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: block, blocking, browser, comments, conditional, connections, css, files, hacks, ie, link, msie, network, performance, script, style
Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.
CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.
Implementation takes only minutes as it requires that you:
- create a (free) account,
- retrieve your existing DNS values from your current provider,
- determine direct vs. CDN “cloud” routing for each subdomain,
- change your DNS records to point to the CloudFlare DNS servers
Some additional advantages I’ve seen since implementing:
- Site remains available in limited capability to users during server outages or upgrades.
- Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
- IPv6 dual-stack support
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: acceleration, akamai, application, browser, cache, cdn, client, cloudflare, content, delivery, fast, http, ipv4, ipv6, network, performance, security, server, speed, web, webapp
There are a couple of steps required to force a browser to save/download content instead of displaying it in the browser window.
X-Download-Options: noopen
X-Content-Type-Options:nosniff
Content-Disposition: attachment; filename=example.txt
Content-Type: text/plain
NOTE: MSIE also supports a poorly documented proprietary META tag…
<meta name="DownloadOptions" content="noopen|nosave" />
REFERENCES:
To prevent XSS/CSRF exploits in MSIE8 and newer, it’s often best to close as many attack vectors as possible. An easy one to implement is an HTTP Header to prevent MSIE from “sniffing” the content to change it when incorrect.
Example: we would not want an HTML page intentionally served with ‘text/plain’ to be rendered as HTML.
X-Content-Type-Options: nosniff
Content-Type: text/plain
This could be added programatically to pages in your application, via a servlet or servlet filter or added to the httpd.conf file.
Apache2 example: httpd.conf
<IfModule headers_module>
Header set X-Content-Type-Options nosniff
</IfModule>
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: change, conf, content, csrf, header, http, httpd, mime, msie, nosniff, security, sniff, type, xss
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: browser, custom, error, friendly, http, ie, messages, msie, registry, server, windows
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: browser, cif, comment, conditional, css, detect, hack, html, ie, if, javascript, link, msie, script, sniff, standards, style
Browsers tend to evolve quickly, but they often do not offer the same capabilities cross-platform. As a result of this, there are many standard tests available to the developers of browser software to test for compliance with modern web standards.
Before making use of a specific capability in your web application, it’s often best to determine which browsers can support it.
Categories: MSIE bugs, Safari bugs, WebStandards, Work Tags: acid, acid2, acid3, browser, capabilities, client, css, html, html5, javascript, standards, testing, w3c, web
MSIE5 added support for CSS expressions or “Dynamic Properties”, however MSIE8 ‘deprecated’ their use and prevents their use in Standards Mode.
While powerful because this allowed you to script your CSS dynamically, there were two primary problems.
- Performance – the expression could fire literally hundreds or thousands of times on a page when scrolled or resized.
- Security – this represented an attack vector and exposed XSS
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: browser, client, css, dynamic, expression, expressions, javascript, msie, performance, properties, setExpression
Even when you’ve used conditional includes, there are often cases where MSIE just will not cooperate with your CSS manipulations. In those cases, it can often be attributed to the hasLayout property of the element. To correct this quirk, setting zoom:1; will often “convince” MSIE to work in the way you expect it to (like other browsers!)
<style type="text/css">
.someclass {
/* your CSS definitions */
zoom:1;
}
</style>
REFERENCES:
Categories: MSIE bugs, WebStandards, Work Tags: box, css, hasLayout, html, layout, model, msie, property, zoom