Release: Validation Plugin 1.11.1

A new version of the jQuery Validation Plugin is available. This is a bugfix release, mostly addressing regressions from the 1.11.0 release. The biggest one was related to the min/max methods, which would compare numbers to strings, in an attempt to make these methods work for date inputs as well. That’s now fixed. More details in the changelog below.

You can also find this plugin on the jQuery Plugins site.

Download this release.

If you use the plugin, please donate or ask your boss to make a donation!

Click here to lend your support to: jQuery Validation Plugin and make a donation at !

Eleven people contributed code to this release. A big thank you to: Bogdan Litescu, Burkhard Reffeling, DexterPark, Erik van Konijnenburg, James Thompson, Nick Schonning, Niklas Nilsson, Paul Cichonski, Robbert Wethmar, g1smd and jcbowman. Also thank you to everyone who reported issues on GitHub or commented on them.

The full changelog:

  • Revert to also converting parameters of range method to numbers. Closes gh-702
  • Replace most usage of PHP with mockjax handlers. Do some demo cleanup as well, update to newer masked-input plugin. Keep captcha demo in PHP. Fixes #662
  • Remove inline code highlighting from milk demo. View source works fine.
  • Fix dynamic-totals demo by trimming whitespace from template content before passing to jQuery constructor
  • Fix min/max validation. Closes gh-666. Fixes #648
  • Fixed ‘messages’ coming up as a rule and causing an exception after being updated through rules(“add”). Closes gh-670, fixes #624
  • Add Korean (ko) localization. Closes gh-671
  • Improved the UK postcode method to filter out more invalid postcodes. Closes #682
  • Update messages_sv.js. Closes #683
  • Change grunt link to the project website. Closes #684
  • Move remote method down the list to run last, after all other methods applied to a field. Fixes #679
  • Update plugin.json description, should include the word ‘validate’
  • Fix typos
  • Fix jQuery loader to use path of itself. Fixes nested demos.
  • Update grunt-contrib-qunit to make use of PhantomJS 1.8, when installed through node module ‘phantomjs’
  • Make valid() return a boolean instead of 0 or 1. Fixes #109 – valid() does not return boolean value
As usual:
  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, eg. new validation methods) to the GitHub issue tracker

Informal reputation systems

Sites like Stackoverflow have formal reputation systems, where every user gets assigned public visible points that increase for actions deemed good, and decrease and some cases considered bad. A score of 10 indicates someone new to the platform, a score of 10.000 someone who’s been around for a long time. Someone new to the platform has an easy time figuring out who’s oldschool and who the other newbies are.

But then there’s endless platforms with informal reputation systems, where there is no explicit number or even rules to increase or decrease your reputation. Yet reputation has a lot of influence on those other platforms as well. Consider web standard processes. If you know anything about them, you’ll recognize the name Hixie. But if you’re new, Hixie is just another name. When you’re new and post to a standards mailing list the first time and no one recognizes your name, you’re much more likely to get ignored.

I wonder if there’s any platform that’s used daily that doesn’t have some form of reputation system. Is there any where reputation really doesn’t matter?

Also, is there a way to convert informal reputation systems like those around web standards into formal ones? Could we build a service that lists people involved in web standards and gives them points for good deeds?

Monday Morning Madness

Random YouTube links, with embeds, yay!

To start, a classic, two iPhone apps screaming at each other:

Up next, goats that sound like humans:

And finally, true facts about the Mantis:

Have a good week!

Freelancing from Germany in the US

This post is for anyone who plans to work for a US company as a freelancer, living in Germany. It assumes that you’re already registered as a freelancer in Germany. As you should be used to, a blog post is no replacement for proper legal advice.

To start with: What about taxes?


In short: You only pay income tax in Germany. You don’t add Umsatzsteuer, like you would for german clients, and you don’t pay any taxes in the US.

The legal base for that is an agreement between Germany and the US from 1989 that intends to avoid double taxing. The german law that puts the agreement into practice is called “Abkommen vom 29. August 1989 zwischen der Bundesrepublik Deutschland und den Vereinigten Staaten von Amerika zur Vermeidung der Doppelbesteuerung und zur Verhinderung der Steuerverkürzung auf dem Gebiet der Steuern vom Einkommen und vom Vermögen und einiger anderer Steuern”. I’ve looked up the page that has the full text of the agreement, the law text and a few change document (patches!) for you. The relevant article of the agreement itself is article 7, “Business Profits”.

As for why you don’t have to charge and pay Umsatzsteuer for US clients: I can’t tell you where exactly that’s regulated. Though there’s a multi-language phone support service, established by a cooperation between  Germany, Netherlands and Belgium. You can find free local phone numbers for each country on their page here. I called there back in 2010 when I was starting my freelance career and called there again today to check if the service is still up and running. You’re likely to talk to someone from the Netherlands first (they speak german, too), but you can leave a number for a german colleague to call you back. I got the information about the Doppelbesteuerungsabkommen (DBA) from there, while my german tax consultant had no clue.

How to get paid

Before you start your first project with a client from the US, you need to agree on how to get paid. There are two important decisions: What currency are you getting paid in? How will you get your money?

For the currency you can agree on a hourly rate (or whatever you do) in USD. In this case, whenever the exchange rate between USD and EUR changes, you end up with more or less money then you originally planned with. This can be both good and bad. You risk getting paid less, with the chance of getting paid more. The alternative is to get paid in EUR. That moves the exchange rate gamble to your client, since there’s no way to completely avoid it. On newer projects I recently tend to ask to get paid in EUR, so far no client had a problem with that.

Either way, next up is figuring out how to actually get your money. While PayPal works for small amounts, their percentage-based fee gets really expensive when invoicing a full month of work. Even at a pretty low rate of 50€ per hour you’d invoice 8000€ for a full month (160 hours) of work, which means several hundred Euros in PayPal fees. In that case, wire transfers through old school banks are a lot cheaper. They will also charge you, usually on both ends, but at least in my experience so far, they only charge a fixed price based on fixed thresholds. For example, anything below 5000€ costs you 20€, anything below 20.000€ costs you 50€, or something like that. In practice, there’s still a lot of variations: On one project, I would invoice in USD and eventually an amount of EUR would land on my business bank account. Inbetween, both banks charged fees and converted from USD to EUR. On another project, I invoiced in EUR and got exactly the amount I invoiced. I’m not sure how exactly that worked and how much my client ended up paying on top, or if they just used a less greedy bank, but it worked pretty well for me.

So much for the money aspects. I have one more recommendations


Timezones are annoying. Timezone math is annoying, calendars are annoying, but there’s no way around them. And the idea to adopt UTC time everywhere isn’t very likely to go anywhere, considering that we can’t even drop stupid daylight saving time (DST). Speaking of which, twice per year there’s this fun period between a few days and a few weeks where Germany is still on DST, while the US isn’t anymore. Or the other way round. In practice, the time difference between you and your client shifts for one hour, for a while. So every single meeting is at a different time.

For that and for keeping your sanity in general, use a calendar application that allows you to specify the timezone of a meeting. Google Calendar does that, it even allows you to display your calendar with multiple timezones at once. In my case that meant setting all the timezones of meetings related to the jQuery project to east coast time (ET). That way, the meeting time would adjust on my calendar for those two annoying DST-shifting periods of the year.

Different timezones also mean different work hours. Unless you’re already sleeping during the day and working at night, you should find clients that are on the east coast and get up pretty early. If you get up late, your work hours might still not fully overlap, but at least you share several hours during each day and you can still have some non-work activities in your evenings. Working with people on the west coast and their nine hour time difference is really exhausting, since your day is done by the time they get up.

Closing Notes

There’s probably a lot more I could write about this topic, for example about visting the US in person. Or about the tools that help work and meet remote colleagues. If there’s something you’d like to know about, tell me! In the comments below, send an email or mention me on Twitter. If you have corrections or suggestions to anything, please also let me know and I’ll update the post accordingly.