anchor.diff:    We've seen almost everything here before. A few things are new or bear repeating.
   
     ### *newHero* template variable
  -  
  +
     The *newHero* template variable refers to the `<input>` element.
  -  
  +
     We can access `newHero` from any sibling or child of the `<input>` element.
  -  When the user clicks the button, we don't need a fancy css selector to
  +  When the user clicks the button, we don't need a fancy CSS selector to
     track down the textbox and extract its value.
  -  
  +
     ### Extract the input box *value*
  -  We could have passed the `newHero` into the component's `addHero()` method. 
  -  
  +  We could have passed the `newHero` into the component's `addHero()` method.
  +
     But that would require `addHero` to pick its way through the `<input>` DOM element,
     something we learned to dislike in our first try at a [*KeyupComponent*](#keyup1).
  -  
  +
     Instead, we grab the input box *value* and pass *that* to `addHero()`.
     The component knows nothing about HTML or DOM which is the way we like it.
   
     ### Don't let template expressions be complex
  -  We bound `(blur)` to *two* JavaScript statements. 
  -  
  -  We like the first one that calls `addHero`. 
  +  We bound `(blur)` to *two* JavaScript statements.
  +
  +  We like the first one that calls `addHero`.
     We do not like the second one that assigns an empty string to the input box value.
  -  
  +
     We did it for a good reason. We have to clear the input box after adding the new hero to the list.
     The component has no way to do that itself &mdash; because it has no access to the
     input box (our design choice).
  -  
  -  Although it *works*, we are rightly wary of JavaScript in HTML. 
  +
  +  Although it *works*, we are rightly wary of JavaScript in HTML.
     Template expressions 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?
  -  
  +
     There should be a better third way. And there is as we'll see when we learn about `NgModel` in the [Forms](forms.html) chapter.
   .l-main-section
   :marked
     ## Source code
  -  
  +
     Here is all the code we talked about in this chapter.
   +makeTabs(`
     user-input/ts/app/click-me.component.ts,
  
positive.code:   Only then do we update the component's `values` property ...
    inside the event expression rather than in the component ...
    because we *can* ... even if it is a dubious practice.
  +makeExample('user-input/ts/app/keyup.components.ts', 'key-up-component-3' ,'app/keyup.components.ts (v3)')  
  :marked
    Here's how it works.
  figure.image-display
  
negative.code:   of JavaScript with 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.
    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:
  
  