Merge remote-tracking branch 'origin/next' into next

Conflicts:
	mithril.js

docs/getting-started.md

@@ -498,7 +498,7 @@ m.mount(document, {controller: todo.controller, view: todo.view});
 </script>
 ```
 
-This example is also available as a [jsFiddle](http://jsfiddle.net/milesmatthias/fbgypzbr/1/).
+This example is also available as a [jsFiddle](http://jsfiddle.net/fbgypzbr/16/).
 There is also [Extended example](http://jsfiddle.net/glebcha/q7tvLxsa/) available on jsfiddle.
 
 ---

docs/installation.md

@@ -60,7 +60,7 @@ Then, to use Mithril, point a script tag to the downloaded file:
 
 ### Bower
 
-[Bower](http://bower.io) is a package manager for [NodeJS](http://nodejs.org/). If you're using NodeJS already or planning on using [Grunt](http://gruntjs.com/) to create a build system, you can use Bower to conveniently keep up-to-date with Mithril versions.
+[Bower](http://bower.io) is a frontend package manager built in [NodeJS](http://nodejs.org/). If you're using NodeJS already or planning on using [Grunt](http://gruntjs.com/) to create a build system, you can use Bower to conveniently keep up-to-date with Mithril versions.
 
 Assuming you have NodeJS installed, you can install Bower by typing this in the command line:
 

docs/mithril.component.md

@@ -219,7 +219,7 @@ Components can be placed anywhere a regular element can. If you have components
 var App = {
 	controller: function() {
 		return {data: [1, 2, 3]}
-	}
+	},
 	view: function(ctrl) {
 		return m(".app", [
 			//pressing the button reverses the list
@@ -513,7 +513,7 @@ There are a few other technical caveats when nesting components:
 
 1.	Nested component views must return either a virtual element or another component. Returning an array, a string, a number, boolean, falsy value, etc will result in an error.
 
-2.	Nested components cannot change `m.redraw.strategy` from the controller constructor (but they can from event handlers). It's recommended that you use the [`ctx.retain`](mithril.md#persising-dom-elements-across-route-changes) flag instead of changing the redraw strategy in controller constructors.
+2.	Nested components cannot change `m.redraw.strategy` from the controller constructor (but they can from event handlers). It's recommended that you use the [`ctx.retain`](mithril.md#persisting-dom-elements-across-route-changes) flag instead of changing the redraw strategy in controller constructors.
 
 3.	The root DOM element in a component's view must not be changed during the lifecycle of the component, otherwise undefined behavior will occur. In other words, don't do this:
 	

docs/mithril.deferred.md

@@ -223,7 +223,7 @@ where:
 
 			The default value (if this parameter is falsy) is the identity function `function(value) {return value}`
 
-			If this function returns undefined, then it passes the `value` argument to the next step in the thennable queue, if any
+			If this function returns undefined, then it passes the `value` argument to the next step in the thenable queue, if any
 
 		-	**any errorCallback(any value)** (optional)
 
@@ -231,7 +231,7 @@ where:
 
 			The default value (if this parameter is falsy) is the identity function `function(value) {return value}`
 
-			If this function returns undefined, then it passes the `value` argument to the next step in the thennable queue, if any
+			If this function returns undefined, then it passes the `value` argument to the next step in the thenable queue, if any
 
 		-	**returns Promise promise**
 

docs/mithril.redraw.md

@@ -126,7 +126,7 @@ Common reasons why one might need to change redraw strategy are:
 
 Note that the redraw strategy is a global setting that affects the entire template trees of all components on the page. In order to prevent redraws in *some parts* of an application, but not others, see [subtree directives](mithril.render.md#subtree-directives)
 
-You can also configure individual elements to always be diffed, instead of recreated from scratch (even across route changes), by using the [`ctx.retain` flag](mithril.md#persising-dom-elements-across-route-changes). If you need to persist DOM state across route changes, it's recommended that you use the `ctx.retain` flag instead of `m.redraw.strategy("diff")`.
+You can also configure individual elements to always be diffed, instead of recreated from scratch (even across route changes), by using the [`ctx.retain` flag](mithril.md#persisting-dom-elements-across-route-changes). If you need to persist DOM state across route changes, it's recommended that you use the `ctx.retain` flag instead of `m.redraw.strategy("diff")`.
 
 ---
 

docs/routing.md

@@ -62,7 +62,7 @@ In this case, since there's only one route, the app redirects to the default rou
 
 The string `johndoe` is bound to the `:userID` parameter, which can be retrieved programmatically in the controller via `m.route.param("userID")`.
 
-The `m.route.mode` property defines which URL portion is used to implement the routing mechanism. Its value can be set to either "search", "hash" or "pathname". The default value is "search".
+The `m.route.mode` property defines which URL portion is used to implement the routing mechanism. It should be set before any calls to `m.route`.  Its value can be set to either "search", "hash" or "pathname". The default value is "search".
 
 -	`search` mode uses the querystring. This allows named anchors (i.e. `<a href="#top">Back to top</a>`, `<a name="top"></a>`) to work on the page, but routing changes causes page refreshes in IE8, due to its lack of support for `history.pushState`.
 

docs/web-services.md

@@ -27,7 +27,7 @@ var users = m.request({method: "GET", url: "/user"});
 
 Note that this getter-setter holds an *undefined* value until the AJAX request completes. Attempting to unwrap its value early will likely result in errors.
 
-The returned getter-setter also implements the [promise](mithril.deferred.md) interface (also known as a *thennable*): this is the mechanism you should always use to queue operations to be performed on the data from the web service.
+The returned getter-setter also implements the [promise](mithril.deferred.md) interface (also known as a *thenable*): this is the mechanism you should always use to queue operations to be performed on the data from the web service.
 
 The simplest use case of this feature is to implement functional value assignment via `m.prop` (i.e. the same thing as above). You can bind a pre-existing getter-setter by passing it in as a parameter to a `.then` method:
 
@@ -49,9 +49,9 @@ var doSomething = function() { /*...*/ }
 m.request({method: "GET", url: "/user"}).then(users).then(doSomething)
 ```
 
-While both basic assignment syntax and thennable syntax can be used to the same effect, typically it's recommended that you use the assignment syntax in the first example whenever possible, as it's easier to read.
+While both basic assignment syntax and thenable syntax can be used to the same effect, typically it's recommended that you use the assignment syntax in the first example whenever possible, as it's easier to read.
 
-The thennable mechanism is intended to be used in three ways:
+The thenable mechanism is intended to be used in three ways:
 
 -	In the model layer: to process web service data in transformative ways (e.g. filtering a list based on a parameter that the web service doesn't support)
 -	In the controller layer: to bind redirection code upon a condition
@@ -98,7 +98,7 @@ var controller = function() {
 
 #### Binding errors
 
-Mithril thennables take two functions as optional parameters: the first parameter is called if the web service request completes successfully. The second parameter is called if it completes with an error.
+Mithril thenables take two functions as optional parameters: the first parameter is called if the web service request completes successfully. The second parameter is called if it completes with an error.
 
 Error binding is meant to be done in the controller layer. Doing it in the model level is also possible, but generally leads to more code in order to connect all the dots.