Ash Searle’s Blog

JavaScript is often used for client-side form validation to save unnecessary round-trips to the server. Unfortunately, lots of client-side validation relies on lenient JavaScript methods such as parseInt, allowing numbers to be input in ways totally unacceptable to your server-side code. Let’s have a look at the problems and some solutions.

Server-side validation

It’s a golden-rule of web-development that you never depend on client-side validation. Users can turn JavaScript off, and hackers can send any data they like at your servers. So, the first thing you have to decide is what data is acceptable to your server. For numbers on the server, are you planning on storing them in a database or performing calculations with them? In either case, what format do the numbers need to be in: integers? decimals? Are you going to manually trim white-space from the number, are you going to allow negative numbers? (more…)

There are plenty of good articles describing how CSS specificity is calculated for normal rule-sets, but the !important modifier is often ignored or overlooked. However, with a little manipulation, !important can simply be treated as one more factor in the specificity calculation.

(more…)

With the new release of Prototype (1.5.0) comes a new website for the Prototype JavaScript Library. The home-page of the new website features a snippet of JavaScript:

cells: function(row) {
  if(row == undefined) return this.tab...
  return $(row).getElementsBySelector(...
}

Let’s get this straight: undefined is not a reserved word. It’s safer and more logical to make the comparison to null:

cells: function(row) {
  if(row == null) return this.tab...
  return $(row).getElementsBySelector(...
}

As null is a reserved word (and it’s quicker to type) I’d expect the Prototype community to favour it.

Note: assuming undefined hasn’t been redefined, the two code fragments are functionally identical. i.e. the equals operator (==) treats null and the primitive value undefined exactly the same.