diff --git a/modules/angular2/docs/core/01_templates.md b/modules/angular2/docs/core/01_templates.md
index 3f732c0d0f..deded9cd48 100644
--- a/modules/angular2/docs/core/01_templates.md
+++ b/modules/angular2/docs/core/01_templates.md
@@ -4,16 +4,16 @@ Templates are markup which is added to HTML to declarativly describe how the app
 projected to DOM as well as which DOM events should invoke which methods on the controller. Templates contain
 syntax which is core to Angular and allows for data-binding, event-binding, template-instantiation.
 
-The design of template syntax has these properties:
+The design of the template syntax has these properties:
 
-* All data-binding expressions are easily identifiable. (i.e. there is never an ambiguity wether the value should be
+* All data-binding expressions are easily identifiable. (i.e. there is never an ambiguity whether the value should be
   interpreted as string literal or as an expression.)
 * All events and their statements are easily identifiable.
 * All places of DOM instantiation are easily identifiable.
-* All places of variable declaration is esily identifiable.
+* All places of variable declaration is easily identifiable.
 
-The above properties guarantee that the templates are easy to parse by tools (such as IDEs) and reason about by people.
-At no point is it necessary to understand which directives are active and what are their symantics in order to reason
+The above properties guarantee that the templates are easily to be parsed by tools (such as IDEs) and reasoned about by people.
+At no point is it necessary to understand which directives are active and what are their semantics in order to reason
 about the template runtime characteristics.
 
 
@@ -21,7 +21,7 @@ about the template runtime characteristics.
 ## Summary
 
 Below is a summary of the kinds of syntaxes which Angular templating supports. The syntaxes are explained in more
-detail in following sections.
+detail in the following sections.
 
 <table>
   <thead>
@@ -222,7 +222,7 @@ Example:
 
 ## Property Binding
 
-Binding application model data to the UI, is the most common kinds of bindings in an Angular application. The bindings
+Binding application model data to the UI is the most common kind of bindings in an Angular application. The bindings
 are always in the form of `property-name` which is assigned an `expression`. The generic form is:
 
 <table>
@@ -253,21 +253,21 @@ its value.
 
 Key points:
 * The binding is to the element property not the element attribute.
-* To prevent custom element from accidentaly reading the literal `expression` on the title element, the attribute name
-  is escaped. In our case the `title` is escaped to `[title]` through the addition of squre brackets `[]`.
+* To prevent custom element from accidentally reading the literal `expression` on the title element, the attribute name
+  is escaped. In our case the `title` is escaped to `[title]` through the addition of square brackets `[]`.
 * A binding value (in this case `user.firstName` will always be an expression, never a string literal)
 
 NOTE: Unlike Angular v1, Angular v2 binds to properties of elements rather than attributes of elements. This is
-done to better support custom elements, and allow binding for values other than strings.
+done to better support custom elements, and to allow binding for values other than strings.
 
-NOTE: Some editors/server side pre-processors may have trouble generating `[]` arround the attribute name. For this
+NOTE: Some editors/server side pre-processors may have trouble generating `[]` around the attribute name. For this
 reason Angular also supports a canonical version which is prefixed using `bind-`.
 
 
 
 ### String Interpolation
 
-Property bindings are the only data bindings which angular supports, but for convenience Angular supports interpolation
+Property bindings are the only data bindings which Angular supports, but for convenience Angular supports an interpolation
 syntax which is just a short hand for the data binding syntax.
 
 ```
@@ -280,7 +280,7 @@ is a short hand for:
 <span [text|0]=" 'Hello ' + stringify(name) + '!' ">_</span>
 ```
 
-The above says to bind `'Hello ' + stringify(name) + '!'` expression to the zero-th child of the `span`'s `text`
+The above says to bind the `'Hello ' + stringify(name) + '!'` expression to the zero-th child of the `span`'s `text`
 property. The index is necessary in case there are more than one text nodes, or if the text node we wish to bind to
 is not the first one.
 
@@ -302,7 +302,7 @@ keeping `null` and `undefined` as empty strings.
 
 
 
-## Local Varibles
+## Local Variables
 
 
 
@@ -311,7 +311,7 @@ keeping `null` and `undefined` as empty strings.
 
 Data binding allows updating the DOM's properties, but it does not allow for changing of the DOM structure. To change
 DOM structure we need the ability to define child templates, and then instantiate these templates into Views. The
-Views can than be inserted and removed as needed to change the DOM structure.
+Views than can be inserted and removed as needed to change the DOM structure.
 
 <table>
   <tr>
@@ -347,7 +347,7 @@ Where:
   templates which have more than one root DOM node.
 * `instantiating-directive` is required for templates. The instantiating directive is responsible for deciding when
   and in which order should child views be inserted into this location. An instantiating directive usually has one or
-  more bindings and can be represnted as either `instantiating-directive-bindings` or
+  more bindings and can be represented as either `instantiating-directive-bindings` or
   `instantiating-directive-microsyntax` on `template` element or attribute. See template microsyntax for more details.
 
 
@@ -355,33 +355,33 @@ Example of conditionally included template:
 
 ```
 Hello {{user}}!
-<div template="if: isAdimnistrator">
+<div template="if: isAdministrator">
   ...administrator menu here...
 </div>
 ```
 
-In the above example the `if` instantiator determins if the child view (an instance of the child template) should be
-inserted into ther root view. The `if` makes this decision based on if the `isAdimnistrator` binding is true.
+In the above example the `if` instantiator determines whether the child view (an instance of the child template) should be
+inserted into the root view. The `if` makes this decision based on if the `isAdministrator` binding is true.
 
-The above example is in the shart form, for better clarity let's rewrite it in the canonical form, which is functionaly
+The above example is in the short form, for better clarity let's rewrite it in the canonical form, which is functionally
 identical.
 
 ```
 Hello {{user}}!
-<template [if]="isAdimnistrator">
+<template [if]="isAdministrator">
   <div>
     ...administrator menu here...
   </div>
 </template>
 ```
 
-NOTE: Only Instantiator directives can be placed on the template element. (Decorators, and Components are not allowed.)
+NOTE: Only Instantiator directives can be placed on the template element. (Decorators and Components are not allowed.)
 
 
 ### Template Microsyntax
 
 Often times it is necessary to encode a lot of different bindings into a template to control how the instantiation
-of the templates occurs. One such example is foreach.
+of the templates occurs. One such example is `foreach`.
 
 ```
 <form #foo=form>
@@ -408,7 +408,7 @@ syntax is preferable.
 </ul>
 ```
 
-Notice how each key value pair is translated to `key=value;` statement in the `template` attribute. This makes the
+Notice how each key value pair is translated to a `key=value;` statement in the `template` attribute. This makes the
 repeat syntax a much shorter, but we can do better. Turns out that most punctuation is optional in the short version
 which allows us to further shorten the text.
 
@@ -427,8 +427,8 @@ microsyntax for `foreach`.
 </ul>
 ```
 
-The format is intentionally defined freely, so that developers of directives can build expressive microsyntax for
-their directives. Following describes a more formal definition.
+The format is intentionally defined freely, so that developers of directives can build an expressive microsyntax for
+their directives. The following code describes a more formal definition.
 
 ```
 expression: ...                     // as defined in Expressions section
@@ -441,14 +441,14 @@ microsyntax: ([[key|keyExpression|varExport][;|,]?)*
 ```
 
 Where
-* `expression` is an angular expression as defined in section: Expressions
+* `expression` is an Angular expression as defined in section: Expressions
 * `local` is a local identifier for local variables.
 * `internal` is an internal variable which the directive exports for binding.
 * `key` is an attribute name usually only used to trigger a specific directive.
-* `keyExpression` is an property name to which the epression will be bound to.
-* `varExport` allows exporting of directive internal state as variables for further binding. If no `internal` name
-  is specified than the exporting is to an implicit variable.
-* `microsyntax` allows you to build simple microsyntax which can still clearly identify which expressions bind to
+* `keyExpression` is an property name to which the expression will be bound to.
+* `varExport` allows exporting of a directive internal state as variable for further binding. If no `internal` name
+  is specified, the exporting is to an implicit variable.
+* `microsyntax` allows you to build a simple microsyntax which can still clearly identify which expressions bind to
   which properties as well as which variables are exported for binding.
 
 
@@ -527,7 +527,7 @@ have different semantics.
 
 ### Expressions
 
-Expressions can be used to bind to a properties only. Expressions represent how data should be projected to the View.
+Expressions can be used to bind to properties only. Expressions represent how data should be projected to the View.
 Expressions should not have any side effects and should be idempotent. Examples of where expressions can be used in
 Angular are:
 ```
@@ -537,19 +537,19 @@ Angular are:
 <div template="if: expression">...</div>
 ```
 
-Expressions are simplified version of expression in the language in which you are writing your application. (i.e. 
+Expressions are a simplified version of an expression in the language in which you are writing your application. (i.e. 
 expressions follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike expressions in the 
-language, binding expressions behave differently in following ways:
+language, binding expressions behave differently in the following ways:
 
 * *Must be defined*: Unlike Angular v1, Angular v2 will throw an error on dereferencing fields which are not defined. 
-  For example: `user.name` will throw an error if `user` is defined but it does not have `name` property. If the `name` 
-  property is not known, it must be declared and set to some value such as empty string, `null` (or `undefined` in JS). 
+  For example: `user.name` will throw an error if `user` is defined but it does not have a `name` property. If the `name` 
+  property is not known, it must be declared and set to some value such as an empty string, `null` (or `undefined` in JS). 
   This is done to allow early detection of errors in the templates. 
-* *Safe dereference*: Expressions `user.name` where `user` is null will throw `NullPointerException` in the language. 
+* *Safe dereference*: Expression `user.name` where `user` is `null` will throw a `NullPointerException` in the language. 
   In contrast Angular will silently ignore `null` on `user`. This is done because Views often have to wait for the data
   to arrive from the backend and many fields will be `null` until the data arrives. Safe dereference is so common in the
-  Views, that we have made it the default.
-* *Single expression*: An expression must be a single statemnet. (i.e. no `;`)
+  Views that we have made it the default.
+* *Single expression*: An expression must be a single statement. (i.e. no `;`)
 * *No assignments*: Binding expressions can not contain assignments.
 * *No keywords*: Binding expressions can not contain keywords such as: `var`, `if`, and so on.
 * *Formatters*: Angular expressions can be piped through formatters to further transform the binding value. 
@@ -567,8 +567,8 @@ class Greeter {
 * `name` : Will result in the value of the `name` property on the `Greeter` class.
 * `name.length`: Will result in either the length of the `name` string or `undefined` (`null` in Dart) if `name` 
   property is `null` or `undefined`. Example of: safe dereference.
-* `foo`: Will thrown on error because `foo` is not declared on the `Greeter` class. Example of: Must be defined
-* `name=1`: Not allowed because fo assignment.
+* `foo`: Will throw an error because `foo` is not declared on the `Greeter` class. Example of: Must be defined
+* `name=1`: Not allowed because of assignment.
 * `name; name.length`: Not allowed because of multiple statements.
 
 
@@ -584,10 +584,10 @@ Examples of where statements can be used in Angular are:
 
 Statements are similar to statements in the language in which you are writing your application. (i.e.
 statements follow JS syntax and semantics in JS and Dart syntax and semantics in Dart). Unlike statements in the
-language, binding expressions behave differently in following ways:
+language, binding expressions behave differently in the following ways:
 
 * *Unsafe dereference*: Expressions `user.verify()` where `user` is `null` will throw `NullPointerException` in the
-  language as well as in statements. (In contrast to Safe dereference in Angular expressions.) While angular protects
+  language as well as in statements. (In contrast to Safe dereference in Angular expressions.) While Angular protects
   you from null dereferencing in expressions due to lazy loading of data, no such protection is required for statements,
   and doing so would make it harder to detect typos in statements.
 * *Multiple statements OK*: Statements can be composed from more than one statement. (i.e. no `doA(); doB()`)
diff --git a/modules/angular2/docs/core/02_directives.md b/modules/angular2/docs/core/02_directives.md
index 666a9f8189..e70bf793c5 100644
--- a/modules/angular2/docs/core/02_directives.md
+++ b/modules/angular2/docs/core/02_directives.md
@@ -1,16 +1,16 @@
 # Directives
 
-Directives are classes which get instantiated as a respones to a particular DOM strcture. By controlling the DOM stracture, what directives are imported, and their selectors, the developer can use the [composition pattern](http://en.wikipedia.org/wiki/Object_composition) to get desirable application behavior.
+Directives are classes which get instantiated as a response to a particular DOM structure. By controlling the DOM structure, what directives are imported, and their selectors, the developer can use the [composition pattern](http://en.wikipedia.org/wiki/Object_composition) to get a desirable application behavior.
 
-Directives are the cornerstone af Angular application. We use Directives to break complex problems into smaller more reusable components. Directives, allow the devolper turn HTML into a DSL and than controll the application assembly process.
+Directives are the cornerstone of an Angular application. We use Directives to break complex problems into smaller more reusable components. Directives allow the developer to turn HTML into a DSL and then control the application assembly process.
 
-Angular applications do not have a main method. Instead they have a root Component. Dependency Injection than assembles the directives into a working Angular application.
+Angular applications do not have a main method. Instead they have a root Component. Dependency Injection then assembles the directives into a working Angular application.
 
-There are three different kinds of directives (described in mored detailed in later sections). 
+There are three different kinds of directives (described in more detail in later sections). 
 
 1. *Decorators*: can be placed on any DOM element and can be combined with other directives.
-2. *Components*: Components have encapsulated view and can configure injectors.
-3. *Viewport*: Is responsible for adding or removing child views in parent view. (i.e. foreach, if)
+2. *Components*: Components have an encapsulated view and can configure injectors.
+3. *Viewport*: is responsible for adding or removing child views in a parent view. (i.e. foreach, if)
 
 
 
@@ -27,10 +27,10 @@ Angular supports these CSS selector constructs:
 * AND operation: `name[attribute]`
 * OR operation: `name,.class`
 
-Angular does not support these (and any CSS selector which crosses element boundries):
+Angular does not support these (and any CSS selector which crosses element boundaries):
 * Descendant: `body div`
 * Direct descendant: `body > div` 
-* Adjascent: `div + table`
+* Adjacent: `div + table`
 * Sibling: `div ~ table`
 * Wildcard: `*`
 * ID: `#id`
@@ -62,7 +62,7 @@ The simplest kind of directive is a decorator. Directives are usefull for encaps
 * Decorators do not introduce new evaluation context.
 * Decorators are registered througt the `@Decorator` meta-data annotation.
 
-Here is a triavial example of tooltip decorator. The directive will log a tooltip into the console on every time mouse enters a region:
+Here is a trivial example of a tooltip decorator. The directive will log a tooltip into the console on every time mouse enters a region:
 
 ```
 @Decorator({
@@ -88,9 +88,9 @@ Example of usage:
 
 ```<span tooltip="Tooltip text goes here.">Some text here.</span>```
 
-The developer of an applacation can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has taught the browser a new reusable and declarative bahavior.
+The developer of an application can now freely use the `tooltip` attribute wherever the behavior is needed. The code above has taught the browser a new reusable and declarative behavior.
 
-Notice that databinding will work with this decorator with no further effort as show below.
+Notice that data binding will work with this decorator with no further effort as shown below.
 
 ```<span tooltip="Greetings {{user}}!">Some text here.</span>```
 
@@ -101,7 +101,7 @@ Notice that databinding will work with this decorator with no further effort as
 Component is a directive which uses shadow DOM to create encapsulate visual behavior. Components are tipically used to create UI widgets or to break up the application into smaller components.
 
 * Only one component can be present per DOM element.
-* Components CSS selectors usualy trigger on element names. (Best practice)
+* Component's CSS selectors usually trigger on element names. (Best practice)
 * Component has its own shadow view which is attached to the element as a Shadow DOM.
 * Shadow view context is the component instance. (i.e. template expressions are evaluated against the component instance.)
 
@@ -138,7 +138,7 @@ class Pane {                      | Component controller class
 
 `pane.html`:
 ```
-<div class="outter">
+<div class="outer">
   <h1>{{title}}</h1>
   <div class="inner" [hidden]="!visible">
     <content></content>
@@ -148,7 +148,7 @@ class Pane {                      | Component controller class
 
 `pane.css`:
 ```
-.outter, .inner { border: 1px solid blue;}
+.outer, .inner { border: 1px solid blue;}
 .h1 {background-color: blue;}
 ```
 
@@ -165,11 +165,11 @@ Example of usage:
 
 ## Viewport
 
-Viewport is a directive which can controll instantiation of child views which are then inserted into the DOM. (Examples are `if` and `foreach`.) 
+Viewport is a directive which can control instantiation of child views which are then inserted into the DOM. (Examples are `if` and `foreach`.) 
 
 * Viewports can only be placed on `<template>` elements (or the short hand version which uses `<element template>` attribute.)
 * Only one viewport can be present per DOM template element.
-* The viewport is is created over the `template` element. This is known as the `ViewContainer`. 
+* The viewport is created over the `template` element. This is known as the `ViewContainer`. 
 * Viewport can insert child views into the `ViewContainer`. The child views show up as siblings of the `Viewport` in the DOM.
 
 >> TODO(misko): Relationship with Injection
@@ -209,20 +209,20 @@ export class If {
 
 ## Dependency Injection
 
-Dependency Injection (DI) is a key aspect of directives. DI allows directives to be assembled into different [compositional](http://en.wikipedia.org/wiki/Object_composition) hieranchies. Angular encourages [composition over inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance) in the application design (but inheritance based approaches are still supported).
+Dependency Injection (DI) is a key aspect of directives. DI allows directives to be assembled into different [compositional](http://en.wikipedia.org/wiki/Object_composition) hierarchies. Angular encourages [composition over inheritance](http://en.wikipedia.org/wiki/Composition_over_inheritance) in the application design (but inheritance based approaches are still supported).
 
-When Angular directives are instantiated, the directive can ask for other related directives to be injected into it. By assembing the directives in different order and subtypes the application behavior can be controlled. A good mental model is that DOM structure controlles the directive instantiation graph.
+When Angular directives are instantiated, the directive can ask for other related directives to be injected into it. By assembling the directives in different order and subtypes the application behavior can be controlled. A good mental model is that the DOM structure controls the directive instantiation graph.
 
-Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by following the DOM hieranchy and if not found using the application level injector.
+Directive instantiation is triggered by the directive CSS selector matching the DOM structure. The directive in its constructor can ask for other directives or application services. When asking for directives the dependency is locating by following the DOM hierarchy and if not found using the application level injector.
 
 To better understand the kinds of injections which are supported in Angular we have broken them down into use case examples.
 
 
 ### Injecting Services
 
-Service injection is the most straight forward kind of injection which Angular supports. It involves a component configureing the `componentServices` and than letting the directive ask for the configured service. 
+Service injection is the most straight forward kind of injection which Angular supports. It involves a component configuring the `componentServices` and then letting the directive ask for the configured service. 
 
-This example ilustrates how to inject `MyService` into `House` directive.
+This example illustrates how to inject `MyService` into `House` directive.
 
 
 ```
@@ -252,7 +252,7 @@ class House {                        |
 
 Assume the following DOM structure for `my_app.html`:
 ```
-<div house>     | The house attribute triggers the creation of House directive. 
+<div house>     | The house attribute triggers the creation of the House directive. 
 </div>          | This is equivalent to:
                 |   new House(injector.get(MyService));
 ```
@@ -264,13 +264,13 @@ Injecting other directives into directives follows a similar mechanism as inject
 
 There are five kinds of visibilities:
 
-* (no annotation): Inject a directives only if it is on the curent element. 
+* (no annotation): Inject a directives only if it is on the current element. 
 * `@ancestor`: Inject a directive if it is at any element above the current element.
 * `@parent`: Inject a directive which is direct parent of the current element.
 * `@child`: Inject a list of direct children which match a given type. (Used with `Query`)
 * `@descendant`: Inject a list of any children which match a given type. (Used with `Query`)
 
-NOTE: if the injection constraint can not be satisfied by the current visibility constraint, than it is forward to normal injector which may provide a default value for the directive or it may throw an error.
+NOTE: if the injection constraint can not be satisfied by the current visibility constraint, then it is forward to the normal injector which may provide a default value for the directive or it may throw an error.
 
 Here is an example of the kinds of injections which can be achieved:
 
@@ -330,7 +330,7 @@ Assume the following DOM structure for `my_app.html`:
 
 ### Shadow DOM effects on Dependency Injection
 
-Shadow DOM provides encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundries.
+Shadow DOM provides an encapsulation for components, so as a general rule it does not allow directive injections to cross the shadow DOM boundaries.
 
 
 
diff --git a/modules/angular2/docs/core/03_formatters.md b/modules/angular2/docs/core/03_formatters.md
index 6081749c92..8d68764579 100644
--- a/modules/angular2/docs/core/03_formatters.md
+++ b/modules/angular2/docs/core/03_formatters.md
@@ -1,7 +1,7 @@
 # Formatters
 
 Formatters can be appended on the end of the expressions to translated the value to a different format. Typically used
-to controll the stringification of numbers, dates, and other data, but can also be used for ordering, maping, and
+to control the stringification of numbers, dates, and other data, but can also be used for ordering, mapping, and 
 reducing arrays. Formatters can be chained.
 
 NOTE: Formatters are known as filters in Angular v1.
diff --git a/modules/angular2/docs/core/10_view.md b/modules/angular2/docs/core/10_view.md
index 855d40fa0e..efa264f09a 100644
--- a/modules/angular2/docs/core/10_view.md
+++ b/modules/angular2/docs/core/10_view.md
@@ -51,7 +51,7 @@ And assume following HTML Template:
 </div>
 ```
 
-The above template is compiled by the Compiler to create a ProtoView. The ProtoView is than used to 
+The above template is compiled by the Compiler to create a ProtoView. The ProtoView is then used to 
 create an instance of the View. The instantiation process involves cloning the above template and 
 locating all of the elements which contain bindings and finally instantiating the Directives 
 associated with the template. (See compilation for more details.)
@@ -81,7 +81,7 @@ Note:
 * View knows which expressions need to be watched.
 * View knows what needs to be updated if the watched expression changes.
 * All DOM elements are owned by single instance of the view.
-* The structure of the DOM can not change during runtime. To Allow structural changes to DOM we need 
+* The structure of the DOM can not change during runtime. To allow structural changes to the DOM we need 
   to understand Composed View.
 
 
@@ -107,27 +107,27 @@ During the compilation process the Compiler breaks the HTML template into these
 and
 
 ```
-<ul>                    | protoViewA(SomeContexnt)
-  <template></template> | protoViewA(SomeContexnt): new ProtoViewPort(protoViewB)
-</ul>                   | protoViewA(SomeContexnt)
+<ul>                    | protoViewA(someContext)
+  <template></template> | protoViewA(someContext): new ProtoViewPort(protoViewB)
+</ul>                   | protoViewA(someContext)
 ```
 
 
-The next step is to compose these two ProtoViews into actual view which is rendered to the user.
+The next step is to compose these two ProtoViews into an actual view which is rendered to the user.
 
 *Step 1:* Instantiate `viewA`
 
 ```
-<ul>                    | viewA(SomeContexnt)
-  <template></template> | viewA(SomeContexnt): new Foreach(new ViewPort(protoViewB))
-</ul>                   | viewA(SomeContexnt)
+<ul>                    | viewA(someContext)
+  <template></template> | viewA(someContext): new Foreach(new ViewPort(protoViewB))
+</ul>                   | viewA(someContext)
 ```
 
 *Step2:* Instantiate `Foreach` directive which will receive the `ViewContainer`. (The ViewContainer 
 has a reference to `protoViewA`).
 
 
-*Step3:* As the `Foreach` unrolls it asks the `ViewContainer` to instantiate `protoViewB` and insert 
+*Step3:* As the `Foreach` directive unrolls it asks the `ViewContainer` to instantiate `protoViewB` and insert 
 it after the `ViewPort` anchor. This is repeated for each `person` in `people`. Notice that 
 
 ```
@@ -135,7 +135,7 @@ it after the `ViewPort` anchor. This is repeated for each `person` in `people`.
   <template></template> | viewA(someContext): new Foreach(new ViewPort(protoViewB))
   <li>{{person}}</li>   | viewB0(locals0(someContext))
   <li>{{person}}</li>   | viewB1(locals0(someContext))
-</ul>                   | viewA(lomeContexnt)
+</ul>                   | viewA(someContext)
 ```
 
 *Step4:* All of the bindings in the child Views are updated. Notice that in the case of `Foreach` 
@@ -152,8 +152,8 @@ delegate any unknown references to the parent context.
 ```
 
 Each View can have zero or more ViewPorts. By inserting and removing child Views to and from the 
-ViewContainers, the application can mutate the DOM structure to any desirable state. A View contain 
-individual nodes or complex DOM structure. The insertion points for the child Views, known as 
+ViewContainers, the application can mutate the DOM structure to any desirable state. A View may contain 
+individual nodes or a complex DOM structure. The insertion points for the child Views, known as 
 ViewContainers, contain a DOM element which acts as an anchor. The anchor is either a `template` or 
 a `script` element depending on your browser. It is used to identify where the child Views will be 
 inserted.
@@ -161,7 +161,7 @@ inserted.
 ## Component Views
 
 A View can also contain Components. Components contain Shadow DOM for encapsulating their internal 
-rendering state. Unlike ViewPorts which can contain zero or more Views, the Component always contain 
+rendering state. Unlike ViewPorts which can contain zero or more Views, the Component always contains 
 exactly one Shadow View.
 
 ```
@@ -177,10 +177,10 @@ exactly one Shadow View.
 
 ## Evaluation Context
 
-Each View as a context for evaluating its expressions. There are two kinds of contexts:
+Each View acts as a context for evaluating its expressions. There are two kinds of contexts:
 
 1. A component controller instance and
-2. a Locals context for introducing Local variables into the View.
+2. a `Locals` context for introducing local variables into the View.
 
 Let's assume following component:
 
@@ -194,7 +194,7 @@ class Greeter {
 }
 ```
 
-And assume following HTML Template:
+And assume the following HTML Template:
 
 ```
 <div>                             | viewA(greeter)
@@ -205,7 +205,7 @@ And assume following HTML Template:
 </div>                            | viewA(greeter)
 ```
 
-The above UI is built using a single View, and hence single context `greeter`. It can be expressed 
+The above UI is built using a single View, and hence a single context `greeter`. It can be expressed 
 in this pseudo-code.
 
 ```
@@ -215,7 +215,7 @@ var greeter = new Greeter();
 The View contains two bindings:
 
 1. `greeting`: This is bound to the `greeting` property on the `Greeter` instance.
-2. `name.value`: This poses a problem. There is no `name` property on `Greeter` instance. To solve 
+2. `name.value`: This poses a problem. There is no `name` property on the `Greeter` instance. To solve 
 this we wrap the `Greeter` instance in the `Local` instance like so:
 ```
 var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
@@ -224,7 +224,7 @@ var greeter = new Locals(new Greeter(), {name: ref_to_input_element })
 
 By wrapping the `Greeter` instance into the `Locals` we allow the view to introduce variables which 
 are in addition to the `Greeter` instance. During the resolution of the expressions we first check 
-the locals, and then `Greeter` instance.
+the locals, and then the `Greeter` instance.