Author Archives: Matthias Reuter

HTML5 brought many good features, but it also brought back user-agent sniffing.

User-Agent sniffing is the nemesis of good modern web development, and that’s for a good reason. As a person who uses Opera since version 4 as his main browser for surfing (not for development though) I have suffered through many bad scripts which try to exclude me just on the grounds I am using neither Internet Explorer nor Firefox. Or neither Internet Explorer nor Netscape. I have ranted against scripts that told me my browser was outdated and I should switch do a newer, faster and better browser like IE, even though I used the latest ubuntu version of Opera.

User-Agent sniffing dates back to when browser vendors extended their products with cool new features like the marquee element (I hope you noticed the sarcasm) and web developers had to find out, if they could use these. Often that led to two completely seperate versions of the web site and the user being redirected to one of them depending on his user-agent (or not being redirected at all, if the user-agent did neither match the sniffing for IE or Netscape).

Many web developers fought the fight to replace user-agent sniffing by feature testing. Instead of looking at the user-agent and thereby deriving from a name what the browser is capable of, it is definitevly better to look at what the browser says it is capable of. This is an example for a very common use case:

function addListener (element, type, callback) {
    if (element.addEventListener) {
        element.addEventListener(type, callback, false);
    }
    else if (element.attachEvent) {
        element.attachEvent("on" + type, callback);
    }
}

This script handles the different event models which exist in browsers, the standardized model of the W3C (addEventListener) and the proprietary model of Microsoft (attachEvent).

What is the advantage of feature detection? It does not break future versions of browsers. If a future version (like IE9) supports a certain feature (like the W3C event model, which by the way it does), we don’t have to change our script, it continues to work. User-agent sniffing on the other hand, has to be adapted whenever a new browser or a new version of an existing browser is released, since that browser might support a feature a former version did not.

Now most will agree that feature detection is superior to user-agent sniffing. However, feature detection is not a replacement for user-agent sniffing, in fact, sometimes we have to use user-agent sniffing. We rarely need it, but the use of HTML5 increases the need of user-agent sniffing.

User-agent sniffing is necessary when a browser does support a certain feature but has a bug in it. I once had the case that a former version of Safari had a bug in its implementation of

document.querySelectorAll

, where in certain circumstances the returned NodeList contained

null

. While there is the theoretical possibility to feature-test bugs, this fails when the browser crashes when using a feature in a special way, as it happened to a friend of mine on a beta version of Safari. There is no way to feature detect a browser crash.

Bugs in implementations of features are quite rare, but what if a browser supports a feature, but not in a way you like? This is very common for features of HTML5.

HTML5 has several new type for the

input

element. A very convenient type is

date

. It is quite easy to do a feature test, if the browser supports that type:

function hasTypeSearch() {
    var input = document.createElement("input");
    input.setAttribute("type", "date");
    
    return input.type === "date";
}

This test works because browsers which do not support

date

will fall back to the type

text

. But this does not help at all. Opera’s support for the

date

type looks like this:

While Chrome’s support looks like that:

Both browsers support the

date

type, but while Opera has a full featured date picker, Chrome only has two buttons to increase or decrease the date.

Now if you want to enhance browsers which do not have a datepicker natively – maybe by adding a jQuery UI datepicker – there is no way to feature detect that.

Similar, the

search

type is supported by many browsers. On Safari for Mac it looks like that:

On all other browsers I tried it looks like an ordinary text field. This is due to the specification, which says:

On platforms where search fields are distinguished from regular text fields, the Search state might result in an appearance consistent with the platform’s search fields rather than appearing like a regular text field.

Offering that little

x

to reset the search is a feature one would like in all browsers on all platforms, but again, there is no way to feature detect this.

HTML5 makes us need user-agent sniffing.

What can we do about this? Nothing. We could only keep user-agent sniffing to a minimum. That is, first try to feature detect. Only if that succeeds, do a user-agent sniffing.

function hasDatepicker () {
    var input = document.createElement("input");
    input.setAttribute("type", "date");
    
    if (input.type !== "date") {
        // does not support type date
        return false;
    }
    
    // currently only Opera supports date as we want it
    return navigator.userAgent.indexOf("Opera") !== -1;
}

This leaves us in the sorry state that we have to monitor browser development closely. Whenever a browser changes, we might need to adapt our sniffing. HTML5 brought many good features, but it also brought back user-agent sniffing.

If you had the chance to build a website from scratch. A website that is going to be launched in the late summer of this year. And an old version of that website already exists, which will be maintained but not developed further…

How would you build the frontend?

I have given that some thought in the last time. And here are the three most important conclusions I came to:

1. Use HTML5 excessively
2. Style with CSS3
3. Drop IE support

While the first two might seem obvious, the third sounds like madness. How can I seriously even think of excluding like fifty percent of the users (less in Europe, more in the US)? It’s only logical (and I admit I’ll cut that down a little later on). But let me explain the first two points first.

Use HTML5 excessively

HTML5 offeres a broad variety of new structural elements. And the basis for a good website is semantic markup. footer, header, nav, article, time and so on are HTML5’s answers to a ton of divs that we used in old (and current) websites. But HTML5 is more, using the audio and video elements you can easily embed multimedia to your site. OK, video is still a mess if you don’t want to double encode your content, but that might change in the near future, since Google announced to drop support for H.264 last week.

There are a lot more techniques that help building a light-weight application, part of which are associated with HTML5, but are not part of the specification. Offline-applications, drag and drop, the File-API, local storage, geolocation and more.

Style with CSS3

This seems obvious as well. It means, if you want to have rounded corners, don’t use a bunch of images, use border-radius. If you want semi-transparent background, don’t use a png image, but use rgba colors. If you want animations, use transitions instead of bloaty Javascript code. If you want a shadowed box, don’t use images, use box-shadow. You want to use your corporate identity font for headings? Do not use images, use @font-face. And most of all, if you want your application to fit in a mobile browser, use media-queries.

So using CSS3 drastically can decrease the number of files you need and therefore the improve the performance of your application.

There is one drawback, though. CSS3 support is not complete in most browsers. Opera for example does not have gradients. Firefox does not support transitions. That’s partly because these specifications still are working drafts. But let’s be honest. Does it really hurt, if Opera users have a single background color instead of a gradient? If Firefox users don’t have an animated hover effect? Form follows function.

Drop IE support

If you have a look at what browsers support today, you can see that many, many features I would use already are supported in Opera, Chrome, Firefox and Safari. So if we dropped IE support, we could be using them today.

And if you then have a look at what will be, you can see that in mid/late 2011, when IE9 is released, most of the features are supported by all browsers. So I correct myself: Drop IE<9 support. As I said it. If you build an application that will be launched in the second half of 2011, use HTML5, CSS3 and don't care about IEs. But how long will it take users to adapt to IE9? My guess is, pretty quickly. Those using IE8 will switch quickly. Those using IE7 or - godforbid - IE6 will probably stick to it forever and eventually die out. You can still send them to the old version of your application (which is a prerequisite of IEs. If you don't have an old version you most likely cannot afford to drop IE support).

In the meantime build the next jQuery

What should be done in the meantime? How should we spend the time until IE9 is released? Build a new javascript library. Large part of current libraries are concerned with selecting dom elements, providing animations, offering functionality that already found its way into Ecmascript 5 (like JSON, Array extras and so on). Throw them away. Use querySelector/querySelectorAll instead of sizzle. Use CSS3 for animations. Ecmascript 5 is widely supported in many browsers today. Again, IE8 is far behind the others, but IE9 is the paragon for ES5 support. It even finally implements the Event model of W3C.

So spend the time building a library that adds the few missing functions. That works around the remaining browser bugs and inconsitencies. Build a library for the future.

A note at the end

When you use semantic markup, media queries and progressive enhancement for the advanced features (and do everything right), then you have a mobile web app almost for free. You don’t have to build an extra app for iPhone, Android… Now wouldn’t that be nice? Think of all the time (and money) you could save. So go ahead and start.

Last night I met Jennifer again and apart from being hot it turns out she’s pretty perceptive as well. When she read my previous article, she objected to some aspects of my address book.

Her point is, it’s a waste of memory to store empty properties of an address. That’s true, so I sat down and threw away those unneccessary bits:

var addresses = [{
    nickName  : "Mom",
    phoneNumber : "555-69-666"
},
{
    firstName : "Mathilda",
    lastName  : "Wozzle",
    phoneNumber : "555-343-37847"
},
{
    firstName : "Jennifer",
    phoneNumber : "555-467-4475"
}];

Unfortunately, we now encounter some problems: First checking for an empty string no longer is sufficent, and second, since undefined is not a string, concatenating is a problem:

var address = {
    nickName : "Mom",
    phoneNumber : "555-69-666"
};
address.firstName; // undefined
address.firstName != ""; // true
address.firstName + "" + address.lastName; // "undefinedundefined"

So what can we do to handle undefined as well? Several commenters liked the second implementation best, so let’s fix that first:

var getDisplayName = function (address) {
    if (address.firstName != "" && address.firstName != undefined && address.lastName != "" && address.lastName != undefined) {

I stopped here because this definitely is not a good solution. Readability suffers greatly if we double check all properties this way. The solution to this – again – lies in the automatic type conversion of Javascript. Both empty strings and undefined convert to false.

var getDisplayName = function (address) {
    if (address.firstName && address.lastName) {
        return address.firstName + " " + address.lastName;
    }
    else if (address.firstName) {
        return address.firstName;
    }
    else if (address.lastName) {
        return address.lastName;
    }
    else {
        return address.nickName;
    }
};

Java developers might feel a bit uncomfortable with this, but hey, this is Javascript.

Now let’s try to fix the one-liner:

return (address.firstName + (address.firstName && address.lastName ? " " : "") + address.lastName) || address.nickName;

We cannot just concatenate the different parts, because they might be undefined. We could instead provide default values like this

return ((address.firstName || "") + (address.firstName && address.lastName ? " " : "") + (address.lastName || "")) || address.nickName;

but that is unreadable again. If we give up our goal of a one-liner, we could do this:

var getDisplayName = function (address) {
    var first = address.firstName || "";
    var last  = address.lastName || "";
    var nick  = address.nickName || "";
    
    return (first + (first && last ? " " : "") + last) || nick;
};

By renaming some variables, we can get a version even shorter than the original (103 bytes vs. 106 bytes, minified):

var getDisplayName = function (address) {
    var f = address.firstName || "", l = address.lastName || "", n = address.nickName || "";
    return (f + (f && l ? " " : "") + l) || n;
};

And still, there is a one-liner (shortened to improve legibility):

return first && last ? first + " " + last : first || last || nick;

Jennifer had a second point. What’s the meaning of a nickname? It’s not the name I have for someone if he has no name. Instead it’s the name I have for someone even though he has a name. Therefore, the nickname should have precedence over first and last name. I assign the task of implementing to you.

This is about three women and a javascript address book. The first woman is my mom. Though she does have a first name and a last name, I have been referring to her as mom for my whole life, so her entry in my address book should be labelled “Mom”.

The second woman is my probation officer, a Mrs. Mathilda Wozzle. I do not have a nickname for her, and obviously I don’t want anybody who happens to look over my shoulder to see what she is. Her address book entry should therefore be labelled innocently “Mathilda Wozzle”.

The third woman is Jennifer. I met her in a pub last week, and I do not remember her last name. I’m not even sure she gave me a last name, can’t remember much of that night. The note she handed me contained only two bits, Jennifer and a phone number. I definitely want her in my address book and until further contact she has to go as “Jennifer”.

I’m afraid it’s getting technical now.

My address book now looks like this:

var addresses = [{
    firstName : "",
    lastName  : "",
    nickName  : "Mom",
    phoneNumber : "555-69-666"
},
{
    firstName : "Mathilda",
    lastName  : "Wozzle",
    nickName  : "",
    phoneNumber : "555-343-37847"
},
{
    firstName : "Jennifer",
    lastName  : "",
    nickName  : "",
    phoneNumber : "555-467-4475"
}];

Now I need to derive a display name from those three properties. This is done according to the following rule set:

1. If both first name and last name are given, the display name consists of those two, separated by a space.
2. If only one of first name and last name is given, the display name is that property.
3. If none of first name and last name is given, the display name is the nick name.

A straight-forward implementation would be this:

var getDisplayName = function (address) {
    if (address.firstName != "" && address.lastName != "") {
        return address.firstName + " " + address.lastName;
    }
    else if (address.firstName != "" || address.lastName != "") {
        if (address.firstName != "") {
            return address.firstName;
        }
        else {
            return address.lastName;
        }
    }
    else {
        return address.nickName;
    }
};

This is ugly to read and does a lot more checks than neccessary, so here’s a better version:

var getDisplayName = function (address) {
    if (address.firstName != "" && address.lastName != "") {
        return address.firstName + " " + address.lastName;
    }
    else if (address.firstName != "") {
        return address.firstName;
    }
    else if (address.lastName != "") {
        return address.lastName;
    }
    else {
        return address.nickName;
    }
};

Now we might get smart:

var getDisplayName = function (address) {
    var displayName = "";
    
    if (address.firstName != "") {
        displayName = address.firstName;
    }
    if (address.lastName != "") {
        if (address.firstName != "") {
            displayName += " ";
        }
        displayName += address.lastName;
    }
    if (address.firstName == "" && address.lastName == "") {
        displayName = address.nickName;
    }
    
    return displayName;
};

Some like the ternary operator:

var getDisplayName = function (address) {
    var displayName = (address.firstName != "") ? address.firstName : "";
    displayName = (address.firstName != "") 
            ? (address.lastName != "") ? displayName + " " + address.lastName : displayName 
            : (address.lastName != "") ? address.lastName : address.nickName;
    return displayName;
};

So, which one do you like most? Actually, I hate them all. There’s a reason I do and that’s they all aren’t written the javascript-way. There is a javascripty solution and best of all, it’s a one-liner. So let’s have a closer look at some features of javascript that help a lot:

Automatic type conversion

If firstName is a string, then the two statements

if (firstName != "")

and

if (firstName)

are equivalent. That’s because an empty string is converted to false, while any other string is converted to true.

The operators && and ||

Those two operators do not return a boolean. Behind the scenes, they convert the operands to boolean values but return the last operand that got evaluated. They return the operands, not their boolean value.

A flaw in concept

This has nothing to do with javascript features, but helps improving the code as well. Have a look at the first line of the function body of the last example (which is a real life example from a project I worked on):

var displayName = (address.firstName != "") ? address.firstName : "";

What does this do? It checks if firstName is not an empty string and if so assigns firstName to displayName. Otherwise it assigns an empty string. Which is the value of firstName. So that line can be written as

var displayName = address.firstName;

Furthermore, we’re dealing with strings, so we just can concatenate them without having to worry about null or undefined. An easy way to implement the first two items of the rule set is that:

var displayName = address.firstName + separator + address.firstName;

for some separator, which is determined by that line:

var separator = address.firstName && address.lastName ? " " : "";

Put together:

var separator = address.firstName && address.lastName ? " " : "";
var displayName = address.firstName + separator + address.firstName;
return displayName;
// for example:
// Mathilda Wozzle: "Mathilda" + " " + "Wozzle"
// Jennifer: "Jennifer" + "" + ""
// Mom: "" + "" + ""

Now we have to handle that mom-case. But that’s easy. If displayName still is an empty string, take nickName:

var separator = address.firstName && address.lastName ? " " : "";
var displayName = address.firstName + separator + address.firstName;
return displayName || address.nickName;

What does

displayName || nickName

do? It converts displayName to a boolean value. So if displayName is not an empty string, it is converted to true. Since no further operands need to be evaluated, displayName is returned. If displayName is an empty string, it is converted to false and address.nickName is evaluated (and since it is the last operand) returned.

I promised a one-liner. Here it is:

return (address.firstName + (address.firstName && address.lastName ? " " : "") + address.lastName) || address.nickName;

If you have a form with a file upload field, in some browsers you cannot extract the path to the chosen file. This is meant as a security measure, because it might reveal some information about the user, e.g. the username.

In earlier versions of Opera, if you tried to read the upload field’s value, only the file name was given:

var uploadField = document.getElementById("upload");
var path = uploadField.value; // was "foo.jpg"

In the recent version, Opera for some reason reveals a full path, but it’s a fake path:

var uploadFIeld = document.getElementById("upload");
var path = uploadField.value; // now "C:\fake_path\foo.jpg"

I agree that the path should be hidden to anyone else but the user, but I don’t agree that giving a fake path is a good solution. Anyway, I found a way to circumvent the path protection. It’s easy. You just have to clone the upload field, change the type and voilà, you can read the whole path:

var uploadField = document.getElementById("upload");

// now create a clone
var clone = uploadField.cloneNode(true);

// since the clone still is an upload field, the value is protected
// so change the type
clone.type = "text";

// now we can extract the value
var path = clone.value; // now "C:\Documents and Settings\Matthias\foo.jpg"

I tried the other way round to see if I could create a text field with a given value and then change it to an upload field. If that was possible, you could upload any file without the user noticing, as long as you can guess the path. Fortunately, this is not possible. Whenever changing the type to “file”, the value is lost.

var uploadField = document.createElement("input");
uploadField.value = "C:\\Documents and Settings\\Matthias\\bar.jpg";
uploadField.type = "file";
document.body.appendChild(uploadField); // value is lost

Extracting the path as mentioned above does not work in Firefox. Firefox only reveals the file name, not the path. Internet Explorer does not protect the path at all, so you can get it just by accessing the upload field’s value. I did not try Chrome or Safari, feel free to leave your findings in a comment.

Escaping is the art of transforming a text into a transport format from which it can be extracted again without any modification.

That’s something every developer does – to a certain level. For example take the sentence

Matthias says: "I love Javascript".

Now put this sentence in a Java source code:

String s = "Matthias says: "I love Javascript".";

If you don’t complain about this, your compiler will. In Java (any many other programming languages) the quotation mark " has a special meaning, it defines a string. So if you have a string containing the quotation mark, you need to escape it:

String s = "Matthias says: \"I love Javascript\".";

If you print out s, the original text is shown:

System.out.print(s); // Matthias says: "I love Javascript".

That’s something we learnt in one of the first programming lessons, and even absolute beginners learn this quickly. Unfortunately, the knowledge of escaping ends here for many. Escaping is not just putting a backslash before a quotation mark. Let’s take a step back and think about why we need escaping.

We have a sequence of characters (like the above sentence) that needs to be put in some environment (like as a String in Java source code). We have to be able to extract that exact sequence of characters from that environment again (like by printing it to a console or a file).

The sequence might as well be some user input that has to be stored in a MySQL database and later be read from that database. Or maybe it’s some user input coming from a database that has to be embedded within an HTML page.

So that’s the first step for escaping:

1. The goal is to embed a sequence of characters in some environment so that we later are able to extract the exact sequence.

Since the environments differ, so does the need of escaping. In Java, we have to escape quotation marks, since they have a special meaning. We also have to escape some control characters like line breaks and tabs. In HTML it’s different. We have to escape angle brackets (< and >), characters not contained in the page’s charset (like € in an ISO-8859-1 page) and some more. That leads to step two:

2. We need to know which characters have a special meaning or are forbidden in the environment.

The environments do not only differ in the characters that need escaping, but in the way to do escaping as well. The escape sequence in Java is a backslash followed by the original character. In HTML the escape sequence has the form

&foo;

, where foo is a textual representation of the escaped character (> becomes &gt; greater than). So step three is:

3. Know how to escape.

When I wrote my own blog software, I stored the entries in a SQL database. Of course I escaped the entries using

mysql_real_escape_string

, but I went a step further. Since the entry was to be embedded in an HTML page, I also escaped it via

htmlspecialchars

before putting it into the database. That wasn’t a good idea. I later added an interface to retrieve entries as JSON and so had to unescape them again. Actually, what I did in the first place was a violation of step one: “…so that we later are able to extract the exact sequence”. I could not extract the same sequence, since I modified it twice.

The right way was: Escape the entry for a MySQL query when storing it. When embedding the stored entry in an HTML page, read it from the database (resulting in the exact sequence) and then escape it for HTML. When embedding it in JSON, read it from the database (resulting again in the exact sequence) and then escape it for JSON. So we have step four:

4. Don’t double escape.

A last step concerns the reinvention of the wheel. Where possible, do not manually escape. There’s no way around it when embedding a quotation mark within a string in Java source code, but for embedding in HTML, SQL, JSON and so on use methods provided by the language you use. In PHP that might be

mysql_real_escape_string

,

json_encode

and

htmlspecialchars

. These methods often cover edge cases of which the normal mind never thinks of.

5. Use methods provided by the language where possible.

Examples

Let’s look at some examples:

URLs

If you search twitter, the url is http://twitter.com/search?q=searchterm. Now if you search for a hashtag (that is a term starting with a #), you need to escape the # because it has a special meaning in an url (it denotes a fragment identifier). Escaping a character in an url is done by replacing it by a %xy sequence, where xy is the hex presentation of that character. So a # must be replaced by %23 and thus the search url becomes e.g. http://twitter.com/search?q=%23songsincode

Formally, we did this:

1. The goal is to embed #searchterm within a URL (precisely in the query part).
2. Slash and hash and % and ? have a special meaning in a URL, and most non-ascii characters are forbidden.
3. The escape character in a URL is the percent sign, followed by the hex representation of the character to escape.
4. Does not apply here.
5. In Javascript for example you escape a query part by

encodeURIComponent()

.

HTML

If you want to explain how to make an HTML paragraph, you might give an example:

<p>This is an HTML paragraph.</p>

If your explanation is within an HTML page, you need to escape it, because <p> obviously has a special meaning in HTML. You need to write it that way:

<p>This is an HTML paragraph.</p>

< and > are special characters in HTML as well as " and &, so they need escaping. (By the way, how would I have to escape the above code to have it displayed as it is in HTML?)

Again, formally:

1. The goal is to embed <p>This is a paragraph.</p> within HTML.
2. Characters with a special meaning in HTML are < > & and ".
3. These are escaped by &lt; &gt; &amp; and &quot;
5. In JSP for example it is done by <c:out value=”${foo}” /> which by default escapes the value.

SQL

Of course you need to escape text if you want to embed it in an SQL query, as seen in this famous cartoon from xkcd.com:

Case study: A complete failure

There is a real life example of how a website completely failed because its developers were unaware of the rules of escaping. The website is not publicly available, so I cannot give you a link. All of the mistakes mentioned here have been fixed in the meantime.

The website represents a virtual pin board where you can pin messages to. It looks like that:

The notes are generated using Javascript, the data (position, message text and background color) are stored in JSON (Javascript Object Notation). So the message text has to be escaped to embed in JSON. In an early version, this was not done. So having a quotation mark in your message text broke the JSON and as a consequence could not be altered, since generating of the notes failed.

I had to wait until this bug was fixed before I could try to break the board again.

The JSON then was part of an HTML page, embedded in a script element. Fortunately, the special characters of HTML need not to be escaped within a script element, with one exception. The HTML parser looks for a closing script tag anywhere. It especially does not parse the Javascript to see if </script> is part of a Javascript string. So having a </script> in your message text broke the HTML again with the consequence of completly breaking the application.

A message could be altered inline, that means the div containing the text was replaced by a textarea. On blur, the text was saved in the background using an HttpRequest and the textarea was again replaced by a div containing the altered text.

The text was not meant to allow HTML, but the altered text was inserted to the page using innerHTML, and thus, HTML could be injected. Until page reload. Since HTML was not allowed, the special characters of HTML needed escaping. Unfortunately a very common mistake was made. Instead of escaping the special characters, they were stripped. This generally is wrong, and was additionally done wrong. Any sequence of characters surrounded by angle brackets was removed. So the mathematical truth (redundant though) of 3<5 and 5>3 was replaced by 33.

The problem was the developers did not think about how user input could break the application. As long as the user behaves like a model citizen, all went right. But users don’t, trust me.

Further reading

A nice overview of how to escape for different environments can be found at http://codecodex.com/wiki/Escape_sequences_and_escape_characters.

Javascript is a weird language. Great but weird. Take functions for example. You cannot only pass any type of arguments, you can also pass any number of arguments. This may be quite disturbing, especially for Java developers. Recently I had a discussion with a Java developer who complained about missing code assistance in Javascript, by which he meant no hint about the type of an argument.

This is of course due to the dynamically typed nature of Javascript. While in Java you denote the expected type of a parameter, and it’s the caller’s duty to pass the correct type (even more, you cannot pass a different type), in Javascript it’s the function’s duty to handle the given parameters and do something reasonable with unexpected types. The question arises: How do you write type safe functions in Javascript? Let me explain this by an example implementation to calculate the greatest common divisor of two numbers.

[The greatest common divisor of two integers is the largest integer that devides these integers without a remainder. The greatest common divisor (or gcd for short) of 24 and 15 is 3, since 24 = 3 · 8 and 15 = 3 · 5.]

This is a basic implementation to calculate the greatest common divisor. It’s based upon the fact that gcd(n,m) = gcd(n-m,m) and gcd(n,n) = n. This is a very easy algorithm, though not the fastest.

function greatestCommonDivisor (n, m) {
  if (n === m) {
    return n;
  }
  if (n < m) {
    return greatestCommonDivisor(n, m - n);
  }
  return greatestCommonDivisor(n - m, n);
}

So now, how do you make this function type safe? It's a function for integers, how do you handle, for example, strings?

Leave it to the user

The easiest answer is, you don't. Just leave the responsibility to the user. If he's to dumb to provide integers let him handle the consequences.

[By the way, what happens when calling this function with strings? Interestingly, you might get the right result,

greatestCommonDivisor("24", "15")

greatestCommonDivisor("9", "24")

results in an infinite loop.]

The consequences could be (a) the right result (unlikely but possible), (b) an error thrown (ugly, but the user asked for it), (c) unexpected results like

NaN

,

null

or

undefined

(still ugly) or (d) an infinite loop. This last possibility should make us discard the easy answer. We might accept a (we surly would), b and c; d however is out of question.

Type check arguments

So the second answer is to type check the arguments. We want numbers, so we reject anything else. How do we reject unexpected types? Throw an error, at least for now.

function greatestCommonDivisor (n, m) {
  if (typeof n !== "number" || typeof m !== "number") {
    throw "Arguments must be numbers";
  )

  if (n === m) {
    return n;
  }
  if (n < m) {
    return greatestCommonDivisor(n, m - n);
  }
  return greatestCommonDivisor(n - m, n);
}

Convert arguments

While this is a valid solution, there are better. If n and m come from user input, it's likely they might be strings. Strings can be easily converted to numbers, so instead of rejecting them, we should convert them. This can be done by calling Number as a functíon:

function greatestCommonDivisor (n, m) {
  n = Number(n);
  m = Number(m);

  // We had to change that check, since Number() might return NaN
  if (isNaN(n) || isNaN(m)) {
    throw new TypeError("Arguments must be numbers");
  )

  if (n === m) {
    return n;
  }
  if (n < m) {
    return greatestCommonDivisor(n, m - n);
  }
  return greatestCommonDivisor(n - m, n);
}

Better design

So now you know three concepts of handling unexpected types: Ignore them (might result in infinitive loops, bad), reject them (why give up so easily, bad) and convert them (good). The concept might be good, but the implementation lacks something. I'll show you what.

First (and that is a minor point) the algorithm is bad. If you pass negative numbers or zero, it results in an infinitive loop. This can be solved by taking the absolute value (gcd(n,m) equals gcd(-n,m)).

Second (a minor point as well) the greatest common divisor expects integers but conversion to number results in float values. This can be solved by using

parseInt()

instead of

Number()

.

The third point is a major. The function greatestCommonDivisor is called recursively. That means in every call we type convert and check the arguments, although after the first call we know the arguments have the correct type. There is an elegant solution. First, we convert and check the arguments. Then we define an inner function to do the calculation, which is then called recursively. Since we provide the arguments for the inner function, we don't have to check them again there.

The fourth is a minor point again. When dealing with numbers I'd rather not throw an error but return

NaN

instead. If the user provides arguments which result in

NaN

, we should just tell him so.

Therefore we get the following solution to how to write a type safe function in Javascript:

function greatestCommonDivisor (n, m) {
  // convert n to an integer using parseInt,
  // take the absolute value to prevent infinitive loops
  n = Math.abs(parseInt(n, 10));
  
  // do the same for m
  m = Math.abs(parseInt(m, 10));

  // check if conversion lead to NaN
  if (isNaN(n) || isNaN(m)) {
    return NaN;
  )
  
  // prevent infinitve loop when one argument is zero
  if (n === 0) {
    return m;
  }
  if (m === 0) {
    return n;
  }
  
  // now the inner function
  var gcd = function (n, m) {
    // gcd(n,1) is 1, so prevent recursion to speed things up
    if (n === 1 || m === 1) {
      return 1;
    }
    if (n === m) {
      return n;
    }
    if (n < m) {
      return gcd(n, m - n);
    }
    return gcd(n - m, n);
  };
  
  // invoke the inner function
  return gcd(n, m);
}

There, we're done! Now... wouldn't it be great to make type checking automated? Something like

var typeSafeGcd = makeTypeSafe(greatestCommonDivisor, ["int", "int"]);
typeSafeGcd(21, 15);       // would still return 3
typeSafeGcd(21.5, "abc");  // would fail

Yes, this can be done and I will show you how. There are some drawbacks though. First, how do you automatically convert an unexpected type? It's easy for some types, for example if you expect a number. However, how do you convert a string to an array? Simply wrap the string? Split it somehow? Converting requires some thought and depends on the context. Therefore I think it's not a good idea to do so automatically. That leaves checking types and rejecting unsupported ones.

Second, how do you reject unsupported types? You could either return null, undefined or NaN (depending on the context) or throw an error. Both ways lead to the user having to check the results of function calls. In other words, you push the responsibility to provide correct parameters off to the user. Graceful conversion definitely is the better alternative.

So keep on reading, if you still want to know how to automatically make a function type safe.

This is heavy stuff. I do not expect you to understand it, if you are a beginner in Javascript. I try to explain everything in detail, so maybe you should give it a try. I've written a jQuery plugin that makes type safe functions, so if you don't understand how it's done, you can use it nonetheless...

So what do we want? We want some way to automatedly check the given arguments by just telling which types we expect. We want to reject all other values. We want to reject the incorrect number of arguments. Let's start step by step.

var makeTypeSafe = function (f, parameterList) {
    return f;
};

We define a

makeTypeSafe

-function that accepts two parameters: f, the function to make type safe, and parameterList, the list of expected types of arguments of f. This function does nothing so far except returning the original function.

Now reject the wrong number of arguments:

var makeTypeSafe = function (f, parameterList) {
    var p = parameterList.length;

    // return a function that first checks the arguments before calling the
    // original function
    return function () {
        // check number of arguments
        if (arguments.length !== p) {
            throw "Unexpected number of arguments. Expected " + p + ", got " + arguments.length;
        }
        
        // call f, passing the arguments, preserving the context
        return f.apply(this, arguments);
    };
};

Here we do no longer return the original function but a new function. This new function checks if the number of arguments (

arguments.length

) is different from the expected number of arguments (

parameterList.length

). If so, it throws an error. If not, f is called (and its return value returned).

Need an example of how to use it? Here you are.

var add = function (a, b) {
    return a + b;
};
var addIntegers = makeTypeSafe(add, ["int", "int"]);
addIntegers(21);        // will throw an error
addIntegers(21,15);     // will return 36
addIntegers("abc", 42); // will not throw an error

Why doesn't the last call throw an error? Because until now we only check the number of arguments, not the type. Let's change that.

var types = {
    "int" : function (n) {
        // by comparing n to its floor value we see if it's an integer
        return n === Math.floor(n);
    }
};

Here we define an object with one property, a function called int, which checks if a given argument is an integer. Since there is no integer type in Javascript, we do this by comparing n to its floor value (which is the same for integers).

Extending the

makeTypeSafe

function to check the types of arguments leads to the following code:

var types = {
    "int" : function (n) {
        return n === Math.floor(n);
    }
};

var makeTypeSafe = function (f, parameterList) {
    return function () {
        // check number of arguments
        if (arguments.length !== parameterList.length) {
            throw "Unexpected number of arguments. Expected " + p + ", got " + arguments.length + ".";
        }
        
        // check every argument using the types functions defined above
        for (var i = 0, l = arguments.length; i < l; i++) {
            if (!types[parameterList[i]](arguments[i])) {
                throw "Invalid argument at " + i + ". Argument must be of type " + parameterList[i] + ".";
            }
        }
        
        // call original function
        return f.apply(this, arguments);
    };
};

That's basically the way to automatedly check parameters before executing the original function. Now we can extend the types object to accept more types:

var types = {
    "int" : function (n) {
        // by comparing n to its floor value we see if it's an integer
        return n === Math.floor(n);
    },
    
    "double" : function (n) {
        // NaN is a number as well, so check that n is not NaN
        return typeof n === "number" && !isNaN(n);
    },
    
    "string" : function (n) {
        return typeof n === "string";
    }
};

We could even add more sophisticated types like natural numbers or arrays of integers.

types["natural"] : function (n) {
    // replace > by >= if 0 is natural to you
    return types["int"](n) && n > 0;
};

types["int[]"] : function (n) {
    // accept only arrays
    if (!(n instanceof Array)) {
        return false;
    }
    // check if every element is an integer
    for (var i = 0, l = n.length; i < l; i++) {
        if (!types["int"](n[i])) {
            return false;
        }
    }
    return true;
};

"Make a jQuery plugin!" my fellow co-author Christian cried. Well, personally I don't fancy jQuery, but if you must make a function type safe, you might be using jQuery anyway, so why not? I extended the list of build-in types to support int, double (alias float), string, boolean, char, object and arrays of those types as well (used via int[], double[] etc). Furthermore, the list of of expected parameters is checked for unknown types.

I solved the original function to calculate the greatest common divisor

// Define internal gcd function
var gcd = function (a, b) {
    if (a === b) {
        return a;
    }
    if (a === 1 || b === 1) {
        return 1;
    }
    if (a < b) {
        return gcd(a, b - a);
    }
    return gcd(a - b, b);
};

// extend the known types to support natural numbers
jQuery.makeTypeSafe.types["natural"] = function (n) {
    return jQuery.makeTypeSafe.types["int"](n) && n > 0;
};

// make gcd type safe
var greatestCommonDivisor = jQuery.makeTypeSafe(gcd, ["natural", "natural"]);

// call type safe gcd function
greatestCommonDivisor(21, 15);     // returns 3
greatestCommonDivisor("21", "15"); // throws an error

Any questions, any remarks? Feel free to comment!

This is the fourth (and last) part of a series “All about types” in Javascript.

1. The basics – types and general rules of conversion
2. Automatic type conversion
3. Explicit type conversion
4. Type detection

The drawback of having a loosely typed language like Javascript, is that you sometimes have to determine the current type of a variable. This mostly occurs when you create a function that accepts different types of parameters – or is limited to one type.

A while ago, I had a function to open up a dialog to allow the user to send an email. That function accepted a parameter recipient to prefill the to-field. For convenience, I accepted a string and an array as that parameter. If an array was given, I had to convert it to a string. So I needed to check, if I really had been given an array.

Unfortunately, detecting an array is the most complex task of type detection. So I will postpone my solution until later and start with the easier ones.

Basic type detection

Of the five types null, undefined, boolean, number and string, four are very easily detected by using the typeof operator.

typeof "some text"; // "string"
typeof 42;          // "number"
typeof true;        // "boolean"
typeof undefined;   // "undefined"

Detecting an object is similar:

typeof {};    // "object"

Detecting null

Now the problems begin. Some special values require special handling. Take null, for example. The type of null unfortunately is not “null”, it is “object”:

typeof null;   // "object"

To test if a variable is null, you have to compare it to null:

obj === null;  // true, if obj is null, otherwise false

Detecting NaN

The second issue comes with NaN. Its type is “number”, although NaN is Not A Number. Funny, isn’t it? Comparing to NaN does not help either:

NaN === NaN;  // false

I have absolutely no idea, why the language specification states to ECMAScript code, all NaN values are indistinguishable from each other.. Fortunately, there is a solution. There is a global function called isNaN that returns true, if the supplied argument is NaN and false otherwise.

isNaN(NaN);  // true
isNaN(42);   // false

An object is an object is an object

Yes, at least for type detection. It does not matter if your object is an array, a date, an HTML-Element or anything else, typeof always returns “object”.

typeof new Date();  // "object"
typeof [];          // "object"
typeof {};          // "object"

Let me come back to my introductive function. I had to test, if a parameter was an array or a string. Since we don’t have a solution for detecting arrays, my first idea was circumvent the problem

if (typeof recipient !== "string") {
  recipient = recipient.join(",");
}

but that was a bad idea. It lacks robustness, since my function would throw an error, if recipient was e.g. a number. Numbers don’t have a join method.

So I really had to detect the type. As an advanced developper, I knew of two ways: duck-typing and the use of the instanceof operator.

Duck typing

What’s duck typing? “If it walks like a duck and quacks like a duck, I would call it a duck.” (attributed to James Whitcomb Riley). In other words, if the object has a join method, a length and a sort method, call it an array.

In my case, I did this:

function sendMessage (recipient) {
  if (recipient && recipient.join) {
    recipient = recipient.join(",");
  }
}

I only needed to know if the object had a property join, since this was the method I needed to call. That may differ in other situations. Maybe you need to check for sort or splice (both suggesting strongly the object is an array), maybe you only need a length property, in which case your function might also be applicable to strings.

The instanceof operator

Another way to detect the kind of an object is the instanceof operator. It returns true, if the left-hand operand is an instance of the right-hand operand:

[] instanceof Array;        // true
[] instanceof Object;       // yes, true as well
new Date() instanceof Date; // true

Therefore I could have written

function sendMessage (recipient) {
  if (recipient instanceof Array) {
    recipient = recipient.join(",");
  }
}

and mostly, that works fine. Not in my situation. The stated method is called from within an iframe, and that means from a different context. Each window has its own global object, and Array is a constructor property of the global object.

Thus Array in recipient instanceof Array refers to the array constructor of the outer window, while recipient is an instance of the array constructor of the iframe’s window.

Detecting the kind of an object using Object.prototype.toString

That was when I discovered a third way to detect the kind of an object. kangax wrote about using the Object.prototype.toString method.

In summary, if Object.prototype.toString is called on an object, it results in a string like “[object Object]”, where Object refers to the Class of the object (“Class” is what I called “kind”). So, calling Object.prototype.toString on an array, results in “[object Array]”:

Object.prototype.toString.call([]) === "[object Array]";  // true

Please note that you have to use the call method of the toString method. The following does not work:

Object.prototype.toString([]) === "[object Object]";

This approach works with Date, RegExp and other constructors, too.

Detecting functions

One exception to the “an object is an object” mantra are functions. Though functions in javascript are objects as well, the type of a function is “function”. So my solution of duck-typing would better be written as this:

function sendMessage (recipient) {
  if (recipient && typeof recipient.join === "function") {
    recipient = recipient.join(",");
  }
}

Summary

There is no consistent way to detect the type of a variable or the kind of an object. That’s why many multi-purpose-libraries offer a function to wrap type detection.

By the way, in the meantime I found another solution to my problem by circumventing type detection:

function sendMessage (recipient) {
  recipient = recipient ? recipient.toString() : "";
}

If recipient is an array, the toString method returns a string containing the values, seperated by a comma, which is exactly that I needed.

That concludes my series about types in Javascript.