Clean up language in the types section.

Author: michaeltwofish

doc/en/types/casting.md

@@ -21,7 +21,7 @@ JavaScript is a *weakly typed* language, so it will apply *type coercion*
 > (Base 8). Octal support for these has been **removed** in ECMAScript 5 strict 
 > mode.
 
-In order to avoid the above, use of the [strict equal operator](#types.equality) 
+To avoid the issues above, use of the [strict equal operator](#types.equality) 
 is **highly** recommended. Although this avoids a lot of common pitfalls, there 
 are still many further issues that arise from JavaScript's weak typing system.
 
@@ -38,16 +38,16 @@ Using a built-in type like `Number` as a constructor will create a new `Number`
 object, but leaving out the `new` keyword will make the `Number` function behave
 like a converter.
 
-In addition, having literals or non-object values in there will result in even
-more type coercion.
+In addition, passing literals or non-object values will result in even more
+type coercion.
 
 The best option is to cast to one of the three possible types **explicitly**.
 
 ### Casting to a String
 
     '' + 10 === '10'; // true
 
-By prepending an empty string, a value can easily be casted to a string.
+By prepending an empty string, a value can easily be cast to a string.
 
 ### Casting to a Number
 

doc/en/types/equality.md

@@ -31,7 +31,7 @@ to another number.
 
 The strict equality operator consists of **three** equal signs: `===`.
 
-It works exactly like the normal equality operator, except that strict equality 
+It works like the normal equality operator, except that strict equality 
 operator does **not** perform type coercion between its operands.
 
     ""           ===   "0"           // false
@@ -50,8 +50,8 @@ the operands are of different types.
 
 ### Comparing Objects
 
-While both `==` and `===` are stated as **equality** operators, they behave 
-differently when at least one of their operands happens to be an `Object`.
+While both `==` and `===` are called **equality** operators, they behave 
+differently when at least one of their operands is an `Object`.
 
     {} === {};                   // false
     new String('foo') === 'foo'; // false

doc/en/types/instanceof.md

@@ -13,8 +13,8 @@ nearly as useless as the [typeof operator](#types.typeof).
     new Bar() instanceof Bar; // true
     new Bar() instanceof Foo; // true
 
-    // This just sets Bar.prototype to the function object Foo
-    // But not to an actual instance of Foo
+    // This just sets Bar.prototype to the function object Foo,
+    // but not to an actual instance of Foo
     Bar.prototype = Foo;
     new Bar() instanceof Foo; // false
 

doc/en/types/typeof.md

@@ -2,16 +2,16 @@
 
 The `typeof` operator (together with 
 [`instanceof`](#types.instanceof)) is probably the biggest 
-design flaw of JavaScript, as it is near of being **completely broken**.
+design flaw of JavaScript, as it is almost **completely broken**.
 
-Although `instanceof` still has its limited uses, `typeof` really has only one
+Although `instanceof` still has limited uses, `typeof` really has only one
 practical use case, which does **not** happen to be checking the type of an 
 object. 
 
-> **Note:** While `typeof` can also be called with a function like syntax
-> i.e. `typeof(obj)`, this is not a function call. The two parenthesis will
-> behave like normal and the return value will be used as the operand of the
-> `typeof` operator. There is **no** `typeof` function.
+> **Note:** While `typeof` can also be called with a function like syntax, i.e.
+> `typeof(obj)`, this is not a function call. The parentheses behave as normal
+> and the return value will be used as the operand of the `typeof` operator.
+> There is **no** `typeof` function.
 
 ### The JavaScript Type Table
 
@@ -79,9 +79,8 @@ referencing it would result in a `ReferenceError`. This is the only thing
 In order to check the type of an object, it is highly recommended to use 
 `Object.prototype.toString` because this is the only reliable way of doing so. 
 As shown in the above type table, some return values of `typeof` are not defined 
-in the specification; thus, they can differ across various implementations.
+in the specification; thus, they can differ between implementations.
 
-Unless checking whether a variable is defined, `typeof` should be avoided at
-**all costs**.
+Unless checking whether a variable is defined, `typeof` should be avoided.