docs - various doc fixes

docs/content/guide/dev_guide.compiler.extending_compiler.ngdoc

@@ -3,61 +3,54 @@
 @name Developer Guide: Angular HTML Compiler: Extending the Angular Compiler
 @description
 
-
 Let's say that we want to create a new DOM element called `<my:greeter/>` that displays a greeting.
 We want this HTML source:
 
-
 <pre>
-<div ng:init="salutation='Hello'; name='World'">
-<my:greeter salutation="salutation" name="name"/>
-</div>
+   <div ng:init="s='Hello'; n='World'">
+      <my:greeter salutation="s" name="n"/>
+  </div>
 </pre>
 
-
 to produce this DOM:
 
-
 <pre>
-<div ng:init="salutation='Hello'; name='World'">
-<my:greeter salutation="salutation" name="name"/>
+<div ng:init="s='Hello'; n='World'">
+<my:greeter salutation="s" name="n"/>
   <span class="salutation">Hello</span>
   <span class="name">World</span>!
 </my:greeter>
 </div>
 </pre>
 
-
 That is, the new `<my:greeter/>` tag's `salutation` and `name` attributes should be transformed by
 the compiler such that two `<span>` tags display the values of the attributes, with CSS classes
 applied to the output.
 
-
 The following code snippet shows how to write a following widget definition that will be processed
 by the compiler. Note that you have to declare the {@link dev_guide.bootstrap namespace} `my` in
 the page:
 
-
 <pre>
 angular.widget('my:greeter', function(compileElement){
-var compiler = this;
-compileElement.css('display', 'block');
-var salutationExp = compileElement.attr('salutation');
-var nameExp = compileElement.attr('name');
-return function(linkElement){
-  var salutationSpan = angular.element('<span class="salutation"></span');
-  var nameSpan = angular.element('<span class="name"></span>');
-  linkElement.append(salutationSpan);
-  linkElement.append(compiler.text(' '));
-  linkElement.append(nameSpan);
-  linkElement.append(compiler.text('!'));
-  this.$watch(salutationExp, function(value){
-    salutationSpan.text(value);
-  });
-  this.$watch(nameExp, function(value){
-  nameSpan.text(value);
-  });
-};
+  var compiler = this;
+  compileElement.css('display', 'block');
+  var salutationExp = compileElement.attr('salutation');
+  var nameExp = compileElement.attr('name');
+  return function(linkElement){
+    var salutationSpan = angular.element('<span class="salutation"></span');
+    var nameSpan = angular.element('<span class="name"></span>');
+    linkElement.append(salutationSpan);
+    linkElement.append(compiler.text(' '));
+    linkElement.append(nameSpan);
+    linkElement.append(compiler.text('!'));
+    this.$watch(salutationExp, function(value){
+      salutationSpan.text(value);
+     });
+    this.$watch(nameExp, function(value){
+    nameSpan.text(value);
+    });
+  };
 });
 </pre>
 

docs/content/guide/dev_guide.unit-testing.ngdoc

@@ -150,13 +150,11 @@ function MyClass(xhr) {
 }
 </pre>
 
-
-This is the proferred way since the code makes no assumptions as to where the `xhr` comes from,
-rather that who-ever crated the class was responsible for passing it in. Since the creator of the
-class should be different code the the user of the class, it separates the responsibility of
+This is the preferred way since the code makes no assumptions as to where the `xhr` comes from,
+rather that whoever created the class was responsible for passing it in. Since the creator of the
+class should be different code than the user of the class, it separates the responsibility of
 creation from the logic, and that is what dependency-injection is in a nutshell.
 
-
 The class above is very testable, since in the test we can write:
 <pre>
 function xhrMock(args) {...}
@@ -165,21 +163,16 @@ myClass.doWork();
 // assert that xhrMock got called with the right arguments
 </pre>
 
-
 Notice that no global variables were harmed in the writing of this test.
 
-
-Angular comes with {@link dev_guide.di dependency-injection} built in which makes the right thin
-the easy thing to do, but you still need to do it if you wish to take advantage of the testability
-story.
-
+Angular comes with {@link dev_guide.di dependency-injection} built in which makes the right thing
+easy to do, but you still need to do it if you wish to take advantage of the testability story.
 
 ## Controllers
 What makes each application unique is its logic, which is what we would like to test. If the logic
 for your application is mixed in with DOM manipulation, it will be hard to test as in the example
 below:
 
-
 <pre>
 function PasswordController(){
   // get references to DOM elements

docs/content/tutorial/step_09.ngdoc

@@ -88,46 +88,34 @@ describe('checkmark filter', function() {
 })
 </pre>
 
-
 To run the unit tests, execute the `./scripts/test.sh` script and you should see the following
 output.
 
-
         Chrome: Runner reset.
         ....
         Total 4 tests (Passed: 4; Fails: 0; Errors: 0) (3.00 ms)
           Chrome 11.0.696.57 Mac OS: Run 4 tests (Passed: 4; Fails: 0; Errors 0) (3.00 ms)
 
 
-
-
 # Experiments
 
-
 * Let's experiment with some of the {@link api/angular.filter built-in angular filters} and add the
 following bindings to `index.html`:
   * `{{ "lower cap string" | uppercase }}`
   * `{{ {foo: "bar", baz: 23} | json }}`
   * `{{ 1304375948024 | date }}`
-  * `{{ 1304375948024 | date:"'MM/dd/yyyy @ h:mma" }}`
-
+  * `{{ 1304375948024 | date:"MM/dd/yyyy @ h:mma" }}`
 
 *  We can also create a model with an input element, and combine it with a filtered binding. Add
 the following to index.html:
 
-
         <input name="userInput"> Uppercased: {{ userInput | uppercase }}
 
 
-
-
 # Summary
 
-
 Now that you have learned how to write and test a custom filter, go to step 10 to learn how we can
 use angular to enhance the phone details page further.
 
 
-
-
 <ul doc:tutorial-nav="9"></ul>