docs(user-input): replace "expression" w/ "statement" in TS doc

closes #714

public/docs/ts/latest/guide/user-input.jade

@@ -14,19 +14,19 @@ include ../../../../_includes/_util-fns
   We can use [Angular event bindings](./template-syntax.html#event-binding)
   to respond to [any DOM event](https://developer.mozilla.org/en-US/docs/Web/Events).
 
-  The syntax is simple. We assign a template expression to the DOM event name, surrounded in parentheses.
+  The syntax is simple. We surround the DOM event name in parentheses and assign a quoted template statement to it.
   As an example, here's an event binding that implements a click handler:
 +makeExample('user-input/ts/app/click-me.component.ts', 'click-me-button')(format=".", language="html")
 
 <a id="click"></a>
 :marked
   The `(click)` to the left of the equal sign identifies the button's click event as the **target of the binding**.
-  The text within quotes on the right is the **template expression** in which we
-  respond to the click event by calling the component's `onClickMe` method. A [template expression](./template-syntax.html#template-expressions) is a subset
-  of JavaScript with a few added tricks.
+  The text within quotes on the right is the **template statement** in which we
+  respond to the click event by calling the component's `onClickMe` method. A [template statement](./template-syntax.html#template-statements) is a subset
+  of JavaScript with restrictions and a few added tricks.
 
-  When writing a binding we must be aware of a template expression's **execution context**.
-  The identifiers appearing within an expression belong to a specific context object.
+  When writing a binding we must be aware of a template statement's **execution context**.
+  The identifiers appearing within an statement belong to a specific context object.
   That object is usually the Angular component that controls the template  ... which it definitely is
   in this case because that snippet of HTML belongs to the following component:
 
@@ -112,8 +112,8 @@ figure.image-display
     Angular only updates the bindings (and therefore the screen)
     if we do something in response to asynchronous events such as keystrokes.
 
-    That's why we bind the `keyup` event to an expression that does ... well, nothing.
-    We're binding to the number 0, the shortest expression we can think of.
+    That's why we bind the `keyup` event to an statement that does ... well, nothing.
+    We're binding to the number 0, the shortest statement we can think of.
     That is all it takes to keep Angular happy. We said it would be clever!
 :marked
   That local template variable is intriguing. It's clearly easier to get to the textbox with that
@@ -131,14 +131,14 @@ figure.image-display
   ## Key event filtering (with `key.enter`)
   Perhaps we don't care about every keystroke.
   Maybe we're only interested in the input box value when the user presses Enter, and we'd like to ignore all other keys.
-  When we bind to the `(keyup)` event, our event handling expression hears *every keystroke*.
+  When we bind to the `(keyup)` event, our event handling statement hears *every keystroke*.
   We could filter the keys first, examining every `$event.keyCode`, and update the `values` property only if the key is Enter.
 
   Angular can filter the key events for us. Angular has a special syntax for keyboard events.
   We can listen for just the Enter key by binding to Angular's `keyup.enter` pseudo-event.
 
   Only then do we update the component's `values` property. (In this example,
-  the update happens inside the event expression. A better practice
+  the update happens inside the event binding statement. A better practice
   would be to put the update code in the component.)
 +makeExample('user-input/ts/app/keyup.components.ts', 'key-up-component-3' ,'app/keyup.components.ts (v3)')(format=".")
 :marked
@@ -198,7 +198,7 @@ figure.image-display
   Instead, we grab the input box *value* and pass *that* to `addHero`.
   The component knows nothing about HTML or the DOM, which is the way we like it.
 
-  ### Keep template expressions simple
+  ### Keep template statements simple
   We bound `(blur)` to *two* JavaScript statements.
 
   We like the first one, which calls `addHero`.
@@ -209,7 +209,7 @@ figure.image-display
   input box (our design choice).
 
   Although the example *works*, we are rightly wary of JavaScript in HTML.
-  Template expressions are powerful. We're supposed to use them responsibly.
+  Template statements are powerful. We're supposed to use them responsibly.
   Complex JavaScript in HTML is irresponsible.
 
   Should we reconsider our reluctance to pass the input box into the component?