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.

The good news: You don’t need any permits to freelance from Germany for US companies. That doesn’t apply anymore when you travel to the US, see below for some details.

To start with: What about taxes?


In short: You only pay income tax in Germany. You don’t add VAT (Umsatzsteuer/USt), 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 the free local phone number 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 a two important descisions: 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. At a rate of 50€ per hour you’d invoice 8000€ for a full month 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€ would cost you 20€, anything below 20.000€ would costs you 50€. The actual numbers depend on the bank. In practice, there’s still a lot of variations: On one project, I invoiced in USD and eventually an amount in EUR landed 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. In general, ask your client to spend some time researching options, both to speed up the transfer and to reduce costs for you and them.

So much for the money aspects. Another interesting one:


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 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 an 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 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.

Traveling to the US

Above I layed out that you can work for a US company from Germany and the tax situation is pretty okay. The picture looks quite different if you consider traveling to the US or even staying there to work on site. From that moment on, the US have a huge interest in your activity. I’ve only ever visited the US to meet friends and attend conferences. If you plan to do that, you’re fine, at least with a german citizenship, since you get a three month VISA automatically. You just need to apply for ETSA (all online, requires a credit card to pay the $15 fee). If you plan to actually work in the US, you have to ask someone else, though this Engineer’s Guide to US Visas is a good starting point. You certainly shouldn’t fly to the US with the intention to work there without knowing anything about this.

Closing Notes

There’s probably a lot more I could write about this topic. If there’s something you’d like to know about, tell me! Send an email or ask me on Twitter. If you have corrections or suggestions to anything, please also let me know and I’ll update the post accordingly.