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>
While working on legacy apps, you might occasionally find that a developer has written a function to reload the existing page. I’ve found that in many cases, the optional javascript argument is neglected in this case and thus the ‘cached’ copy of the page is presented, often showing stale or invalid data. The solution here is simple, always specify ‘true’ to force the page to be requested from the server.
<script type="text/javascript">
window.location.reload(true);//NOTE: 'true' forces NON-cached copy to be returned
</script>
REFERENCES:
There are still a measurable number of internet users that browse without the use of JavaScript, use the NoScript plugin, or have disabled it for security purposes. In those cases, as well as for SEO. It’s often a good idea to manipulate the display to better accomodate these users. One of the most common methods is shown below, as we can toggle a CSS class on the HTML tag easily and use CSS “cascade” to hide or show alternate content.
NOTE: this example currently requires PrototypeJS, but can easily be changed to not do so.
<!DOCTYPE html>
<html class="no-js">
<head>
<script type="text/javascript">
var ar = document.getElementsByTagName('html');
var i = ar.length;// should only be one!
while(i--){
Element.removeClassName(ar[i],'no-js');
}
</script>
<style type="text/css>
html .no-js-show { display:none; }
html.no-js .no-js-show { display:block; }
html.no-js .no-js-hide { display:none; }
</style>
</head>
<body>
JavaScript is:
<p class="no-js-hide">enabled</p>
<p class="no-js-show">JavaScript is disabled</p>
</body>
</html>
In the past few years the browser wars have heated up again. Performance and capabilities of some browsers varies greatly. There are several standard tests that are publicly available to benchmark your systems. WebKit (Safari, Chrome & Chromium) and Mozilla (Firefox) based browsers, as well as Opera perform pretty well, MSIE is currently trailing in most cases.
Here are a few common ones…
The optional radix parameter for JavaScript parseInt(string,radix) function is often overlooked and can lead to some difficult problems when not specified. If you are in doubt, and only use/expect decimal numbers, you SHOULD set it to 10.
This might go undetected for a very long time, until someone decides to prefix their value with a zero or zero and an ‘x’ and your code interprets it with something completely different. This behavior can be different based on the browser used due to changes in the EcmaScript definition and support of ‘octal’.
Here’s why…
Radix can be any number from 2-36 to define the number system.
If the radix parameter is omitted, JavaScript assumes the following:
In all cases, the following is observed:
parseInt() returns NaN.REFERENCES:
Occasionally I’ve stumbled upon legacy javascript code that is used to determine javascript support by the visiting users. This often proves comical, because they are many times wasting time making checks for some “VERY OLD” browsers indeed! Here’s a rundown of the versions of javascript as well as their release dates and some common browser versions that implemented them.
The language attribute has long been deprecated and should generally be avoided, it’s original purpose was to support other scripting languages, notably VBScript, or particular JavaScript versions. Modern conventions rely on specifying the MIME type instead via the ‘type’ attribute.
<SCRIPT LANGUAGE="JavaScript"> is now <script type="text/javascript">
<SCRIPT LANGUAGE="JavaScript1.1"> is now <script type="text/javascript1.1">
<SCRIPT LANGUAGE="VBScript"> is now <script type="text/vbscript">
<SCRIPT LANGUAGE="TCL"> is now <script type="text/tcl">
REFERENCES:
Ternary operators, if not abused, can make code easier to follow once you grasp the concept. While normally used for assignment, they can also be used to control program flow. The keys to this are the condition, question mark and colon that identify the condition and results.
var foo = (some_condition) ? then_code : else_code;
REFERENCES:
JavaScript, while mostly object-oriented, does not support function overloading like Java and other common OO languages. To my less knowledgeable audience, overloading is use of the same function name with a different number of arguments or types.
NOTE: there are various ways to implement this sort of functionality using various frameworks, but legacy code can be full of these issues!
In the following code, they share the same name, the second function will always be executed as it is defined last!
<script type="text/javascript">
function doSomething(arg1, arg2){
alert('2 args');
}
function doSomething(arg1){
alert('1 arg');
}
</script>
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:
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.