Fix for https:// and ftp:// URLs

[mattclements]

Added Fix to allow https:// and ftp:// URL's (Issue #5)

I suppose we need to look at the possibility of passing protocol lists to the validation rules so you can enable ftp:// etc when required.

[victorjonsson]

Thank you for your contribution Matt!

There's one thing I find a bit odd though. I see that you have changed the way of comparing variables, always using === or !==. Is this something proposed by JSLint? Please point me to some articles discussing why this necessary. I dont see why typeof (var) === 'undefined' is preffered over == 'undefined', since there's no risk of problems with type casting that case.

[mattclements]

No problem - Glad I can help, I am going to put together some more bits for the plugin over the next few days such as UK Date formats, UK Postcodes etc.

Details about the === vs == : http://stackoverflow.com/questions/359494/javascript-vs-does-it-matter-which-equal-operator-i-use

Basically as no type conversion will be taking place this makes the comparison slightly faster. Also if the type is ever incorrect this will instantly fail, rather than bloating while trying to convert the variable.

[victorjonsson]

Oh, that sounds great! If you can find out how to easily translate different date formats it would be greatly appriciated. At the moment the plugin only supports two different date formats. The code only decides whether to use either yyyy-mm-dd or dd/mm/yyyy, it has no greater understanding of what the formatted string actually means.

Regarding the "equal" operator. In my opinion the type conversion never becomes an issue as long as the programmer doesn't becmoe sloppy. If there's a risk of type conversion messing up the outcome of an if-statement the ===/!== should be used. In the case of typeof(var) == 'something' I know that typeof() returns a string which means that no type conversion will take place when Im comparing it with another string, or am I wrong?

I know that Mr. Crockfords words is considered "law" by many but I'm having problems accepting that I should use === when Im using a native javascript function (becaus its native I can feel sure about what it will return).

[mattclements]

Brilliant,

I agree with you entirely with regards to the "equal" operator. I guess due to working on lots of projects that are then handed over to a "sloppy" programmer/web guy/everything else once I have finished a clients project I always use === to make sure if they make changes to the inputs by a function etc then this will continue to work correctly.

Basically it is no worse using === than ==, and it can be faster/safer to use if somebody hacks around with the code.

[victorjonsson]

+1