JavaScript “use strict”

ECMAScript 5 added Strict Mode to JavaScript. Many of you may have first seen mention of this if you’ve used JSLint. It helps to remember that JavaScript still behaves much like an interpreted vs. compiled language as each browser/parser makes assumptions to execute code faster in different manners.

There are four primary features/goals of strict mode:

  • Throws errors for some common coding issues, that are sometimes obscure but previously didn’t throw an error.
  • Prevents or throws errors for potentially “unsafe” actions (such as gaining access to the global object).
  • Disables functions that are confusing or poorly thought out
  • Potentially code in strict mode could run faster by eliminating mistakes that would make it difficult for JavaScript engines to perform optimizations

Initial support added in FireFox 4 and MSIE10:

WARNING: if you chose to do this at a ‘file’ level, be sure to never concatenate several files together that are not ALL strict.

JS File Example:
"use strict";
function testFunction(){
var testvar = 1;
return testvar;
}

// This causes a syntax error.
testvar = 2;

JS Function Example:
function testFunction(){
"use strict";
// This causes a syntax error.
testvar = 1;
return testvar;
}
testvar = 2;

REFERENCES:

Conditional Comments cause CSS to block

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…. a quick solution to this is to add an empty conditional comment early on, that is, before the main content (CSS) is loaded.. This works for all approaches, such as those where comments surround the <body> or various <link>, <style> or <script> tags.

UPDATE:
Personally, I like to do this immediately after the DOCTYPE and before the <html> tag. Additionally, since IE10 dropped support for this technique, I’ll just target IE 9 and below for any developer that comes after me.


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

REFERENCES:

window.location.reload(true);

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:

No JavaScript support

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>

Browser Performance/Capability Benchmark Testing

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…

JavaScript radix

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.

  • 2 = binary (0-1)
  • 8 = octal (0-7)
  • 10 = decimal (0-9)
  • 16 = hexadecimal (0-F, where… 0-9,A=10,B=11,C=12,D=13,E=14,F=15)

If the radix parameter is omitted, JavaScript assumes the following:

  • If the string begins with “0x” or “0X”, the radix is 16 (hexadecimal)
  • If the string begins with “0”, the radix is 8 (octal). This feature is deprecated
  • If the string begins with any other value, the radix is 10 (decimal)

In all cases, the following is observed:

  • Leading and trailing spaces are allowed,
  • If the first character cannot be converted to a number, parseInt() returns NaN.
  • Only the first number in the string is returned.

REFERENCES:

JavaScript language attribute

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.

  • JavaScript 1.0 (March 1996) = Navigator 2.0 / MSIE 3.0
  • JavaScript 1.1 (August 1996) = Navigator 3.0
  • JavaScript 1.2 (June 1997) = Navigator 4.0-4.05
  • JavaScript 1.3 (October 1998) = Navigator 4.06-4.7x / MSIE 4.0
  • JavaScript 1.4 = Netscape Server
  • JavaScript 1.5 (November 2000) = Navigator 6.0 / Firefox 1.0 / MSIE 5.5 – 8.0 / Safari 3.0-5 / Chrome 1.0-10.x / Opera 6.0
  • JavaScript 1.6 (November 2005) = Firefox 1.5
  • JavaScript 1.7 (October 2006) = Firefox 2.0
  • JavaScript 1.8 (June 2008) = Firefox 3.0 / Opera 11.50
  • JavaScript 1.8.1 = Firefox 3.5
  • JavaScript 1.8.2 (June 2009) = Firefox 3.6
  • JavaScript 1.8.5 (July 2010) = Firefox 4.0 / MSIE 9.0 / Opera 11.60

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:

JavaScript function overloading

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>

MSIE Conditional 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:

CDATA markup of XHTML script and style tags

Ideally all JavaScript and CSS definitions should be external to the content of an HTML page, in some cases it’s simply not practical. If you’ve migrated to XHTML markup of your page, this can often lead to XML validation errors. The use of a CDATA escape can fix most issues, though you may have to cleanup some of the actual code to resolve other issues, particularly with some special characters that are expected to be encoded.

Here are a few examples of CDATA implementation in HTML tags:

<script type="text/javascript">
/* <![CDATA[ */
...
/* ]]> */
</script>

<script type="text/javascript">// <![CDATA[
...
// ]]>
</script>

<style type="text/css">
/* <![CDATA[ */
...
/* ]]> */
</style>