Interesting. You certainly have a flair for design. I have some qualms about your execution though.

First things first, you have two versions of jQuery in your source code:

https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js
https://code.jquery.com/jquery-latest.min.js

Why?

--------

You're using Javascript to alter text colors of your labels when the form input/select element is hovered, but you're using CSS :hover/:focus/:active states to govern background colors of the form fields.

So this means that I can hover one of the select elements, turning its label's text red and its background white; then focus that select element when using it, and then move the mouse cursor away -- the label text remains white, and thus invisible until I focus on something else.

Here is a screenshot of what I am trying to describe:
http://i.imgur.com/uXqRpDE.png

It's a complete waste of Javascript's time to do such trivial things; the timing will be out of sync compared to the heavily optimised CSS transition; and it's just bad coding to have two identical and connected tasks divided such that one is governed by the CSS and the other by jQuery soup. Good luck maintaining that.

Just use CSS to govern the hover states of the labels as well. It should be trivial to set up a transition as you did for the select element.

--------

I've been using the word 'label', but that's not the element you've used, but rather the element you should be using instead of a div and p.

<!-- BAD -->
<div class="duration">
<p>HOLIDAY DURATION</p>
</div>

<!-- GOOD -->
<label class="duration" for="dagen">
<span>HOLIDAY DURATION</span>
</label>

HTML5 has been designed for the provision of semantic meaning, it makes both your code clearer to you later down the line and also makes the site/app more accessible.

--------

I concur with this comment by nailer a lot: https://news.ycombinator.com/reply?id=13461341&goto=item%3Fi...

--------

Also, your Google Analytics tracking code is the first thing in the document. That's not a great idea -- unless you think a page view should be registered even before the page has been, well, viewed. Most choose to stick the tracking code at the end of the body element, or as the last element of the head element, depending on how honestly they want to report on pageviews. Either way, the first thing that should be read by a browser is a charset declaration (utf-8).

--------

Also, in your CSS you have a bit that looks like this:

* {
overflow: none;
}

There is no such thing, that's just a CSS parser error. You can say overflow: hidden, but I'd be cautious about doing that. Generally speaking, if you have understood the CSS box model correctly, you should not need to govern the overflow of all of your elements like that. If yours is an edge case, where it's necessary to have some overflow, you might want to consider setting overflow-x: hidden; overflow-y: auto on html/body elements instead.

--------

Also, no offence, but that jQuery code is looking pretty smelly. I know you're beginners, and you've accomplished something very cool here, you should be proud, but I can't help but feel as though you've picked an approach to web development that you'll want to unlearn if you are serious about web development.

I'm not talking about using React when I say that -- I tend to work without a framework of any kind, unless I'm working with a team. I'm talking about learning about function composition, and learning about functional programming techniques in general. It will cut your code down to size and make it much easier to navigate and debug.

React just so happens to force a functional approach to webdev, and it's very trendy at the moment, so it might be worth your investing time to study it. Otherwise, Marijn Haverbeke's book 'Eloquent JavaScript' (eloquentjavascript.net) is a good thing to start off with. It doesn't cover jQuery, and I think that's why I always recommend it to anyone wishing to develop for the front-end: the last thing you should learn is jQuery, and then by the time you do come to learn it, you won't need it.

--------

Also, 4 web fonts, 9+ weights? Yikes, bye bye 2G/3G users. Still, if you must destroy people on slower connections, at least combine these as was intended:

<!-- BAD -->
<link href="https://fonts.googleapis.com/css?family=Heebo:100,300,400" rel="stylesheet" type="text/css">
<link href="https://fonts.googleapis.com/css?family=Karla" rel="stylesheet" type="text/css">
<link href="https://fonts.googleapis.com/css?family=Quicksand:300,400,700" rel="stylesheet" type="text/css">
<link href="https://fonts.googleapis.com/css?family=Open+Sans:300,600" rel="stylesheet" type="text/css">

<!-- GOOD -->
<link href="https://fonts.googleapis.com/css?family=Heebo:100,300,400|Open+Sans:300,600|Quicksand:300,400,700|Karla" rel="stylesheet">

That will cut your HTTP requests down a bit, and make for less ugly code. Consider bundling each of your CSS source files together, unless you're counting on HTTP/2 to save the day.