all typos

docs/cookbook/cb-02-inline-styles tip.md

@@ -19,4 +19,4 @@ var divStyle = {
 React.renderComponent(<div style={divStyle}>Hello World!</div>, mountNode);
 ```
 
-Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase 'W'.
+Style keys are camelCased in order to be consistent with accessing the properties using node.style.___ in DOM. This also explains why WebkitTransition has an uppercase "W".

docs/cookbook/cb-02-inline-styles.md

@@ -24,4 +24,4 @@ React.renderComponent(<div style={divStyle}>Hello World!</div>, mountNode);
 ```
 
 ### Discussion
-Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase 'W'.
+Style keys are camelCased in order to be consistent with accessing the properties using `node.style.___` in DOM. This also explains why `WebkitTransition` has an uppercase "W".

docs/cookbook/cb-05-jsx-root-node-count tip.md

@@ -5,6 +5,6 @@ layout: docs
 permalink: jsx-root-node-count-tip.html
 ---
 
-Currently in `render`, you can only return one node; if you have, say, a list of divs to return, you must wrap your components within, say, one big `div` or `span` (or any other component).
+Currently in `render`, you can only return one node; if you have, say, a list of `div`s to return, you must wrap your components within, say, one big `div` or `span` (or any other component).
 
 Don't forget that JSX compiles into regular js, and returning two functions doesn't really make syntactic sense.

docs/cookbook/cb-08-controlled-input-null-value tip.md

@@ -7,7 +7,7 @@ permalink: controlled-input-null-value-tip.html
 
 With a controlled input component, specifying a `value` prevents the user from changing the input unless you desire so (more info [here](forms.html)).
 
-You might have ran into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited.
+You might have run into a problem where you specified a `value` but the input can still be changed. In this case, you might have accidentally set your `value` to `undefined` or `null`. The snippet below shows this phenomenon; after a second, the text can be edited.
 
 ```js
 /** @jsx React.DOM */

docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting-tip.md

@@ -5,6 +5,6 @@ layout: docs
 permalink: componentWillReceiveProps-not-triggered-after-mounting-tip.html
 ---
 
-`componentWillReceiveProps` isn't triggered after the node is put on scene. This is by design. Checkout [other lifecycle methods](component-specs.html) for the one that suits your needs.
+`componentWillReceiveProps` isn't triggered after the node is put on scene. This is by design. Check out [other lifecycle methods](component-specs.html) for the one that suits your needs.
 
 The reason for that is because `componentWillReceiveProps` often handles the logic of comparing with the old props and act upon changes; not triggering it at mounting, where there are no old props, clearly defines what the method should do.

docs/cookbook/cb-09-componentWillReceiveProps-not-triggered-after-mounting.md

@@ -9,7 +9,7 @@ permalink: componentWillReceiveProps-not-triggered-after-mounting.html
 `componentWillReceiveProps` isn't triggered after the node is put on scene.
 
 ### Solution
-This is by design. Checkout [other lifecycle methods](component-specs.html) for the one that suits your needs.
+This is by design. Check out [other lifecycle methods](component-specs.html) for the one that suits your needs.
 
 ### Discussion
 `componentWillReceiveProps` often handles the logic of comparing with the old props and act upon changes; not triggering it at mounting, where there are no old props, clearly defines what the method should do.