diff --git a/public/docs/_examples/template-syntax/ts/app/app.component.html b/public/docs/_examples/template-syntax/ts/app/app.component.html
index f983716ee4..f0ee22ab80 100644
--- a/public/docs/_examples/template-syntax/ts/app/app.component.html
+++ b/public/docs/_examples/template-syntax/ts/app/app.component.html
@@ -208,9 +208,9 @@ button</button>
 <!-- #enddocregion class-binding-1 -->
 
 <!-- #docregion class-binding-2 -->
-<!-- reset all class names with a string binding  -->
+<!-- reset/override all class names with a binding  -->
 <div class="bad curly special"
-     [class]="'bad curly'">Bad curly</div>
+     [class]="badCurly">Bad curly</div>
 <!-- #enddocregion class-binding-2 -->
 
 <!-- #docregion class-binding-3 -->
@@ -370,24 +370,14 @@ After setClasses(), the classes are "{{classDiv.className}}"
 <p>setStyles returns {{setStyles() | json}}</p>
 <!-- #docregion NgStyle-2 -->
 <div [ngStyle]="setStyles()">
-  This div is italic, normal weight, and x-large
+  This div is italic, normal weight, and extra large (24px)
 </div>
 <!-- #enddocregion NgStyle-2 -->
-<div [ngStyle]="setStyles()" #styleDiv>
-  After setStyles(), the styles are "{{getStyles(styleDiv)}}"
-</div>
-
-
-<h3>Use setStyles2() - camelCase style property names</h3>
-<p>setStyles2 returns {{setStyles2() | json}}</p>
-<!-- #docregion NgStyle-3 -->
-<div [ngStyle]="setStyles2()">
-  This div is italic, normal weight, and x-large
-</div>
-<!-- #enddocregion NgStyle-3 -->
-<div [ngStyle]="setStyles2()" #styleDiv2>
-  After setStyles2(), the styles are "{{getStyles(styleDiv2)}}"
-</div>
+<p>After setStyles(), the DOM confirms that the styles are
+  <span [ngStyle]="setStyles()" #styleDiv>
+    "{{getStyles(styleDiv)}}"
+  </span>.
+</p>
 
 <!-- not used in chapter -->
 
@@ -480,8 +470,8 @@ After setClasses(), the classes are "{{classDiv.className}}"
 <br>
 
 <div class="box">
-  <!-- #docregion NgFor-3 -->
   <!-- Ex: 1 - Hercules Son of Zeus -->
+  <!-- #docregion NgFor-3 -->
   <div *ngFor="#hero of heroes, #i=index">{{i + 1}} - {{hero.fullName}}</div>
   <!-- #enddocregion NgFor-3 -->
 </div>
diff --git a/public/docs/_examples/template-syntax/ts/app/app.component.ts b/public/docs/_examples/template-syntax/ts/app/app.component.ts
index 28da87436e..4f7b0fa16a 100644
--- a/public/docs/_examples/template-syntax/ts/app/app.component.ts
+++ b/public/docs/_examples/template-syntax/ts/app/app.component.ts
@@ -29,6 +29,7 @@ export class AppComponent {
 
   actionName = 'Go for it';
   alert = alerter;
+  badCurly = 'bad curly';
   callFax(value:string)   {this.alert(`Faxing ${value} ...`)}
   callPhone(value:string) {this.alert(`Calling ${value} ...`)}
   canSave =  true;
@@ -130,7 +131,7 @@ export class AppComponent {
       // CSS property names
       'font-style':  this.canSave      ? 'italic' : 'normal',  // italic
       'font-weight': !this.isUnchanged ? 'bold'   : 'normal',  // normal
-      'font-size':   this.isSpecial    ? 'x-large': 'smaller', // larger
+      'font-size':   this.isSpecial    ? '24px'   : '8px',     // 24px
     }
     // #enddocregion setStyles
     // compensate for DevMode (sigh)
@@ -143,25 +144,6 @@ export class AppComponent {
   }
   // #enddocregion setStyles
 
-  // #docregion setStyles2
-  setStyles2() {
-    let styles = {
-      // camelCase style properties work too
-      fontStyle:  this.canSave      ? 'italic' : 'normal',  // italic
-      fontWeight: !this.isUnchanged ? 'bold'   : 'normal',  // normal
-      fontSize:   this.isSpecial    ? 'x-large': 'smaller', // larger
-    }
-    // #enddocregion setStyles2
-    // compensate for DevMode (sigh)
-    if (JSON.stringify(styles) === JSON.stringify(this._priorStyles2)){
-       return this._priorStyles2;
-    }
-    this._priorStyles2 = styles;
-    // #docregion setStyles2
-    return styles;
-  }
-  // #enddocregion setStyles2
-
   toeChoice = '';
   toeChooser(picker:HTMLFieldSetElement){
     let choices = picker.children;
diff --git a/public/docs/ts/latest/guide/template-syntax.jade b/public/docs/ts/latest/guide/template-syntax.jade
index 2b18d3b9e0..558ed1f8e5 100644
--- a/public/docs/ts/latest/guide/template-syntax.jade
+++ b/public/docs/ts/latest/guide/template-syntax.jade
@@ -1,59 +1,43 @@
 include ../../../../_includes/_util-fns
 
 :marked
-  # Template Syntax
-  Our Angular application manages what the user sees and does through the interaction of a Component class instance and its user-facing template.
+  Our Angular application manages what the user sees and does through the interaction of a Component class instance (the *component*) and its user-facing template.
 
-  Many of us are familiar with the Component/Template duality from our experience with Model-View-Controller or Model-View-ViewModel. In Angular,  the Component plays the part of the Controller/ViewModel and the Template represents the view.
+  Many of us are familiar with the component/template duality from our experience with model-view-controller (MVC) or model-view-viewmodel (MVVM). In Angular,  the component plays the part of the controller/viewmodel, and the template represents the view.
 
-  Let’s find out what it takes to write a Template for our view.
+  Let’s find out what it takes to write a template for our view. We’ll cover these basic elements of template syntax:
 
-  We’ll cover these basic elements of Template Syntax
+  * [HTML](#html)
+  * [Interpolation](#interpolation)
+  * [Template expressions](#template-expressions)
+  * [Template statements](#template-statements)
+  * [Binding syntax](#binding-syntax)
+  * [Property binding](#property-binding)
+  * [Attribute, class, and style bindings](#other-bindings)
+  * [Event binding](#event-binding)
+  * [Two-way data binding with `NgModel`](#ngModel)
+  * [Built-in directives](#directives)
+  * [* and &lt;template>](#star-template)
+  * [Local template variables](#local-vars)
+  * [Input and output properties](#inputs-outputs)
+  * [Template expression operators](#expression-operators)
 
-  >[HTML](#html)
-
-  >[Interpolation](#interpolation)
-
-  >[Template expressions](#template-expressions)
-
-  >[Template statements](#template-statements)
-  
-  >[Binding syntax](#binding-syntax)
-
-  >[Property Binding](#property-binding)
-
-  >[Attribute, Class and Style Bindings](#other-bindings)
-
-  >[Event Binding](#event-binding)
-
-  >[Two-way data binding with `NgModel`](#ngModel)
-
-  >[Built-in Directives](#directives)
-
-  >[* and &lt;template>](#star-template)
-
-  >[Local template variables](#local-vars)
-
-  >[Input and Output Properties](#inputs-outputs)
-
-  >[Template Expression Operators](#expression-operators)
-
-  [Live Example](/resources/live-examples/template-syntax/ts/plnkr.html).
+  [Run the live example](/resources/live-examples/template-syntax/ts/plnkr.html)
 
 .l-main-section
 :marked
   ## HTML
-  HTML is the language of the Angular template. Our “[QuickStart](./quickstart.html)” application had a template that was pure HTML
+  HTML is the language of the Angular template. Our [QuickStart](./quickstart.html) application had a template that was pure HTML:
 
 +makeExample('template-syntax/ts/app/app.component.html', 'my-first-app')(format=".")
 :marked
-  Almost all HTML syntax is valid template syntax. The `<script>` element is a notable exception;  it is forbidden in order to eliminate any possibility of JavaScript injection attacks (in practice it is simply ignored).
+  Almost all HTML syntax is valid template syntax. The `<script>` element is a notable exception; it is forbidden, eliminating the risk of JavaScript injection attacks. (In practice, `<script>` is simply ignored.)
 
-  Some legal HTML doesn’t make much sense in a template. The `<html>`, `<body>` and `<base>` elements have no useful role in our repertoire. Pretty much everything else is fair game.
+  Some legal HTML doesn’t make much sense in a template. The `<html>`, `<body>`, and `<base>` elements have no useful role in our repertoire. Pretty much everything else is fair game.
 
-  We can extend the HTML vocabulary of our templates with Components and Directives that appear as new elements and attributes. And we are about to learn how to get and set DOM values dynamically through data binding.
+  We can extend the HTML vocabulary of our templates with components and directives that appear as new elements and attributes. And we are about to learn how to get and set DOM values dynamically through data binding.
 
-  Let’s turn to the first form of data binding - interpolation - to see how much richer Template HTML can be.
+  Let’s turn to the first form of data binding &mdash; interpolation &mdash; to see how much richer template HTML can be.
 
 .l-main-section
 :marked
@@ -73,115 +57,124 @@ include ../../../../_includes/_util-fns
   and then **converts to a string**. The following interpolation illustrates the point by adding the two numbers within braces:
 +makeExample('template-syntax/ts/app/app.component.html', 'sum-1')(format=".")
 :marked
-  The expression can invoke methods of the host component as we do here with `getVal()`:
+  The expression can invoke methods of the host component, as we do here with `getVal()`:
 +makeExample('template-syntax/ts/app/app.component.html', 'sum-2')(format=".")
 :marked
   Angular evaluates all expressions in double curly braces, converts the expression results to strings, and concatenates them with neighboring literal strings. Finally,
   it assigns this composite interpolated result to an **element or directive property**.
 
   We appear to be inserting the result between element tags and assigning to attributes.
-  It's convenient to think so and we rarely suffer for this mistake.
-  But it is not literally true. Interpolation is actually a special syntax that Angular converts into a
-  [Property Binding](#property-binding) as we explain below. The implications and consequences can be profound.
+  It's convenient to think so, and we rarely suffer for this mistake.
+  But it is not literally true. Interpolation is a special syntax that Angular converts into a
+  [property binding](#property-binding), as we'll explain below.
 
-  But before we explore that assertion, we’ll take a closer look at template expressions and statements.
+  But first, let's take a closer look at template expressions and statements.
 
 <a id="template-expressions"></a>
 .l-main-section
 :marked
-  ## Template Expressions
-  A template **expression** produces a value. 
-  Angular executes the expression and assigns it to property of a binding target such
-  as an HTML element, a component, or a directive.
-  
-  We put a template expression within the interpolation braces when we wrote `{{1 + 1}}`.
-  We’ll see template expressions again in [Property Bindings](#property-binding) , 
-  appearing in quotes to the right of the (=) symbol as in `[property]="expression"`.
+  ## Template expressions
+  A template **expression** produces a value.
+  Angular executes the expression and assigns it to a property of a binding target;
+  the target might be an HTML element, a component, or a directive.
 
-  We write template expressions in a language that looks like JavaScript. 
-  Many JavaScript expressions are legal template expressions but not all.
-  JavaScript expressions that have or promote side-effects are prohibited including:
+  We put a template expression within the interpolation braces when we wrote `{{1 + 1}}`.
+  We’ll see template expressions again in the [property binding](#property-binding) section,
+  appearing in quotes to the right of the `=` symbol as in `[property]="expression"`.
+
+  We write template expressions in a language that looks like JavaScript.
+  Many JavaScript expressions are legal template expressions, but not all.
+  JavaScript expressions that have or promote side effects are prohibited,
+  including:
   * assignments (`=`, `+=`, `-=`)
   * the `new` operator
   * chaining expressions with `;` or `,`
-  * increment and decrement operators, `++` and `--`.
+  * increment and decrement operators (`++` and `--`)
 
   Other notable differences from JavaScript syntax include:
-  * no support for the bit-wise operators, `|` and `&`
+  * no support for the bitwise operators `|` and `&`
   * new [template expression operators](#expression-operators), such as `|` and `?.`
-  
+
   <a id="expression-context"></a>
-  ### Expression Context
-  
-  Perhaps more surprising, we cannot refer to anything in the global namespace.
-  We can’t refer to `window` or `document`. We can’t call `console.log` or `Math.max`.
-  We are restricted to referencing members of the expression context.
-  
-  The *expression context* is typically the **component instance**, the source of binding values.
+  ### Expression context
+
+  Perhaps more surprising, template expressions cannot refer to anything in the global namespace.
+  They can’t refer to `window` or `document`. They can’t call `console.log` or `Math.max`.
+  They are restricted to referencing members of the expression context.
+
+  The *expression context* is typically the **component instance**, which is
+  the source of binding values.
 
   When we see *title* wrapped in double-curly braces, <code>{{title}}</code>,
   we know that `title` is a property of the data-bound component.
   When we see *isUnchanged* in `[disabled]="isUnchanged"`,
   we know we are referring to that component's `isUnchanged` property.
 
-  The component itself is usually the expression *context* in which case
+  The component itself is usually the expression *context*, in which case
   the template expression usually references that component.
-  
-  The expression context may include an object other than the component.
+
+  The expression context can include objects <!-- CHECK: is that an ok wording change? -->
+  other than the component.
   A [local template variable](#local-vars) is one such alternative context object.
-  
+
 
   <a id="no-side-effects"></a>
-  ### Expression Guidelines
-  Template expressions can make or break an application. 
-  Please follow these guidelines unless you have an exceptionally good reason to break them
-  in specific circumstances that you thoroughly understand.
-  
-  #### No visible side-effects
+  ### Expression guidelines
+  Template expressions can make or break an application.
+  Please follow these guidelines:
 
-  A template expression should have ***no visible side-effects***. 
-  We're not allowed to change any application state other than the value of the
+  * [No visible side effects](#no-visible-side-effects)
+  * [Quick execution](#quick-execution)
+  * [Simplicity](#simplicity)
+  * [Idempotence](#idempotence)
+
+  The only exceptions to these guidelines are specific circumstances that you thoroughly understand.
+
+  #### No visible side effects
+
+  A template expression should not change any application state other than the value of the
   target property.
-  
+
   This rule is essential to Angular's "unidirectional data flow" policy.
   We should never worry that reading a component value might change some other displayed value.
   The view should be stable throughout a single rendering pass.
-  
-  #### Finish fast
+
+  #### Quick execution
   Angular executes template expressions more often than we might think.
   Expressions should finish quickly or the user experience may drag, especially on slower devices.
-  
-  #### Keep them simple
-  Although we can write quite complex template expressions, we strongly discourage that practice. 
-  Most readers frown on JavaScript in the HTML. 
-  A property name or method call should be the norm. 
-  An occasional Boolean negation (`!`) is OK. 
-  Otherwise, confine application and business logic to the component itself where it will be easier to develop and test.    
-  
-  #### Idempotent Expressions
+
+  #### Simplicity
+  Although it's possible to write quite complex template expressions, we really shouldn't.
+
+  A property name or method call should be the norm.
+  An occasional Boolean negation (`!`) is OK.
+  Otherwise, confine application and business logic to the component itself,
+  where it will be easier to develop and test.
+
+  #### Idempotence
   An [idempotent](https://en.wikipedia.org/wiki/Idempotence) expression is ideal because
-  it is free of side-effects and improves Angular's change detection performance.
+  it is free of side effects and improves Angular's change detection performance.
 
   In Angular terms, an idempotent expression always returns *exactly the same thing* until
   one of its dependent values changes.
-  
+
   Dependent values should not change during a single turn of the JavaScript virtual machine.
   If an idempotent expression returns a string or a number, it returns the same string or number
   when called twice in a row. If the expression returns an object (including a `Date` or `Array`),
-  it returns the same object *reference* when called twice in a row. 
+  it returns the same object *reference* when called twice in a row.
 
 <a id="template-statements"></a>
 .l-main-section
 :marked
-  ## Template Statements
-  
-  A template **statement** responds to an ***event*** raised by a binding target 
-  such as an element, component, or directive.
-  
-  We’ll see template statements in [Event Bindings](#event-binding), 
-  appearing in quotes to the right of the (=) symbol as in `(event)="statement"`.
+  ## Template statements
 
-  A template statement *has a side-effect*. 
+  A template **statement** responds to an **event** raised by a binding target
+  such as an element, component, or directive.
+
+  We’ll see template statements in the [event binding](#event-binding) section,
+  appearing in quotes to the right of the `=` symbol as in `(event)="statement"`.
+
+  A template statement *has a side effect*.
   It's how we update application state from user input.
   There would be no point to responding to an event otherwise.
 .l-sub-section
@@ -189,59 +182,62 @@ include ../../../../_includes/_util-fns
     Responding to events is the other side of Angular's "unidirectional data flow".
     We're free to change anything, anywhere, during this turn of the JavaScript virtual machine.
 :marked
-  Angular template statements are also written in a language that looks like JavaScript.
-  The template statement parser is different than the template expression parser and 
-  specifically supports both basic assignment (=) and chaining expressions with semicolons (;) and commas (,).
-  
+  Like template expressions, template *statements* use a language that looks like JavaScript.
+  The template statement parser is different than the template expression parser and
+  specifically supports both basic assignment (`=`) and chaining expressions with semicolons (`;`) and commas (`,`).
+
   However, certain JavaScript syntax is not allowed:
   * the `new` operator
   * increment and decrement operators, `++` and `--`
-  * operator assignment, e.g. `+=`, `-=`
-  * bit-wise operators, `|` and `&`
+  * operator assignment, such as `+=` and `-=`
+  * the bitwise operators `|` and `&`
   * the [template expression operators](#expression-operators)
-  
-  As with expressions, we cannot refer to anything in the global namespace.
-  We can’t refer to `window` or `document`. We can’t call `console.log` or `Math.max`.
-  
-  We are restricted to referencing members of the statement context.
-  The **statement context** is typically the **component instance** to which we are binding an event.
+
+
+  ### Statement context
+
+  As with expressions, statements cannot refer to anything in the global namespace.
+  They can’t refer to `window` or `document`. They can’t call `console.log` or `Math.max`.
+
+  Statements are restricted to referencing members of the statement context.
+  The statement context is typically the **component instance** to which we are binding an event.
 
   The *onSave* in `(click)="onSave()"` is sure to be a method of the data-bound component instance.
-  
+
   The statement context may include an object other than the component.
-  A [local template variable](#local-vars) is one such alternative context object. 
+  A [local template variable](#local-vars) is one such alternative context object.
   We'll frequently see the reserved `$event` symbol in event binding statements,
-  representing the "message" or "payload" of the raised event. 
-.l-sub-section
-  :marked
-    Although we can write quite complex template statements, we strongly discourage that practice. 
-    Most readers frown on JavaScript in the HTML. 
-    A method call or simple property assignment should be the norm.
-:marked
-  Now that we have a feel for template expressions and statements, 
-  we’re ready to learn about the varieties of data binding syntax beyond Interpolation.
+  representing the "message" or "payload" of the raised event.
+
+  ### Statement guidelines
+
+  As with expressions, avoid writing complex template statements.
+  A method call or simple property assignment should be the norm.
+
+  Now that we have a feel for template expressions and statements,
+  we’re ready to learn about the varieties of data binding syntax beyond interpolation.
 
 .l-main-section
 :marked
   <a id="binding-syntax"></a>
-  ## Binding syntax overview
-  Data binding is a mechanism for coordinating what users see with application data values.  
+  ## Binding syntax: An overview
+  Data binding is a mechanism for coordinating what users see with application data values.
   While we could push values to and pull values from HTML,
   the application is easier to write, read, and maintain if we turn these chores over to a binding framework.
   We simply declare bindings between binding sources and target HTML elements and let the framework do the work.
 
-  Angular provides many kinds of data binding and we’ll discuss each of them in this chapter.
-  First we'll take a high level view of Angular data binding and its syntax.
+  Angular provides many kinds of data binding, and we’ll discuss each of them in this chapter.
+  First we'll take a high-level view of Angular data binding and its syntax.
 
-  We can group all bindings into three categories by the direction in which data flows. 
+  We can group all bindings into three categories by the direction in which data flows.
   Each category has its distinctive syntax:
 table
   tr
-    th Data Direction
+    th Data direction
     th Syntax
-    th Binding Type
+    th Binding type
   tr
-    td One way<br>from data source<br>to view target
+    td One-way<br>from data source<br>to view target
     td
       code-example(format="" ).
         {{expression}}
@@ -254,45 +250,45 @@ table
       Class<br>
       Style
     tr
-      td One way<br>from view target<br>to data source
+      td One-way<br>from view target<br>to data source
       td
         code-example(format="" ).
           (target) = "statement"
           on-target = "statement"
       td Event
     tr
-      td Two way
+      td Two-way
       td
         code-example(format="" ).
           [(target)] = "expression"
           bindon-target = "expression"
       td Two-way
 :marked
-  Binding types other than interpolation have a **target name** to the left of the equal sign, 
+  Binding types other than interpolation have a **target name** to the left of the equal sign,
   either surrounded by punctuation (`[]`, `()`) or preceded by a prefix (`bind-`, `on-`, `bindon-`).
 
-  What is that target? Before we can answer that question, we must challenge ourselves to look at Template HTML in a new way.
+  What is that target? Before we can answer that question, we must challenge ourselves to look at template HTML in a new way.
 
-  ### A New Mental Model
+  ### A new mental model
 
   With all the power of data binding and our ability to extend the HTML vocabulary
-  with custom markup, it is tempting to think of Template HTML as “HTML Plus”.
-  
-  *Well it is HTML Plus*.
+  with custom markup, it is tempting to think of template HTML as *HTML Plus*.
+
+  Well, it *is* HTML Plus.
   But it’s also significantly different than the HTML we’re used to.
   We really need a new mental model.
 
-  In the normal course of HTML development, we create a visual structure with HTML elements and
+  In the normal course of HTML development, we create a visual structure with HTML elements, and
   we modify those elements by setting element attributes with string constants.
 +makeExample('template-syntax/ts/app/app.component.html', 'img+button')(format=".")
 :marked
   We still create a structure and initialize attribute values this way in Angular templates.
 
-  Then we learn to create new elements with Components that encapsulate HTML
+  Then we learn to create new elements with components that encapsulate HTML
   and drop them into our templates as if they were native HTML elements
 +makeExample('template-syntax/ts/app/app.component.html', 'hero-detail-1')(format=".")
 :marked
-  That’s “HTML Plus”.
+  That’s HTML Plus.
 
   Now we start to learn about data binding. The first binding we meet might look like this:
 
@@ -308,11 +304,11 @@ table
 
 .l-sub-section
   :marked
-    ### HTML Attribute vs. DOM Property
+    ### HTML attribute vs. DOM property
 
     The distinction between an HTML attribute and a DOM property is crucial to understanding how Angular binding works.
 
-    **Attributes are defined by HTML. Properties are defined by DOM (the Document Object Model).**
+    **Attributes are defined by HTML. Properties are defined by the DOM (Document Object Model).**
 
     * A few HTML attributes have 1:1 mapping to properties. `id` is one example.
 
@@ -320,12 +316,12 @@ table
 
     * Some DOM properties don't have corresponding attributes. `textContent` is one example.
 
-    * Many HTML attributes appear to map to properties ... but not the way we think!
+    * Many HTML attributes appear to map to properties ... but not in the way we might think!
 
     That last category can be especially confusing ... until we understand this general rule:
 
     **Attributes *initialize* DOM properties and then they are done.
-    Property values may change; attribute values don't.**
+    Property values can change; attribute values can't.**
 
     For example, when the browser renders `<input type="text" value="Bob">`, it creates a
     corresponding DOM node with a `value` property *initialized* to "Bob".
@@ -341,10 +337,10 @@ table
     When we add the `disabled` *attribute*, it's presence alone initializes the  button's `disabled` *property* to `true`
     so the button is disabled.
 
-    Adding and removing the `disabled` *attribute* disables and enables the button. The value of the *attribute* is irrelevant
+    Adding and removing the `disabled` *attribute* disables and enables the button. The value of the *attribute* is irrelevant,
     which is why we cannot enable a button by writing `<button disabled="false">Still Disabled</button>`.
 
-    Setting the button's `disabled` *property*  (e.g. with an Angular binding) disables or enables the button.
+    Setting the button's `disabled` *property*  (say, with an Angular binding) disables or enables the button.
     The value of the *property* matters.
 
     **The HTML attribute and the DOM property are not the same thing even when they have the same name.**
@@ -361,9 +357,9 @@ table
     When we data bind, we're dealing exclusively with element and directive properties and events.
     Attributes effectively disappear.
 :marked
-  With this model firmly in mind, we are ready to discuss the variety of target properties to which we may bind.
+  With this model firmly in mind, let's learn about binding targets.
 
-  ### Binding Targets
+  ### Binding targets
   The **target of a data binding** is something in the DOM.
   Depending on the binding type, the target can be an
   (element | component | directive) property, an
@@ -373,30 +369,29 @@ table
 <div width="90%">
 table
   tr
-    th Binding Type
+    th Binding type
     th Target
     th Examples
   tr
     td Property
     td.
-      Element&nbsp;Property<br>
-      Component&nbsp;Property<br>
+      Element&nbsp;property<br>
+      Component&nbsp;property<br>
       Directive&nbsp;property
     td
       +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-syntax-1')(format=".")
   tr
     td Event
     td.
-      Element&nbsp;Event<br>
-      Component&nbsp;Event<br>
-      Directive&nbsp;Event
+      Element&nbsp;event<br>
+      Component&nbsp;event<br>
+      Directive&nbsp;event
     td
       +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-syntax-1')(format=".")
   tr
     td Two-way
     td.
-      Directive&nbsp;Event
-      Property
+      Event and property
     td
       +makeExample('template-syntax/ts/app/app.component.html', '2-way-binding-syntax-1')(format=".")
   tr
@@ -409,13 +404,13 @@ table
   tr
     td Class
     td.
-      <code>class</code> Property
+      <code>class</code> property
     td
       +makeExample('template-syntax/ts/app/app.component.html', 'class-binding-syntax-1')(format=".")
   tr
     td Style
     td.
-      <code>style</code> Property
+      <code>style</code> property
     td
       +makeExample('template-syntax/ts/app/app.component.html', 'style-binding-syntax-1')(format=".")
 </div>
@@ -425,56 +420,56 @@ table
 
 .l-main-section
 :marked
-  ## Property Binding
-  We write a template **Property Binding** when we want to set a property of a view element to the value of 
+  ## Property binding
+  We write a template **property binding** when we want to set a property of a view element to the value of
   a [template expression](#template-expressions).
 
-  The most common Property Binding sets an element property to a component property value as when
-  we bind the source property of an image element to the component’s `heroImageUrl` property.
+  The most common property binding sets an element property to a component property value. An example is
+  binding the `src` property of an image element to a component’s `heroImageUrl` property:
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-1')(format=".")
 :marked
-  … or disable a button when the component says that it `isUnchanged`.
+  Another example is disabling a button when the component says that it `isUnchanged`:
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-2')(format=".")
 :marked
-  … or set a property of a directive
+  Another is setting a property of a directive:
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-3')(format=".")
 :marked
-  … or set the model property of a custom component (a great way
-  for parent and child components to communicate)
+  Yet another is setting the model property of a custom component (a great way
+  for parent and child components to communicate):
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-4')(format=".")
 :marked
   ### One-way *in*
-  People often describe property binding as *one way data binding* because it flows a value in one direction, 
+  People often describe property binding as *one-way data binding* because it flows a value in one direction,
   from a component’s data property into a target element property.
-  
+
   We cannot use property binding to pull values *out* of the target element.
   We can't bind to a property of the target element to read it. We can only set it.
 
 .l-sub-section
   :marked
     Nor can we use property binding to *call* a method on the target element.
-    
+
     If the element raises events we can listen to them with an [event binding](#event-binding).
-    
+
     If we must read a target element property or call one of its methods,
-    we'll need a different technique. 
-    See the API reference for 
-    [viewChild](../api/core/ViewChild-var.html) and 
+    we'll need a different technique.
+    See the API reference for
+    [viewChild](../api/core/ViewChild-var.html) and
     [contentChild](../api/core/ContentChild-var.html).
 
 :marked
-  ### Binding Target
-  A name between enclosing square brackets identifies the target property. The target property in this example is the image element’s `src` property.
+  ### Binding target
+  A name between enclosing square brackets identifies the target property. The target property in the following code is the image element’s `src` property.
 
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-1')(format=".")
 :marked
-  Some developers prefer the `bind-` prefix alternative, known as the “canonical form”:
+  Some people prefer the `bind-` prefix alternative, known as the *canonical form*:
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-5')(format=".")
 :marked
   The target name is always the name of a property, even when it appears to be the name of something else. We see `src` and may think it’s the name of an attribute. No. It’s the name of an image element property.
 
   Element properties may be the more common targets,
-  but Angular looks first to see if the name is a property of a known directive
+  but Angular looks first to see if the name is a property of a known directive,
   as it is in the following example:
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-3')(format=".")
 
@@ -486,87 +481,88 @@ table
 :marked
   If the name fails to match a property of a known directive or element, Angular reports an “unknown directive” error.
 
-  ### Property Binding template expressions
-  Evaluation of the expression should have no visible side-effects. The expression language itself does its part to keep us safe. We can’t assign a value to anything in a Property Binding expression nor use the increment and decorator operators.
+  ### Template expressions in property binding
+  As we've already discussed, evaluation of a template expression should have no visible side effects. The expression language itself does its part to keep us safe. We can’t assign a value to anything in a property binding expression nor use the increment and decorator operators.
 
-  Of course, our expression might invoke a property or method that has side-effects. Angular has no way of knowing that or stopping us.
+  Of course, our expression might invoke a property or method that has side effects. Angular has no way of knowing that or stopping us.
 
   The expression could call something like `getFoo()`. Only we know what `getFoo()` does.
-  If `getFoo()`  changes something and we happen to be binding to that something, we risk an unpleasant experience. Angular may or may not display the changed value. Angular may detect the change and throw a warning error. Our general advice: stick to data properties and methods that return values and do no more.
+  If `getFoo()` changes something and we happen to be binding to that something, we risk an unpleasant experience. Angular may or may not display the changed value. Angular may detect the change and throw a warning error. Our general advice: stick to data properties and to methods that return values and do no more.
 
-  The template expression should evaluate to a value of the type expected by the target property. Most native element properties do expect a string. The image `src` should be set to a string, an URL for the resource providing the image. On the other hand, the `disabled` property of a button expects a Boolean value so our expression should evaluate to `true` or `false`.
+  The template expression should evaluate to a value of the type expected by the target property. Most native element properties expect a string. For example, the image `src` should be set to a string that's an URL for the resource providing the image. On the other hand, the `disabled` property of a button expects a Boolean value, so an expression that's assigned to `disabled` should evaluate to `true` or `false`.
 
-  The `hero` property of the `HeroDetail` component expects a `Hero` object which is exactly what we’re sending in the Property Binding:
+  The `hero` property of the `HeroDetail` component expects a `Hero` object, which is exactly what we’re sending in the property binding:
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-4')(format=".")
 :marked
-  This is good news for the Angular developer.
-  If `hero` were an attribute we could not set it to a `Hero` object.
+  This is good news.
+  If `hero` were an attribute, we could not set it to a `Hero` object.
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-6')(format=".")
 :marked
   We can't set an attribute to an object. We can only set it to a string.
   Internally, the attribute may be able to convert that string to an object before setting the like-named element property.
   That’s good to know but not helpful to us when we're trying to pass a significant data object
   from one component element to another.
-  The power of Property Binding is its ability to bypass the attribute and
+  The power of property binding is its ability to bypass the attribute and
   set the element property directly with a value of the appropriate type.
 
-  ### Property Binding or Interpolation?
-  We often have a choice between Interpolation and Property Binding. The following binding pairs do the same thing
+  ### Property binding or interpolation?
+  We often have a choice between interpolation and property binding. The following binding pairs do the same thing:
 
 +makeExample('template-syntax/ts/app/app.component.html', 'property-binding-vs-interpolation')(format=".")
 :marked
-  Interpolation is actually a convenient alternative for Property Binding in many cases.
-  In fact, Angular  translates those Interpolations into the corresponding Property Bindings
+  Interpolation is a convenient alternative for property binding in many cases.
+  In fact, Angular  translates those interpolations into the corresponding property bindings
   before rendering the view.
 
   There is no technical reason to prefer one form to the other.
-  We lean toward readability which tends to favor interpolation.
+  We lean toward readability, which tends to favor interpolation.
   We suggest establishing coding style rules for the organization and choosing the form that
   both conforms to the rules and feels most natural for the task at hand.
 
 .l-main-section
 :marked
   <a id="other-bindings"></a>
-  ## Attribute, Class, and Style Bindings
-  The template syntax provides specialized one-way bindings for scenarios less well suited to Property Binding.
+  ## Attribute, class, and style bindings
+  The template syntax provides specialized one-way bindings for scenarios less well suited to property binding.
 
-  ### Attribute Binding
-  We can set the value of an attribute directly with an **Attribute Binding**.
+  ### Attribute binding
+  We can set the value of an attribute directly with an **attribute binding**.
 .l-sub-section
   :marked
     This is the only exception to the rule that a binding sets a target property. This is the only binding that creates and sets an attribute.
 
 :marked
-  We have stressed throughout this chapter that setting an element property with a Property Binding is always preferred to setting the attribute with a string. Why does Angular offer Attribute Binding?
+  We have stressed throughout this chapter that setting an element property with a property binding is always preferred to setting the attribute with a string. Why does Angular offer attribute binding?
 
-  **We must use Attribute Binding when there is no element property to bind.**
+  **We must use attribute binding when there is no element property to bind.**
 
-  Consider the [aria](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA),
-  [svg](https://developer.mozilla.org/en-US/docs/Web/SVG), and
+  Consider the [ARIA](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA),
+  [SVG](https://developer.mozilla.org/en-US/docs/Web/SVG), and
   table span attributes. They are pure attributes.
-  They do not correspond to element properties and they do not set element properties.
+  They do not correspond to element properties, and they do not set element properties.
   There are no property targets to bind to.
 
   We become painfully aware of this fact when we try to write something like this:
 code-example(language="html").
   &lt;tr>&lt;td colspan="{{1 + 1}}">Three-Four&lt;/td>&lt;/tr>
 :marked
-  … and get the error:
+  We get this error:
 code-example(format="", language="html").
   Template parse errors:
   Can't bind to 'colspan' since it isn't a known native property
 :marked
   As the message says, the `<td>` element does not have a `colspan` property.
-  It has the "colspan" *attribute* but
-  interpolation and property binding can only set properties, not attributes.
+  It has the "colspan" *attribute*, but
+  interpolation and property binding can set only *properties*, not attributes.
 
-  We need an Attribute Binding to create and bind to such attributes.
+  We need attribute bindings to create and bind to such attributes.
 
-  Attribute Binding syntax resembles Property Binding.
-  Instead of an element property between brackets, we start with the keyword **`attr`**
-  followed by the name of the attribute and then set it with an expression that resolves to a string.
+  Attribute binding syntax resembles property binding.
+  Instead of an element property between brackets, we start with the prefix **`attr`**,
+  followed by a dot (`.`) and the name of the attribute. We then set the attribute
+  value, using an expression that resolves to a string.
 
-  Here we bind `[attr.colspan]` to a calulated value:
+  Here we bind `[attr.colspan]` to a calculated value:
 +makeExample('template-syntax/ts/app/app.component.html', 'attrib-binding-colspan')(format=".")
 :marked
   Here's how the table renders:
@@ -575,28 +571,29 @@ code-example(format="", language="html").
     <tr><td>Five</td><td>Six</td></tr>
    </table>
 
-  One of the primary use cases for the Attribute Binding
-  is to set aria attributes as we see in this example
+  One of the primary use cases for attribute binding
+  is to set ARIA attributes, as in this example:
 +makeExample('template-syntax/ts/app/app.component.html', 'attrib-binding-aria')(format=".")
 :marked
-  ### Class Binding
+  ### Class binding
 
-  We can add and remove CSS class names from an element’s `class` attribute with the **Class Binding**.
+  We can add and remove CSS class names from an element’s `class` attribute with
+  a **class binding**.
 
-  Class Binding syntax resembles Property Binding.
-  Instead of an element property between brackets, we start with the keyword `class` followed
-  by the name of a CSS class: `[class.class-name]`.
+  Class binding syntax resembles property binding.
+  Instead of an element property between brackets, we start with the prefix `class`,
+  optionally followed by a dot (`.`) and the name of a CSS class: `[class.class-name]`.
 
-  In the following examples we see how to add and remove the application's "special" class
-  with class bindings.  We start by setting the attribute without binding:
+  The following examples show how to add and remove the application's "special" class
+  with class bindings.  Here's how we set the attribute without binding:
 +makeExample('template-syntax/ts/app/app.component.html', 'class-binding-1')(format=".")
 :marked
-  We replace that with a binding to a string of the desired class names; this is an all-or-nothing, replacement binding.
+  We can replace that with a binding to a string of the desired class names; this is an all-or-nothing, replacement binding.
 +makeExample('template-syntax/ts/app/app.component.html', 'class-binding-2')(format=".")
 :marked
-  Finally, we bind to a specific class name.
-  Angular adds the class when the template expression evaluates to something truthy and
-  removes the class name when the expression is falsey.
+  Finally, we can bind to a specific class name.
+  Angular adds the class when the template expression evaluates to something truthy.
+  It removes the class when the expression is falsey.
 +makeExample('template-syntax/ts/app/app.component.html', 'class-binding-3')(format=".")
 
 .l-sub-section
@@ -605,17 +602,17 @@ code-example(format="", language="html").
     we generally prefer the [NgClass directive](#ngClass) for managing multiple class names at the same time.
 
 :marked
-  ### Style Binding
+  ### Style binding
 
-  We can set inline styles with a **Style Binding**.
+  We can set inline styles with a **style binding**.
 
-  Style Binding syntax resembles Property Binding.
-  Instead of an element property between brackets, we start with the key word `style`
-  followed by the name of a CSS style property: `[style.style-property]`.
+  Style binding syntax resembles property binding.
+  Instead of an element property between brackets, we start with the prefix `style`,
+  followed by a dot (`.`) and the name of a CSS style property: `[style.style-property]`.
 
 +makeExample('template-syntax/ts/app/app.component.html', 'style-binding-1')(format=".")
 :marked
-  Some Style Binding styles have unit extension. Here we conditionally set the `fontSize` in  “em” and “%” units .
+  Some style binding styles have unit extension. Here we conditionally set the `fontSize` in  “em” and “%” units .
 +makeExample('template-syntax/ts/app/app.component.html', 'style-binding-2')(format=".")
 
 .l-sub-section
@@ -625,126 +622,146 @@ code-example(format="", language="html").
 
 .l-main-section
 :marked
-  ## Event Binding
-  The bindings we’ve met so far flow data in one direction *from the component to an element*.
+  ## Event binding
+  The bindings we’ve met so far flow data in one direction: *from the component to an element*.
 
-  Users don’t just stare at the screen. They enter text into a input box. They pick items from a list.
-  They click buttons. Such user actions may result in a flow of data in the opposite direction,
-  ***from an element to the component***.
+  Users don’t just stare at the screen. They enter text into input boxes. They pick items from lists.
+  They click buttons. Such user actions may result in a flow of data in the opposite direction:
+  *from an element to the component*.
 
   The only way to know about a user action is to listen for certain events such as
-  keystrokes, mouse movements, clicks and touches.
-  We declare our interest in user actions through Angular Event Binding.
+  keystrokes, mouse movements, clicks, and touches.
+  We declare our interest in user actions through Angular event binding.
 
-  Event Binding syntax consists of a target event within parentheses on the left of an equal sign and a quoted
-  [**template statement**](#template-statements) on the right.
-  
-  The following Event Binding listens for the button’s click event and calls the component's `onSave()` method:
+  Event binding syntax consists of a **target event** within parentheses on the left of an equal sign, and a quoted
+  [template statement](#template-statements) on the right.
+  The following event binding listens for the button’s click event, calling
+  the component's `onSave()` method whenever a click occurs:
 +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-1')(format=".")
 :marked
-  ### Binding target
-  A **name between enclosing parentheses** identifies the target event. In the following example, the target is the button’s click event.
+  ### Target event
+  A **name between enclosing parentheses** &mdash; for example, `(keyup)` &mdash;
+  identifies the target event. In the following example, the target is the button’s click event.
 +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-1')(format=".")
 :marked
-  Some developers prefer the `on-` prefix alternative, known as the “canonical form”:
+  Some people prefer the `on-` prefix alternative, known as the *canonical form*:
 +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-2')(format=".")
 :marked
   Element events may be the more common targets, but Angular looks first to see if the name matches an event property
-  of a known directive as it does in the following example:
+  of a known directive, as it does in the following example:
 +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-3')(format=".")
 :marked
   If the name fails to match an element event or an output property of a known directive,
   Angular reports an “unknown directive” error.
 
   ### $event and event handling statements
-  In an Event Binding, Angular sets up an event handler for the target event.
+  In an event binding, Angular sets up an event handler for the target event.
 
   When the event is raised, the handler executes the template statement.
   The template statement typically involves a receiver that wants to do something
-  in response to the event such as take a value from the HTML control and store it
+  in response to the event, such as take a value from the HTML control and store it
   in a model.
 
-  The binding conveys information about the event including data values through
+  The binding conveys information about the event, including data values, through
   an **event object named `$event`**.
 
-  The shape of the $event object is determined by the target event itself.
+  The shape of the event object is determined by the target event itself.
   If the target event is a native DOM element event, the `$event` is a
-  [DOM event object]( https://developer.mozilla.org/en-US/docs/Web/Events) with properties such as `target` and `target.value`.
+  [DOM event object]( https://developer.mozilla.org/en-US/docs/Web/Events),
+  with properties such as `target` and `target.value`.
 
   Consider this example:
 +makeExample('template-syntax/ts/app/app.component.html', 'without-NgModel')(format=".")
 :marked
-  We’re binding the input box `value` to a `firstName` property and we’re listening for changes by binding to the input box’s `input` event.
+  We’re binding the input box `value` to a `firstName` property, and we’re listening for changes by binding to the input box’s `input` event.
   When the user makes changes, the `input` event is raised, and the binding executes the statement within a context that includes the DOM event object, `$event`.
 
-  We must follow the `$event.target.value` path to get the changed text so we can update the `firstName`
+  To update the `firstName` property, we must get the changed text by following
+  the path `$event.target.value`.
 
   If the event belongs to a directive (remember: components are directives), `$event` has whatever shape the directive chose to produce.
+
+  <a id="eventemitter"></a>
+  <a id="custom-event"></a>
+  ### Custom events with EventEmitter
+
+  Directives typically raise custom events with an Angular [EventEmitter](../api/core/EventEmitter-class.html).
+  A directive creates an `EventEmitter` and exposes it as a property.
+  The directive calls `EventEmitter.emit(payload)` to fire an event, passing in a message payload that can be anything.
+  Parent directives listen for the event by binding to this property and accessing the payload through the `$event` object.
+
   Consider a `HeroDetailComponent` that produces `deleted` events with an `EventEmitter`.
-+makeExample('template-syntax/ts/app/hero-detail.component.ts', 'deleted', 'HeroDetailComponent.ts (excerpt)')(format=".")
++makeExample('template-syntax/ts/app/hero-detail.component.ts',
+'deleted', 'HeroDetailComponent.ts (excerpt)')(format=".")
 :marked
-  When something invokes the `onDeleted()` method, we "emit" a `Hero` object.
+  When the user clicks a button, the component invokes the `onDeleted()` method, which emits a `Hero` object.
+  The `HeroDetailComponent` doesn't know how to delete a hero. Its job is to present information and
+  respond to user actions.
 
-  Now imagine a parent component that listens for that event with an Event Binding.
-+makeExample('template-syntax/ts/app/app.component.html', 'event-binding-to-component')(format=".")
+  Now imagine a parent component that binds to the `HeroDetailComponent`'s `deleted` event.
+
++makeExample('template-syntax/ts/app/app.component.html',
+'event-binding-to-component')(format=".")
 :marked
-  The event binding surfaces the *hero-to-delete* emitted by `HeroDetail` to the statement via the `$event` variable.
-  We pass it along to the parent `onHeroDeleted()` method.
-  That method presumably knows how to delete the hero.
+  When the `deleted` event fires, Angular calls the parent component's `onHeroDeleted` method,
+  passing the *hero-to-delete* (emitted by `HeroDetail`) in the `$event` variable.
 
-  Evaluation of this Event Binding template statement has a side-effect. It deletes a hero.
-  Side-effects are not just OK; they are expected.
+  The `onHeroDeleted` method has a side effect: It deletes a hero.
+  Side effects are not just OK, they are expected.
 
-  The statement could update the model thereby triggering other changes that percolate through the system, changes that
-  are ultimately displayed in this view and other views.
-  The event processing may result in queries and saves to a remote server. It's all good.
+  Deleting the hero updates the model, perhaps triggering other changes
+  including queries and saves to a remote server.
+  These changes percolate through the system and are ultimately displayed in this and other views.
+  It's all good.
 
-  ### Event bubbling and propagation
-  Angular invokes the event-handling statement if the event is raised by the current element or one of its child elements.
-+makeExample('template-syntax/ts/app/app.component.html', 'event-binding-bubbling')(format=".")
-:marked
-  Many DOM events, both [native](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Overview_of_Events_and_Handlers ) and [custom](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events ),  “bubble” events up their ancestor tree of DOM elements until an event handler along the way prevents further propagation.
-
-.l-sub-section
+//
   :marked
-    `EventEmitter` events don’t bubble.
+    ### Event bubbling and propagation [TODO: reinstate this section when it becomes true]
+    Angular invokes the event-handling statement if the event is raised by the current element or one of its child elements.
+  +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-bubbling')(format=".")
+  :marked
+    Many DOM events, both [native](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Overview_of_Events_and_Handlers ) and [custom](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events ), bubble up their ancestor tree of DOM elements until an event handler along the way prevents further propagation.
 
-:marked
-  The result of an Event Binding statement determines if
-  [event propagation](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Examples#Example_5:_Event_Propagation)
-  continues or stops with the current element.
+  .l-sub-section
+    :marked
+      `EventEmitter` events don’t bubble.
 
-  Event propagation stops if the binding statement returns a falsey value (as does a method with no return value).
-  Clicking the button in this next example triggers a save;
-  the click doesn't make it to the outer `<div>` so it's save is not called:
-+makeExample('template-syntax/ts/app/app.component.html', 'event-binding-no-propagation')(format=".")
-:marked
-  Propagation continues if the statement returns a truthy value. The click is heard both by the button
-  and the outer `<div>`, causing a double save:
-+makeExample('template-syntax/ts/app/app.component.html', 'event-binding-propagation')(format=".")
+  :marked
+    The result of an event binding statement determines whether
+    [event propagation](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Examples#Example_5:_Event_Propagation)
+    continues or stops with the current element.
+
+    Event propagation stops if the binding statement returns a falsey value (as does a method with no return value).
+    Clicking the button in the next example triggers a save;
+    the click doesn't make it to the outer `<div>` so the div's save handler is not called.
+  +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-no-propagation')(format=".")
+  :marked
+    Propagation continues if the statement returns a truthy value. In the next example, the click is heard by both the button
+    and the outer `<div>`, causing a double save.
+  +makeExample('template-syntax/ts/app/app.component.html', 'event-binding-propagation')(format=".")
 
 
 .l-main-section
 :marked
   <a name="ngModel"></a>
-  ## Two-Way Binding with NgModel
-  When developing data entry forms we often want to both display a data property and update that property when the user makes changes.
+  ## Two-way binding with NgModel
+  When developing data entry forms, we often want to both display a data property and update that property when the user makes changes.
 
-  The `NgModel` directive serves that purpose as seen in this example:
+  The `NgModel` directive serves that purpose, as in this example:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgModel-1')(format=".")
 .callout.is-important
-  header 
+  header
     :marked
        <span style="font-family:consolas; monospace">[()]</span> = banana in a box
   :marked
     To remember that the parentheses go inside the brackets, visualize a *banana in a box*.
 :marked
-  If we prefer the “canonical” prefix form to the punctuation form, we can write
+  Alternatively, we can use the canonical prefix form:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgModel-2')(format=".")
 :marked
-  There’s a story behind this construction, a story that builds on the Property and Event Binding techniques we learned previously.
+  There’s a story behind this construction, a story that builds on the property and event binding techniques we learned previously.
 
-  We could have achieved the same result as `NgModel` with separate bindings to the
+  We could have achieved the same result as `NgModel` with separate bindings to
   the `<input>` element's  `value` property and `input` event.
 +makeExample('template-syntax/ts/app/app.component.html', 'without-NgModel')(format=".")
 :marked
@@ -756,7 +773,7 @@ code-example(format="", language="html").
   and raises its own event with the changed text ready for us to consume.
 +makeExample('template-syntax/ts/app/app.component.html', 'NgModel-3')(format=".")
 :marked
-  That’s an improvement. It should be better.
+  That’s an improvement, but it could be better.
 
   We shouldn't have to mention the data property twice. Angular should be able to read the component’s data property and set it
   with a single declaration &mdash; which it can with the `[( )]` syntax:
@@ -764,33 +781,36 @@ code-example(format="", language="html").
 
 .l-sub-section
   :marked
-    Internally, Angular maps the term, `ngModel`, to an `ngModel` input property and an
+    Internally, Angular maps the term `ngModel` to an `ngModel` input property and an
     `ngModelChange` output property.
-    That’s a specific example of a more general pattern in which it matches `[(x)]` to an `x` input property
-    for Property Binding and an `xChange` output property for Event Binding.
-
-    We can write our own two-way binding directive that follows this pattern if we're ever in the mood to do so.
+    That’s a specific example of a more general pattern in which Angular matches `[(x)]` to an `x` input property
+    for property binding and an `xChange` output property for event binding.
+    <!-- TODO: We haven't talked about input and output properties before on
+    this page (and barely mentioned them before in the Forms page). Introduce them better. -->
 :marked
   Is `[(ngModel)]` all we need? Is there ever a reason to fall back to its expanded form?
 
-  Well `NgModel` can only set the target property.
+  Well, `NgModel` can only set the target property.
   What if we need to do something more or something different when the user changes the value?
+  Then we need to use the expanded form.
 
-  Let's try something silly like forcing the input value to uppercase.
+  Let's try something silly like forcing the input value to uppercase:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgModel-4')(format=".")
 :marked
   Here are all variations in action, including the uppercase version:
 figure.image-display
     img(src='/resources/images/devguide/template-syntax/ng-model-anim.gif' alt="NgModel variations")
 :marked
+  <!-- TODO: Update image to use camelCase instead of kabob-case -->
 
 .l-main-section
 :marked
   <a name="directives"></a>
-  ## Built-in Directives
+  ## Built-in directives
 
   Earlier versions of Angular included over seventy built-in directives.
-  The community contributed many more and individuals have created countless private directives for internal applications.
+  The community contributed many more, and countless private directives
+  have been created for internal applications.
 
   We don’t need many of those directives in Angular 2.
   Quite often we can achieve the same results with the more capable and expressive Angular 2 binding system.
@@ -799,9 +819,9 @@ figure.image-display
 :marked
   We still benefit from directives that simplify complex tasks.
   Angular still ships with built-in directives; just not as many.
-  We will write our own directives; just not as many.
+  We'll write our own directives, just not as many.
 
-  In this segment we review some of the most frequently used built-in directives.
+  This segment reviews some of the most frequently used built-in directives.
 
 <a id="ngClass"></a>
 .l-main-section
@@ -812,74 +832,73 @@ figure.image-display
   by adding and removing CSS classes dynamically.
   We can bind to `NgClass` to add or remove several classes simultaneously.
 
-  We prefer to use a [Class Binding](#class-binding) to add or remove a *single* class.
+  A [class binding](#class-binding) is a good way to add or remove a *single* class.
 +makeExample('template-syntax/ts/app/app.component.html', 'class-binding-3a')(format=".")
 :marked
   The `NgClass` directive may be the better choice
-  when we want to add or remove *many* classes at the same time.
+  when we want to add or remove *many* CSS classes at the same time.
 
-  Our favorite way to apply `NgClass` is by binding it to a key:value control object. Each key of the object is a class name and its value is `true` if the class should be added, `false` if it should be removed.
+  A good way to apply `NgClass` is by binding it to a key:value control object. Each key of the object is a CSS class name; its value is `true` if the class should be added, `false` if it should be removed.
 
-  Consider a component method such as `setClasses` that returns its approval of two class names:
+  Consider a component method such as `setClasses` that manages the state of three CSS classes:
 +makeExample('template-syntax/ts/app/app.component.ts', 'setClasses')(format=".")
 :marked
-  Now add an `NgClass` property binding to call it like this
+  Now we can add an `NgClass` property binding that calls `setClasses`
+  and sets the element's classes accordingly:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgClass-1')(format=".")
 
 <a id="ngStyle"></a>
 .l-main-section
 :marked
   ### NgStyle
-  We may set inline styles dynamically based on the state of the component.
-  We bind to `NgStyle` to set many inline styles simultaneously.
+  We can set inline styles dynamically, based on the state of the component.
+  Binding to `NgStyle` lets us set many inline styles simultaneously.
 
-  We prefer to use a [Style Binding](#style-binding) to set a *single* style value.
+  A [style binding](#style-binding) is an easy way to set a *single* style value.
 +makeExample('template-syntax/ts/app/app.component.html', 'NgStyle-1')(format=".")
 :marked
   The `NgStyle` directive may be the better choice
   when we want to set *many* inline styles at the same time.
 
   We apply `NgStyle` by binding it to a key:value control object.
-  Each key of the object is a style name and its value is whatever is appropriate for that style.
+  Each key of the object is a style name; its value is whatever is appropriate for that style.
 
   Consider a component method such as `setStyles` that returns an object defining three styles:
 +makeExample('template-syntax/ts/app/app.component.ts', 'setStyles')(format=".")
 :marked
-  Now add an `NgStyle` property binding to call it like this
+  Now we just add an `NgStyle` property binding that calls `setStyles`
+  and sets the element's styles accordingly:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgStyle-2')(format=".")
-:marked
-  Alternatively, we can return an object with camelCase style property names with the same effects:
-+makeExample('template-syntax/ts/app/app.component.ts', 'setStyles2')(format=".")
-:marked
 
 <a id="ngIf"></a>
 .l-main-section
 :marked
   ### NgIf
-  We can add an element sub-tree (an element and its children) to the DOM  by binding an `NgIf` directive to a truthy expression.
+  We can add an element subtree (an element and its children) to the DOM  by binding an `NgIf` directive to a truthy expression.
 +makeExample('template-syntax/ts/app/app.component.html', 'NgIf-1')(format=".")
 
 .alert.is-critical
   :marked
-    The leading asterisk (\*) in front of `ngIf` is a critical part of this syntax.
-    See the section below on [\* and &lt;template>](#star-template).
+    Don't forget the asterisk (`*`) in front of `ngIf`.
+    For more information, see [\* and &lt;template>](#star-template).
 :marked
-  Binding to a falsey expression removes the element sub-tree from the DOM.
+  Binding to a falsey expression removes the element subtree from the DOM.
 +makeExample('template-syntax/ts/app/app.component.html', 'NgIf-2')(format=".")
 :marked
   #### Visibility and NgIf are not the same
-  We can show and hide an element sub-tree (the element and its children) with a  [Class](#class-binding) or a [Style](#style-binding) binding:
+  We can show and hide an element subtree (the element and its children) with a
+  [class](#class-binding) or [style](#style-binding) binding:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgIf-3')(format=".")
 :marked
-  Hiding a sub-tree is quite different from excluding a sub-tree with `NgIf`.
+  Hiding a subtree is quite different from excluding a subtree with `NgIf`.
 
-  When we hide the element sub-tree, it remains in the DOM.
-  Components in the sub-tree are preserved along with their state.
+  When we hide the element subtree, it remains in the DOM.
+  Components in the subtree are preserved, along with their state.
   Angular may continue to check for changes even to invisible properties.
-  The sub-tree may tie up substantial memory and computing resources.
+  The subtree may tie up substantial memory and computing resources.
 
-  When `NgIf` is `false`, Angular physically removes the element sub-tree from the DOM.
-  It destroys components in the sub-tree along with their state which may free up substantial resources
+  When `NgIf` is `false`, Angular physically removes the element subtree from the DOM.
+  It destroys components in the subtree, along with their state, potentially freeing up substantial resources and
   resulting in better performance for the user.
 
   The show/hide technique is probably fine for small element trees.
@@ -890,140 +909,142 @@ figure.image-display
 :marked
   ### NgSwitch
   We bind to `NgSwitch` when we want to display *one* element tree (an element and its children)
-  from a *set* of possible element trees based on some condition.
-  Angular only puts the *selected* element tree into the DOM.
+  from a *set* of possible element trees, based on some condition.
+  Angular puts only the *selected* element tree into the DOM.
 
   Here’s an example:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgSwitch')(format=".")
 :marked
-  We bind the parent `NgSwitch` directive to an expression returning a “switch value”.  The value is a string in this example but it can be a value of any type.
+  We bind the parent `NgSwitch` directive to an expression returning a *switch value*.  The value is a string in this example, but it can be a value of any type.
 
   The parent `NgSwitch` directive controls a set of child`<template>` elements. Each `<template>` wraps a candidate subtree. A template is either pegged to a “match value” expression or marked as the default template.
 
-  **At any particular moment, only one of these templates will be rendered**
+  **At any particular moment, at most one of these templates is in the DOM.**
 
-  If the template’s “match value” equals the “switch value”, Angular adds the template’s sub-tree to the DOM. If no template is a match and there is a default template, Angular adds the default template’s sub-tree to the DOM. Angular removes and destroys the sub-tree’s of all other templates.
+  If the template’s *match value* equals the switch value, Angular adds the template’s subtree to the DOM. If no template is a match and there is a default template, Angular adds the default template’s subtree to the DOM. Angular removes and destroys the subtrees of all other templates.
 
-  There are three collaborating directives at work here.
-  1. `ngSwitch` - bound to an expression that returns the switch value.
-  1. `ngSwitchWhen` - bound to an expression returning a match value.
-  1. `ngSwitchDefault` - a marker attribute on the default template.
+  Three collaborating directives are at work here:
+  1. `ngSwitch`: bound to an expression that returns the switch value
+  1. `ngSwitchWhen`: bound to an expression returning a match value
+  1. `ngSwitchDefault`: a marker attribute on the default template
 
 <a id="ngFor"></a>
 .l-main-section
 :marked
   ### NgFor
-  `NgFor` is a “repeater” directive. It will be familiar if we’ve written repeaters for other view engines.
+  `NgFor` is a _repeater_ directive &mdash; a way to customize data display.
 
   Our goal is to present a list of items. We define a block of HTML that defines how a single item should be displayed.
   We tell Angular to use that block as a template for rendering each item in the list.
 
-  Here is an example of `NgFor` applied to a simple `<div>`.
+  Here is an example of `NgFor` applied to a simple `<div>`:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgFor-1')(format=".")
 :marked
-  We can apply an `NgFor` to a component element as well as we do in this example:
+  We can also apply an `NgFor` to a component element, as in this example:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgFor-2')(format=".")
 
 .alert.is-critical
   :marked
-    The leading asterisk (\*) in front of `ngFor` is a critical part of this syntax.
-    See the section below on [\* and &lt;template>](#star-template).
+    Don't forget the asterisk (`*`) in front of `ngFor`.
+    For more information, see [\* and &lt;template>](#star-template).
 :marked
   The text assigned to `*ngFor` is the instruction that guides the repeater process.
 
 .l-sub-section
   :marked
-    #### NgFor Micro-syntax
+    #### NgFor microsyntax
     The string assigned to `*ngFor` is not a [template expression](#template-expressions).
-    It’s a little language of its own called a “micro-syntax” that Angular interprets. In this example it means:
+    It’s a *microsyntax* &mdash; a little language of its own that Angular interprets. In this example, the string "#hero of heroes" means:
 
     >*Take each hero in the `heroes` array, store it in the local `hero` variable, and make it available to the templated HTML
-    for each iteration*.
+    for each iteration.*
 
     Angular translates this instruction into a new set of elements and bindings.
-    We’ll talk about this in the next section about templates.
+    We’ll talk about this in the next section.
 :marked
-  In our two examples, the `ngFor` directive iterates over the `heroes` array returned by the parent component’s `heroes` property
-  and stamps out instances of the element to which it is applied.
+  In the two previous examples, the `ngFor` directive iterates over the `heroes` array returned by the parent component’s `heroes` property,
+  stamping out instances of the element to which it is applied.
   Angular creates a fresh instance of the template for each hero in the array.
 
-  The (#) character before "hero" identifies a [local template variable](#local-vars) called `hero`.
+  The hash (`#`) character before "hero" creates a [local template variable](#local-vars) called `hero`.
 
-  We reference this variable within the template to access a hero’s properties as we’re doing in the interpolation
-  or we can pass it in a binding to a component element as we're doing with `hero-detail`.
+  We use this variable within the template to access a hero’s properties,
+  as we’re doing in the interpolation.
+  We can also pass the variable in a binding to a component element,
+  as we're doing with `hero-detail`.
 
   #### NgFor with index
-  The `ngFor` directive supports an optional index that increases from 0 to the length of the array for each iteration.
-  We can capture that in another local template variable (`i`) and use it in our  template too.
+  The `ngFor` directive supports an optional `index` that increases from 0 to the length of the array for each iteration.
+  We can capture the index in a local template variable and use it in our  template.
 
-  This next example stamps out rows that display like "1 - Hercules Son of Zeus":
+  The next example captures the index in a variable named `i`, using it to stamp out rows like "1 - Hercules Son of Zeus".
 
 +makeExample('template-syntax/ts/app/app.component.html', 'NgFor-3')(format=".")
 :marked
 .l-sub-section
   :marked
-    Learn about other special values such as `last`, `even` and `odd` in the [API](../api/common/NgFor-directive.html) guide.
+    Learn about other special values such as `last`, `even`, and `odd` in the [NgFor API reference](../api/common/NgFor-directive.html).
 
 <a name="star-template"></a>
 <a name="structural-directive"></a>
 .l-main-section
 :marked
   ## * and &lt;template>
-  When we reviewed the `ngFor` and `ngIf` built-in directives we called out an oddity of the syntax, the asterisk (*)  that appears before the directive name.
+  When we reviewed the `NgFor` and `NgIf` built-in directives, we called out an oddity of the syntax: the asterisk (`*`) that appears before the directive name.
 
-  This is a bit of “**syntactic sugar**” that makes it easier to read and write directives that modify HTML layout
+  The `*` is a bit of syntactic sugar that makes it easier to read and write directives that modify HTML layout
   with the help of templates.
   `NgFor`, `NgIf`, and `NgSwitch` all add and remove element subtrees that are wrapped in `<template>` tags.
 
-  With the [NgSwitch](#ngSwitch) directive we always write the `<template>` tags explicitly as we saw [above](#ngSwitch).
+  With the [NgSwitch](#ngSwitch) directive we always write the `<template>` tags explicitly.
   There isn’t much choice; we define a different template for each switch choice
   and let the directive render the template that matches the switch value.
 
-  [NgFor](#ngFor) and [NgIf](#ngIf) only need one template,
-  the *template-to-repeat* and the *template-to-include* respectively.
+  [NgFor](#ngFor) and [NgIf](#ngIf), on the other hand, each need only one template:
+  the *template-to-repeat* and the *template-to-include*, respectively.
 
-  The (\*) prefix syntax is a convenient way for developers to skip the `<template>` wrapper tags and
+  The `*` prefix syntax is a convenient way to skip the `<template>` wrapper tags and
   focus directly on the HTML element to repeat or include.
-  Angular sees the (*) and expands the HTML into the `<template>` tags for us.
+  Angular sees the `*` and expands the HTML into the `<template>` tags for us.
 
   ### Expanding `*ngIf`
-  We can do that ourselves if we wish. Instead of writing ...
+  We can do that expansion ourselves if we wish. Here's some code with `*ngIf`:
 +makeExample('template-syntax/ts/app/app.component.html', 'Template-1')(format=".")
 :marked
-  … we can write:
+  Here's the equivalent with `<template>` and `ngIf`:
 +makeExample('template-syntax/ts/app/app.component.html', 'Template-2')(format=".")
 :marked
-  Notice the (\*) is gone and we have a [Property Binding](#property-binding) to the `ngIf`
+  Notice that the `*` is gone and we have a [property binding](#property-binding) to the `ngIf`
   directive, applied in this case to the `<template>` rather than
   the application’s `hero-detail` component.
 
   The `[hero]="currentHero"` binding remains on the child `<hero-detail>`
-  element inside the template. Angular does that too.
+  element inside the template.
 
 
 .callout.is-critical
   header Remember the brackets!
   :marked
     Don’t make the mistake of writing `ngIf="currentHero"`!
-    That syntax assigns the *string* value, "currentHero", to `ngIf`.
-    In JavaScript a non-empty string is a truthy value so `ngIf` would always be
-    `true` and Angular will always display the `hero-detail`
+    That syntax assigns the *string* value "currentHero" to `ngIf`.
+    In JavaScript a non-empty string is a truthy value, so `ngIf` would always be
+    `true` and Angular would always display the `hero-detail`
     … even when there is no `currentHero`!
 
 :marked
   ### Expanding `*ngFor`
-  A similar transformation applies to `*ngFor`. We can "de-sugar" the syntax ourselves and go from ...
+  A similar transformation applies to `*ngFor`. We can de-sugar the syntax ourselves. First, here's an example with `*ngFor`:
 +makeExample('template-syntax/ts/app/app.component.html', 'NgFor-2')(format=".")
 :marked
-  ... to
+  Here's the same example, slightly expanded:
 +makeExample('template-syntax/ts/app/app.component.html', 'Template-3')(format=".")
 :marked
-  ... and from there to
+  And here it is, expanded further:
 +makeExample('template-syntax/ts/app/app.component.html', 'Template-4')(format=".")
 :marked
-  This is a bit more complex than `NgIf` because a repeater has more moving parts to configure.
+  The `NgFor` code is a bit more complex than `NgIf` because a repeater has more moving parts to configure.
   In this case, we have to remember the `NgForOf` directive that identifies the list.
-  It should be clear why we prefer the `*ngFor` syntax to writing out this expanded HTML ourselves.
+  Using the `*ngFor` syntax is much easier than writing out this expanded HTML ourselves.
 
 <a id="local-vars"></a>
 .l-main-section
@@ -1032,20 +1053,21 @@ figure.image-display
 
   A **local template variable** is a vehicle for moving data across element lines.
 
-  We've seen the `#hero` local template variable several times in this chapter,
+  We've seen `#hero` used to declare a local template variable several times in this chapter,
   most prominently when writing [NgFor](#ngFor) repeaters.
 
-  In the [* and &lt;templates>](#star-template) segment we learned how Angular expands
+  In [* and &lt;templates>](#star-template), we learned how Angular expands
   an `*ngFor` on a component tag into a `<template>` that wraps the component.
 +makeExample('template-syntax/ts/app/app.component.html', 'Template-4')(format=".")
 :marked
-  The (#) prefix character in front of "hero" means that we're defining a `hero` variable.
+  The hash (`#`) prefix to "hero" means that we're defining a `hero` variable.
 .l-sub-section
   :marked
-    Some folks don't like the (#) character.
-    The `var-` prefix is the  “cannonical” alternative to "#". We could have declared our variable as `var-hero`.
+    Folks who don't like using the `#` character can use its canonical alternative,
+    the `var-` prefix. For example, we can declare the our `hero` variable using
+    either `#hero` or `var-hero`.
 :marked
-  We defined `hero` on the outer `<template>` element where it becomes the current hero item
+  We define `hero` on the outer `<template>` element, where it becomes the current hero item
   as Angular iterates through the list of heroes.
 
   The `hero` variable appears again in the binding on the inner `<hero-detail>` component element.
@@ -1054,28 +1076,28 @@ figure.image-display
   ### Referencing a local template variable
 
   We can reference a local template variable on the same element, on a sibling element, or on
-  any of its child elements.
+  any child elements.
 
   Here are two other examples of creating and consuming a local template variable:
 +makeExample('template-syntax/ts/app/app.component.html', 'var-phone')(format=".")
 :marked
-  ### How it gets its value
-  The value assigned to the variable depends upon the context.
+  ### How a variable gets its value
+  The value assigned to a variable depends upon the context.
 
   When a directive is present on the element, as it is in the earlier NgFor `<hero-detail>` component example,
   the directive sets the value.  Accordingly, the `NgFor` directive
   sets the `hero` variable to a hero item from the `heroes` array.
 
-  When there is no directive present, as in phone and fax examples,
-  Angular sets the variable to the element on which it was defined.
+  When no directive is present, as in phone and fax examples,
+  Angular sets the variable's value to the element on which it was defined.
   We defined these variables on the `input` elements.
   We’re passing those `input` element objects across to the
-  button elements where they become arguments to the `call()` methods in the event bindings.
+  button elements, where they're used in arguments to the `call` methods in the event bindings.
 
   ### NgForm and local template variables
-  Let's look at one final example, a Form, the poster child for local template variables.
+  Let's look at one final example: a form, the poster child for local template variables.
 
-  The HTML for a form can be quite involved as we saw in the [Forms](forms.html) chapter.
+  The HTML for a form can be quite involved, as we saw in the [Forms](forms.html) chapter.
   The following is a *simplified* example &mdash; and it's not simple at all.
 +makeExample('template-syntax/ts/app/app.component.html', 'var-form')
 :marked
@@ -1088,7 +1110,7 @@ figure.image-display
   It would be the [HTMLFormElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement)
   if Angular hadn't taken it over.
   It's actually `ngForm`, a reference to the Angular built-in `NgForm` directive that wraps the native `HTMLFormElement`
-  and endows it with additional super powers such as the ability to
+  and endows it with additional superpowers such as the ability to
   track the validity of user input.
 
   This explains how we can disable the submit button by checking `theForm.form.valid`
@@ -1097,81 +1119,84 @@ figure.image-display
 <a id="inputs-outputs"></a>
 .l-main-section
 :marked
-  ## Input and Output Properties
-  We can only bind to **target directive** properties that are either **inputs** or **outputs**.
-  
-.alert.is-important
-  :marked
-    A *component is a directive*. We use the terms "directive" and "component" interchangeably.
+  ## Input and output properties
+  So far, we’ve focused mainly on binding to component members within template expressions and statements
+  that appear on the *right side of the binding declaration*.
+  A member in that position is a data binding **source**.
 
+  This section concentrates on binding to **targets**, which are directive
+  properties on the *left side of the binding declaration*.
+  These directive properties must be declared as **inputs** or **outputs**.
+
+.alert.is-important
+  :markdown
+    Remember: All **components** are **directives**.
+
+:marked
 .l-sub-section
   :marked
     We're drawing a sharp distinction between a data binding **target** and a data binding **source**.
 
-    The *target* of a binding is to the *left* of the (=).
-    The *source* is on the *right* of the (=).
-    
+    The *target* of a binding is to the *left* of the `=`.
+    The *source* is on the *right* of the `=`.
+
     The *target* of a binding is the property or event inside the binding punctuation: `[]`, `()` or `[()]`.
-    The *source* is either inside quotes (") or within an interpolation (`{}`).
+    The *source* is either inside quotes (`" "`) or within an interpolation (`{}`).
 
-    Every member of a **source** directive or component is automatically available for binding.
-    We don't have to do anything special to access a component member in a template expression or statement.
+    Every member of a **source** directive is automatically available for binding.
+    We don't have to do anything special to access a directive member in a template expression or statement.
 
-    We have *limited* access to members of a **target** directive or component.
+    We have *limited* access to members of a **target** directive.
     We can only bind to properties that are explicitly identified as *inputs* and *outputs*.
 :marked
-  In this chapter we’ve focused mainly on binding to component members within template expressions and statements
-  that appear on the *right side of the binding declaration*.
-  A member in that position is a binding “data source”.
-
-  In the following example, `iconUrl` and `onSave` are members of the `AppComponent`
-  referenced within quoted syntax to the right of the (=).
+  In the following example, `iconUrl` and `onSave` are members of a component
+  that are referenced within quoted syntax to the right of the `=`.
 +makeExample('template-syntax/ts/app/app.component.html', 'io-1')(format=".")
 :marked
-  They are *neither inputs nor outputs* of `AppComponent`. They are data sources for their bindings.
+  They are *neither inputs nor outputs* of the component. They are data sources for their bindings.
 
-  Now look at the `HeroDetailComponent` when it is the **target of a binding**.
+  Now look at `HeroDetailComponent` when it is the **target of a binding**.
 +makeExample('template-syntax/ts/app/app.component.html', 'io-2')(format=".")
 :marked
-  Both `HeroDetail.hero` and `HeroDetail.deleted` are on the **left side** of binding declarations.
-  `HeroDetail.hero` is inside brackets; it is the target of a Property Binding. 
-  `HeroDetail.deleted` is inside parentheses; it is the target of an Event Binding.
-  
+  Both `HeroDetailComponent.hero` and `HeroDetailComponent.deleted` are on the **left side** of binding declarations.
+  `HeroDetailComponent.hero` is inside brackets; it is the target of a property binding.
+  `HeroDetailComponent.deleted` is inside parentheses; it is the target of an event binding.
+
   ### Declaring input and output properties
   Target properties must be explicitly marked as inputs or outputs.
-  
-  When we peek inside `HeroDetailComponent` we see that these properties are marked
+
+  When we peek inside `HeroDetailComponent`, we see that these properties are marked
   with decorators as input and output properties.
 +makeExample('template-syntax/ts/app/hero-detail.component.ts', 'input-output-1')(format=".")
 :marked
 .l-sub-section
   :marked
-    Alternatively, we can identify them in the `inputs` and `outputs` arrays
-    of the directive metadata as seen in this example:
+    Alternatively, we can identify members in the `inputs` and `outputs` arrays
+    of the directive metadata, as in this example:
   +makeExample('template-syntax/ts/app/hero-detail.component.ts', 'input-output-2')(format=".")
   <br>
   :marked
-    We can specify an input/output property with a decorator or in one the metadata arrays.
+    We can specify an input/output property either with a decorator or in a metadata array.
     Don't do both!
 :marked
-  ### Input or Output?
+  ### Input or output?
 
   *Input* properties usually receive data values.
-  *Output* properties expose event producers (e.g, an `EventEmitter`).
-  
-  The terms "input" and "output" reflect the perspective of the target directive.
-  
-  `HeroDetail.hero` is an ***input*** property from the perspective of `HeroDetailComponent`
-  because data flow  *into* that property from a template binding expression.
+  *Output* properties expose event producers, such as `EventEmitter` objects.
 
-  `HeroDetail.deleted` is an ***output*** property from the perspective of `HeroDetailComponent`
+  The terms _input_ and _output_ reflect the perspective of the target directive.
+
+  `HeroDetailComponent.hero` is an **input** property from the perspective of `HeroDetailComponent`
+  because data flows *into* that property from a template binding expression.
+
+  `HeroDetailComponent.deleted` is an **output** property from the perspective of `HeroDetailComponent`
   because events stream *out* of that property and toward the handler in a template binding statement.
-  
+
   ### Aliasing input/output properties
 
   Sometimes we want the public name of an input/output property to be different from the internal name.
 
-  This is frequently the case with [Attribute Directives](attribute-directives.html).
+  This is frequently the case with [attribute directives](attribute-directives.html).
   Directive consumers expect to bind to the name of the directive.
   For example, when we apply a directive with a `myClick` selector to a `<div>` tag,
   we expect to bind to an event property that is also called `myClick`.
@@ -1181,55 +1206,55 @@ figure.image-display
   The directive name rarely describes what the property does.
   The `myClick` directive name is not a good name for a property that emits click messages.
 
-  Fortunately, we can have a public name for the property that meets conventional expectations
+  Fortunately, we can have a public name for the property that meets conventional expectations,
   while using a different name internally.
-  In the example immediately above, we are actually binding *through the* `myClick` *alias* to 
+  In the example immediately above, we are actually binding *through the* `myClick` *alias* to
   the directive's own `clicks` property.
-  
-  We can specify the alias for the property name by passing it into the input/output decorator like this: 
+
+  We can specify the alias for the property name by passing it into the input/output decorator like this:
 
 +makeExample('template-syntax/ts/app/my-click.directive.ts', 'my-click-output-1')(format=".")
 :marked
 
-  
+
 .l-sub-section
   :marked
     We can also alias property names in the `inputs` and `outputs` arrays.
-    We write a *colon-delimited* (:) string with
+    We write a colon-delimited (`:`) string with
     the directive property name on the *left* and the public alias on the *right*:
   +makeExample('template-syntax/ts/app/my-click.directive.ts', 'my-click-output-2')(format=".")
 
 <a id="expression-operators"></a>
 .l-main-section
 :marked
-  ## Template Expression Operators
-  The template expression language employs a subset of JavaScript syntax supplemented with some special operators
-  for specific scenarios. We'll cover two of them, "pipe" and "Elvis".
+  ## Template expression operators
+  The template expression language employs a subset of JavaScript syntax supplemented with a few special operators
+  for specific scenarios. We'll cover two of these operators: _pipe_ and _Elvis_.
 
   <a id="pipe"></a>
-  ### The Pipe Operator ( | )
-  The result of an expression may require some transformation before we’re ready to use it in a binding.  For example, we may wish to display a number as a currency, force text to uppercase, or filter a list and sort it.
+  ### The pipe operator ( | )
+  The result of an expression might require some transformation before we’re ready to use it in a binding.  For example, we might want to display a number as a currency, force text to uppercase, or filter a list and sort it.
 
-  Angular [Pipes](./pipes.html) are a good choice for small transformations such as these.
+  Angular [pipes](./pipes.html) are a good choice for small transformations such as these.
   Pipes are simple functions that accept an input value and return a transformed value.
-  They are easy to apply within template expressions using the **pipe operator ( | )**:
+  They're easy to apply within template expressions, using the **pipe operator (`|`)**:
 +makeExample('template-syntax/ts/app/app.component.html', 'pipes-1')(format=".")
 :marked
   The pipe operator passes the result of an expression on the left to a pipe function on the right.
 
-  We can chain expressions through multiple pipes
+  We can chain expressions through multiple pipes:
 +makeExample('template-syntax/ts/app/app.component.html', 'pipes-2')(format=".")
 :marked
   And we can configure them too:
 +makeExample('template-syntax/ts/app/app.component.html', 'pipes-3')(format=".")
 :marked
-  The `json` pipe is particular helpful for debugging our bindings:
+  The `json` pipe is particularly helpful for debugging our bindings:
 +makeExample('template-syntax/ts/app/app.component.html', 'pipes-json')(format=".")
 :marked
   <a id="elvis"></a>
-  ### The Elvis Operator ( ?. ) and null property paths
+  ### The Elvis operator ( ?. ) and null property paths
 
-  The Angular **“Elvis” operator ( ?. )** is a fluent and convenient way to guard against null and undefined values in property paths.
+  The Angular **Elvis operator (`?.`)** is a fluent and convenient way to guard against null and undefined values in property paths.
   Here it is, protecting against a view render failure if the `currentHero` is null.
 +makeExample('template-syntax/ts/app/app.component.html', 'elvis-2')(format=".")
 :marked
@@ -1238,16 +1263,16 @@ figure.image-display
   What happens when the following data bound `title` property is null?
 +makeExample('template-syntax/ts/app/app.component.html', 'elvis-1')(format=".")
 :marked
-  The view still renders but the displayed value is blank; we see only "`The title is`" with nothing after it.
+  The view still renders but the displayed value is blank; we see only "The title is" with nothing after it.
   That is reasonable behavior. At least the app doesn't crash.
 
-  Suppose the template expression involves a property path as in this next example
+  Suppose the template expression involves a property path, as in this next example
   where we’re displaying the `firstName` of a null hero.
 
 code-example(format="" language="html").
   The null hero's name is {{nullHero.firstName}}
 :marked
-  JavaScript throws a null reference error and so does Angular:
+  JavaScript throws a null reference error, and so does Angular:
 code-example(format="" language="html").
   TypeError: Cannot read property 'firstName' of null in [null]
 :marked
@@ -1261,32 +1286,29 @@ code-example(format="" language="html").
   On the other hand, null values in the property path may be OK from time to time,
   especially when we know the data will arrive eventually.
 
-  While we wait for data, the view should render without complaint and
+  While we wait for data, the view should render without complaint, and
   the null property path should display as blank just as the `title` property does.
 
   Unfortunately, our app crashes when the `currentHero` is null.
 
-  We could code around that problem with [NgIf](#ngIf)
+  We could code around that problem with [NgIf](#ngIf).
 +makeExample('template-syntax/ts/app/app.component.html', 'elvis-4')(format=".")
 :marked
   Or we could try to chain parts of the property path with `&&`, knowing that the expression bails out
   when it encounters the first null.
 +makeExample('template-syntax/ts/app/app.component.html', 'elvis-5')(format=".")
 :marked
-  These approaches have merit but they can be cumbersome, especially if the property path is long.
+  These approaches have merit but can be cumbersome, especially if the property path is long.
   Imagine guarding against a null somewhere in a long property path such as `a.b.c.d`.
 
-  The Angular  **“Elvis” operator ( ?. )** is a more fluent and convenient way to guard against nulls in property paths.
+  The Angular Elvis operator (`?.`) is a more fluent and convenient way to guard against nulls in property paths.
   The expression bails out when it hits the first null value.
-  The display is blank but the app keeps rolling and there are no errors.
+  The display is blank, but the app keeps rolling without errors.
 +makeExample('template-syntax/ts/app/app.component.html', 'elvis-6')(format=".")
 :marked
-  It works perfectly with long property paths too:
-  ```
-  a?.b?.c?.d
-  ```
+  It works perfectly with long property paths such as `a?.b?.c?.d`.
 
 .l-main-section
 :marked
-  ## What Next?
-  We’ve completed our survey of Template Syntax. Time to put that knowledge to work as we write our own Components and Directives.
+  ## Summary
+  We’ve completed our survey of template syntax. Now it's time to put that knowledge to work as we write our own components and directives.
diff --git a/public/resources/images/devguide/template-syntax/ng-model-anim.gif b/public/resources/images/devguide/template-syntax/ng-model-anim.gif
index f27387bfbc..ed5da31712 100644
Binary files a/public/resources/images/devguide/template-syntax/ng-model-anim.gif and b/public/resources/images/devguide/template-syntax/ng-model-anim.gif differ