docs: adjust page heading levels (#2813)

* docs: adjust page heading levels Only the page TOC should be at heading level 1. All other headings should start at level 2. This commit also removes duplicate headings, in continuation of #2796. (This fix is necessary to support an auto-TOC feature.)
2016-11-16 10:02:31 -08:00 · 2016-11-16 10:02:31 -08:00 · 061e50fa06
parent 31e0101020
commit 061e50fa06
13 changed files with 102 additions and 110 deletions
--- a/public/docs/ts/_cache/glossary.jade
+++ b/public/docs/ts/_cache/glossary.jade
@ -9,8 +9,6 @@ block includes
 - var _decoratorLink = '<a href="#' + _decorator + '">' + _decorator + '</a>'

 :marked
-  # Angular 2 Glossary
-
  Angular 2 has a vocabulary of its own.
  Most Angular 2 terms are everyday English words
  with a specific meaning within the Angular system.
--- a/public/docs/ts/_cache/guide/lifecycle-hooks.jade
+++ b/public/docs/ts/_cache/guide/lifecycle-hooks.jade
@ -3,9 +3,13 @@ block includes

 - var top="vertical-align:top"

+figure
+  img(src="/resources/images/devguide/lifecycle-hooks/hooks-in-sequence.png" alt="Us" align="left" style="width:200px; margin-left:-40px;margin-right:30px")
+
 :marked
-  # Component Lifecycle
-  A Component has a lifecycle managed by Angular itself. Angular creates it, renders it, creates and renders its children,
+  A component has a lifecycle managed by Angular itself.
+  
+  Angular creates it, renders it, creates and renders its children,
  checks it when its data-bound properties change, and destroys it before removing it from the DOM.

  Angular offers **component lifecycle hooks**
--- a/public/docs/ts/_cache/guide/server-communication.jade
+++ b/public/docs/ts/_cache/guide/server-communication.jade
@ -38,7 +38,7 @@ block includes
  
 .l-main-section
 :marked
-  # Demos
+  ## Demos

  This chapter describes server communication with the help of the following demos

@ -139,7 +139,7 @@ figure.image-display
 a#oninit
 a#HeroListComponent
 :marked
-  ## The *HeroListComponent* class
+  ### The *HeroListComponent* class
  Here's the component class:
 +makeExample('server-communication/ts/app/toh/hero-list.component.ts','component', 'app/toh/hero-list.component.ts (class)')  
 :marked
@ -219,7 +219,7 @@ a#HeroService

  .l-main-section
  :marked
-    # RxJS Library
+    ## RxJS Library
    [RxJS](https://github.com/ReactiveX/RxJS) ("Reactive Extensions") is a 3rd party library, endorsed by Angular,
    that implements the [*asynchronous observable*](https://www.youtube.com/watch?v=UHI0AzD_WfY "Rob Wormald on observables") pattern.

--- a/public/docs/ts/latest/cookbook/index.jade
+++ b/public/docs/ts/latest/cookbook/index.jade
@ -1,8 +1,6 @@
 include ../_util-fns 

 :marked
-  # Angular Cookbook
-  
  The *Cookbook* offers answers to common implementation questions.
  
  Each cookbook chapter is a collection of recipes focused on a particular Angular feature or application challenge
--- a/public/docs/ts/latest/cookbook/ngmodule-faq.jade
+++ b/public/docs/ts/latest/cookbook/ngmodule-faq.jade
@ -2,8 +2,6 @@ block includes
  include ../_util-fns

 :marked
-  # FAQs
-
  **Angular Modules** help organize an application into cohesive blocks of functionality.

  The [Angular Modules chapter](../guide/ngmodule.html) covers the concepts and takes you step by step
--- a/public/docs/ts/latest/glossary.jade
+++ b/public/docs/ts/latest/glossary.jade
@ -9,8 +9,6 @@ block includes
 - var _decoratorLink = '<a href="#' + _decorator + '">' + _decorator + '</a>'

 :marked
-  # Angular Glossary
-
  Angular has a vocabulary of its own.
  Most Angular terms are everyday English words
  with a specific meaning within the Angular system.
--- a/public/docs/ts/latest/guide/browser-support.jade
+++ b/public/docs/ts/latest/guide/browser-support.jade
@ -3,7 +3,6 @@ block includes
  - var _at_angular = '@angular'

 :marked
-  # Browser support #  
  Angular supports most recent browsers. This includes the following specific versions:

 table
@ -61,7 +60,7 @@ table
    <a href="https://www.browserstack.com" target="_blank">Browserstack</a>.

 :marked
-  # Polyfills #
+  ## Polyfills #
  Angular is built on the latest standards of the web platform.
  Targeting such a wide range of browsers is challenging because they do not support all features of modern browsers.
  
@ -81,7 +80,7 @@ table
    Note that polyfills cannot magically transform an old, slow browser into a modern, fast one.
  
 :marked
-  ## Mandatory polyfills ##
+  ### Mandatory polyfills ##
  These are the polyfills required to run an Angular application on each supported browser:
  
 table
@ -103,7 +102,7 @@ table
        [ES6<br>classList](#classlist)

 :marked
-  ## Optional browser features to polyfill ##
+  ### Optional browser features to polyfill ##
  Some features of Angular may require additional polyfills.
  
  For example, the animations library relies on the standard web animation API, which is only available in Chrome and Firefox today.
@ -156,7 +155,7 @@ table
    td IE 9

 :marked
-  ## Suggested polyfills ##
+  ### Suggested polyfills ##
  Below are the polyfills which are used to test the framework itself. They are a good starting point for an application. 

 table
--- a/public/docs/ts/latest/guide/change-log.jade
+++ b/public/docs/ts/latest/guide/change-log.jade
@ -2,8 +2,6 @@ block includes
  include ../_util-fns

 :marked
-  # Documentation Change Log
-
  The Angular documentation is a living document with continuous improvements.
  This log calls attention to recent significant changes.

--- a/public/docs/ts/latest/guide/index.jade
+++ b/public/docs/ts/latest/guide/index.jade
@ -10,7 +10,7 @@ figure
  <br style="clear:left;">

 :marked
-  # Organization
+  ## Organization

  The documentation is divided into major thematic sections, each
  a collection of pages devoted to that theme.
@ -53,7 +53,7 @@ table(width="100%")
      :marked
        Recipes for specific application challenges, mostly code snippets with a minimum of exposition.
 :marked
-  # Learning path
+  ## Learning path
  You don't have to read the guide straight through.  Most pages stand on their own.

  For those new to Angular, the recommended learning path runs through the *Guide* section:
@ -81,7 +81,7 @@ table(width="100%")
  After reading the above sections, you can skip to any other pages on this site.

 :marked
-  # Code samples
+  ## Code samples

  Each page includes code snippets that you can reuse in your applications.
  These snippets are excerpts from a sample application that accompanies the page.
@ -98,7 +98,7 @@ block example-links
  The rest of the pages highlight key points in code rather than explain each step necessary to build the sample.
  You can always get the full source through the #{_liveLink}.

-  # Reference pages
+  ## Reference pages

  The [Cheat Sheet](cheatsheet.html) lists Angular syntax for common scenarios.

@ -106,7 +106,7 @@ block example-links

  The [API Reference](../api/) is the authority on every public-facing member of the Angular libraries.

-  # Feedback
+  ## Feedback

  We welcome feedback! 

--- a/public/docs/ts/latest/guide/lifecycle-hooks.jade
+++ b/public/docs/ts/latest/guide/lifecycle-hooks.jade
@ -3,10 +3,9 @@ block includes

 - var top="vertical-align:top"

-:marked
-  # Component Lifecycle
 figure
  img(src="/resources/images/devguide/lifecycle-hooks/hooks-in-sequence.png" alt="Us" align="left" style="width:200px; margin-left:-40px;margin-right:30px")
+
 :marked
  A component has a lifecycle managed by Angular itself. 
  
--- a/public/docs/ts/latest/guide/server-communication.jade
+++ b/public/docs/ts/latest/guide/server-communication.jade
@ -102,7 +102,7 @@ block http-providers
    Loading its module now saves time.
 .l-main-section#http-client
 :marked
-  # The Tour of Heroes HTTP client demo
+  ## The Tour of Heroes HTTP client demo

  The first demo is a mini-version of the [tutorial](../tutorial)'s "Tour of Heroes" (ToH) application.
  This version gets some heroes from the server, displays them in a list, lets the user add new heroes, and saves them to the server.
@ -128,7 +128,7 @@ figure.image-display
 a#oninit
 a#HeroListComponent
 :marked
-  ## The *HeroListComponent* class
+  ### The *HeroListComponent* class
  Here's the component class:
 +makeExample('server-communication/ts/app/toh/hero-list.component.ts','component', 'app/toh/hero-list.component.ts (class)')
 :marked
@ -205,7 +205,7 @@ a#HeroService

  .l-main-section
  :marked
-    # RxJS library
+    ## RxJS library
    [RxJS](https://github.com/ReactiveX/RxJS) ("Reactive Extensions") is a 3rd party library, endorsed by Angular,
    that implements the [*asynchronous observable*](https://www.youtube.com/watch?v=UHI0AzD_WfY "Rob Wormald on observables") pattern.

--- a/public/docs/ts/latest/guide/testing.jade
+++ b/public/docs/ts/latest/guide/testing.jade
@ -80,7 +80,7 @@ block includes
 :marked
  It’s a big agenda. Fortunately, you can learn a little bit at a time and put each lesson to use.

-  # Live examples
+  ## Live examples
  The chapter sample code is available as live examples for inspection, experiment, and download.
  
  * <live-example>The sample application</live-example>
@ -92,7 +92,7 @@ a(href="#top").to-top Back to top
 .l-hr
 #testing-intro
 :marked
-  # Introduction to Angular Testing
+  ## Introduction to Angular Testing

  You write tests to explore and confirm the behavior of the application.

@ -107,13 +107,13 @@ a(href="#top").to-top Back to top

  <!-- TODO
  :marked
-  ## Learn more
+  ### Learn more
  Learn more about basic Jasmine testing here
  [Resources TBD](./#)
  -->


-  ## Tools and Technologies
+  ### Tools and Technologies

  You can write and run Angular tests with a variety of tools and technologies. 
  This chapter describes specific choices that are known to work well.
@ -160,7 +160,7 @@ table(width="100%")
 .l-hr
 #setup
 :marked
-  # Setup
+  ## Setup

  Many think writing tests is fun. 
  Few enjoy setting up the test environment.
@ -253,7 +253,7 @@ table(width="100%")
 .l-hr
 #1st-karma-test
 :marked
-  # The first karma test
+  ## The first karma test

  Start with a simple test to make sure the setup works properly.

@ -273,7 +273,7 @@ table(width="100%")
  Add the following code to `app/1st.spec.ts`.
 +makeExample('testing/ts/app/1st.spec.ts', '', 'app/1st.spec.ts')(format='.')
 :marked
-  ## Run karma
+  ### Run karma
  Compile and run it in karma from the command line with this command:
 code-example(format="." language="bash").
  npm test
@ -330,7 +330,7 @@ code-example(format="." language="bash").
    The console log can be quite long. Keep your eye on the last line.
    It says `SUCCESS` when all is well.
 :marked
-  ## Test debugging
+  ### Test debugging
  
  Debug specs in the browser in the same way you debug an application.

@ -350,7 +350,7 @@ a(href="#top").to-top Back to top
 .l-hr
 #atu-intro
 :marked
-  # Introduction to the Angular Testing Utilities
+  ## Introduction to the Angular Testing Utilities

  Many tests explore how applications classes interact with Angular and the DOM while under Angular's control.

@ -416,7 +416,7 @@ a(href="#top").to-top Back to top

 #sample-app
 :marked
-  # The sample application and its tests
+  ## The sample application and its tests

  This chapter tests a cut-down version of the _Tour of Heroes_ [tutorial app](../tutorial).
  
@ -437,7 +437,7 @@ a(href="#top").to-top Back to top

 #simple-component-test
 :marked
-  # Test a component
+  ## Test a component

  The top of the screen displays application title, presented by the `BannerComponent` in `app/banner.component.ts`.
 +makeExample('testing/ts/app/banner.component.ts', '', 'app/banner.component.ts')(format='.')
@ -568,7 +568,7 @@ a(href="#top").to-top Back to top

 #component-with-dependency
 :marked
-  # Test a component with a dependency
+  ## Test a component with a dependency
  Components often have service dependencies.
  The `WelcomeComponent` displays a welcome message to the logged in user.
  It knows who the user is based on a property of the injected `UserService`:
@ -584,7 +584,7 @@ a(href="#top").to-top Back to top
  
 #service-test-doubles 
 :marked
-  ## Provide service test doubles
+  ### Provide service test doubles

  A _component-under-test_ doesn't have to be injected with real services. 
  In fact, it is usually better if they are test doubles (stubs, fakes, spies, or mocks).
@ -603,7 +603,7 @@ a(href="#top").to-top Back to top

 #get-injected-service
 :marked
-  ## Get injected services
+  ### Get injected services
  The tests need access to the (stub) `UserService` injected into the `WelcomeComponent`.

  Angular has a hierarchical injection system.
@ -667,7 +667,7 @@ a(href="#top").to-top Back to top

 #component-with-async-service
 :marked
-  # Test a component with an async service
+  ## Test a component with an async service
  Many services return values asynchronously. 
  Most data services make an HTTP request to a remote server and the response is necessarily asynchronous.

@ -824,7 +824,7 @@ a(href="#top").to-top Back to top

 #component-with-external-template
 :marked
-  # Test a component with an external template
+  ## Test a component with an external template
  The `TestBed.createComponent` is a synchronous method. 
  It assumes that everything it could need is already in memory.

@ -852,7 +852,7 @@ a(href="#top").to-top Back to top

 #async-in-before-each
 :marked
-  ## The _async_ function in _beforeEach_
+  ### The _async_ function in _beforeEach_

  Notice the `async` call in the `beforeEach`, made necessary by the asynchronous `TestBed.compileComponents` method.
  The `async` function arranges for the tester's code to run in a special _async test zone_
@ -860,7 +860,7 @@ a(href="#top").to-top Back to top

 #compile-components
 :marked
-  ## _compileComponents_ 
+  ### _compileComponents_ 
  In this example, `TestBed.compileComponents` compiles one component, the `DashboardComponent`. 
  It's the only declared component in this testing module.

@ -890,7 +890,7 @@ a(href="#top").to-top Back to top

 #component-with-input-output
 :marked
-  # Test a component with inputs and outputs
+  ## Test a component with inputs and outputs
  A component with inputs and outputs typically appears inside the view template of a host component.
  The host uses a property binding to set the input property and uses an event binding to
  listen to events raised by the output property.
@ -930,7 +930,7 @@ a(href="#top").to-top Back to top
  The immediate goal is to test the `DashboardHeroComponent`, not the `DashboardComponent`, and there's no need
  to work hard unnecessarily. Let's try the second and third options.

-  ## Test _DashboardHeroComponent_ stand-alone
+  ### Test _DashboardHeroComponent_ stand-alone

  Here's the spec file setup.
 +makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'setup', 'app/dashboard/dashboard-hero.component.spec.ts (setup)')(format='.')
@ -1014,7 +1014,7 @@ a(href="#top").to-top Back to top

 #component-inside-test-host
 :marked
-  # Test a component inside a test host component
+  ## Test a component inside a test host component

  In the previous approach the tests themselves played the role of the host `DashboardComponent`.
  A nagging suspicion remains. 
@ -1058,7 +1058,7 @@ a(href="#top").to-top Back to top

 #routed-component
 :marked
-  # Test a routed component
+  ## Test a routed component

  Testing the actual `DashboardComponent` seemed daunting because it injects the `Router`.
 +makeExample('testing/ts/app/dashboard/dashboard.component.ts', 'ctor', 'app/dashboard/dashboard.component.ts (constructor)')(format='.')
@ -1084,7 +1084,7 @@ a(href="#top").to-top Back to top

 #inject
 :marked
-  ## The _inject_ function
+  ### The _inject_ function

  Notice the `inject` function in the second `it` argument.
 +makeExample('testing/ts/app/dashboard/dashboard.component.spec.ts', 'inject')(format='.')
@ -1126,7 +1126,7 @@ a(href="#top").to-top Back to top

 #routed-component-w-param
 :marked
-  # Test a routed component with parameters
+  ## Test a routed component with parameters
  
  Clicking a _Dashboard_ hero triggers navigation to `heroes/:id` where `:id`
  is a route parameter whose value is the `id` of the hero to edit. 
@ -1220,7 +1220,7 @@ a(href="#top").to-top Back to top

 #page-object
 :marked
-  # Use a _page_ object to simplify setup
+  ## Use a _page_ object to simplify setup

  The `HeroDetailComponent` is a simple view with a title, two hero fields, and two buttons.
 figure.image-display
@ -1257,7 +1257,7 @@ a(href="#top").to-top Back to top

 #import-module
 :marked
-  # Setup with module imports
+  ## Setup with module imports
  Earlier component tests configured the testing module with a few `declarations` like this:
 +makeExample('testing/ts/app/dashboard/dashboard-hero.component.spec.ts', 'compile-components', 'app/dashboard/dashboard-hero.component.spec.ts (config)')(format='.')
 :marked
@ -1311,7 +1311,7 @@ a(href="#top").to-top Back to top

 #component-override
 :marked
-  # Override component providers
+  ## Override component providers

  The `HeroDetailComponent` provides its own `HeroDetailService`.
 +makeExample('testing/ts/app/hero/hero-detail.component.ts', 'prototype', 'app/hero/hero-detail.component.ts (prototype)')(format='.')
@ -1401,7 +1401,7 @@ a(href="#top").to-top Back to top

 #router-outlet-component
 :marked
-  # Test a _RouterOutlet_ component
+  ## Test a _RouterOutlet_ component

  The `AppComponent` displays routed components in a `<router-outlet>`.
  It also displays a navigation bar with anchors and their `RouterLink` directives.
@ -1501,7 +1501,7 @@ a(href="#top").to-top Back to top

 #shallow-component-test
 :marked
-  # "Shallow component tests" with *NO\_ERRORS\_SCHEMA*
+  ## "Shallow component tests" with *NO\_ERRORS\_SCHEMA*

  The [previous setup](#stub-component) declared the `BannerComponent` and stubbed two other components 
  for _no reason other than to avoid a compiler error_.
@ -1535,7 +1535,7 @@ a(href="#top").to-top Back to top

 #attribute-directive
 :marked
-  # Test an attribute directive
+  ## Test an attribute directive

  An _attribute directive_ modifies the behavior of an element, component or another directive.
  Its name reflects the way the directive is applied: as an attribute on a host element.
@ -1595,7 +1595,7 @@ a(href="#top").to-top Back to top

 #isolated-unit-tests
 :marked
-  # Isolated Unit Tests
+  ## Isolated Unit Tests

  Testing applications with the help of the Angular testing utilities is the main focus of this chapter.

@ -1624,7 +1624,7 @@ a(href="#top").to-top Back to top

 #isolated-service-tests
 :marked
-  ## Services
+  ### Services
  Services are good candidates for isolated unit testing. 
  Here are some synchronous and asynchronous unit tests of the `FancyService` 
  written without assistance from Angular testing utilities.
@ -1648,7 +1648,7 @@ a(href="#top").to-top Back to top

  Pick the approach that suits you.

-  ### Services with dependencies
+  #### Services with dependencies

  Services often depend on other services that Angular injects into the constructor.
  You can test these services _without_ the testbed.
@ -1675,7 +1675,7 @@ a(href="#top").to-top Back to top

 #isolated-pipe-tests
 :marked
-  ## Pipes
+  ### Pipes
  Pipes are easy to test without the Angular testing utilities.

  A pipe class has one method, `transform`, that turns an input to an output. 
@ -1691,7 +1691,7 @@ a(href="#top").to-top Back to top
  Use simple Jasmine to explore the expected cases and the edge cases.
 +makeExample('testing/ts/app/shared/title-case.pipe.spec.ts', 'excerpt', 'app/shared/title-case.pipe.spec.ts')
 :marked
-  ### Write Angular tests too
+  #### Write Angular tests too
  These are tests of the pipe _in isolation_.
  They can't tell if the `TitleCasePipe` is working properly as applied in the application components.

@ -1700,7 +1700,7 @@ a(href="#top").to-top Back to top

 #isolated-component-tests
 :marked
-  ## Components
+  ### Components

  Component tests typically examine how a component class interacts with its own template or with collaborating components.
  The Angular testing utilities are specifically designed to facilitate such tests.
@ -1737,7 +1737,7 @@ a(href="#top").to-top Back to top

 #atu-apis
 :marked
-  # Angular Testing Utility APIs
+  ## Angular Testing Utility APIs

  This section takes inventory of the most useful Angular testing features and summarizes what they do.

@ -1829,7 +1829,7 @@ table

 #testbed-class-summary
 :marked
-  # _TestBed_ Class Summary
+  ## _TestBed_ Class Summary
  The `TestBed` class is one of the principal Angular testing utilities. 
  Its API is quite large and can be overwhelming until you've explored it first
  a little at a time. Read the early part of this chapter first
@ -1972,7 +1972,7 @@ table

 #component-fixture-api-summary
 :marked
-  ## The _ComponentFixture_
+  ### The _ComponentFixture_

  The `TestBed.createComponent<T>`
  creates an instance of the component `T` 
@ -1983,7 +1983,7 @@ table

 #component-fixture-properties
 :marked
-  ### _ComponentFixture_ properties
+  #### _ComponentFixture_ properties

  Here are the most important properties for testers, in order of likely utility.
  
@ -2021,7 +2021,7 @@ table

 #component-fixture-methods
 :marked
-  ### _ComponentFixture_ methods
+  #### _ComponentFixture_ methods

  The _fixture_ methods cause Angular to perform certain tasks to the component tree.
  Call these method to trigger Angular behavior in response to simulated user action.
@ -2088,7 +2088,7 @@ table

 #debug-element-details
 :marked
-  ### _DebugElement_
+  #### _DebugElement_

  The `DebugElement` provides crucial insights into the component's DOM representation.

--- a/public/docs/ts/latest/guide/upgrade.jade
+++ b/public/docs/ts/latest/guide/upgrade.jade
@ -48,7 +48,7 @@ include ../_util-fns

 .l-main-section
 :marked
-  # Preparation
+  ## Preparation

  There are many ways to structure Angular 1 applications. When we begin
  to upgrade these applications to Angular 2, some will turn out to be
@ -56,7 +56,7 @@ include ../_util-fns
  and patterns that we can apply to future proof our apps even before we
  begin the migration.

-  ## Follow the Angular Style Guide
+  ### Follow the Angular Style Guide

  The [Angular 1 Style Guide](https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md#single-responsibility)
  collects patterns and practices that have been proven to result in
@ -91,7 +91,7 @@ include ../_util-fns
  preparation step. And this is not just for the sake of the upgrade - it is just
  solid advice in general!

-  ## Using a Module Loader
+  ### Using a Module Loader

  When we break application code down into one component per file, we often end
  up with a project structure with a large number of relatively small files. This is
@ -113,7 +113,7 @@ include ../_util-fns
  to package them all up into production bundles with batteries included.

 :marked
-  ## Migrating to TypeScript
+  ### Migrating to TypeScript

  If part of our Angular 2 upgrade plan is to also take TypeScript into use, it makes
  sense to bring in the TypeScript compiler even before the upgrade itself begins.
@ -139,7 +139,7 @@ include ../_util-fns
    closer to becoming Angular 2 service and component classes, which will make our
    life easier once we do the upgrade.

-  ## Using Component Directives
+  ### Using Component Directives

  In Angular 2, components are the main primitive from which user interfaces
  are built. We define the different parts of our UIs as components, and then
@ -205,7 +205,7 @@ include ../_util-fns

 .l-main-section
 :marked
-  # Upgrading with The Upgrade Module
+  ## Upgrading with The Upgrade Module

  The `upgrade` module in Angular 2 is a very useful tool for upgrading
  anything but the smallest of applications. With it we can mix and match
@ -214,7 +214,7 @@ include ../_util-fns
  since there's a natural coexistence between the two frameworks during the
  transition period.

-  ## How The Upgrade Module Works
+  ### How The Upgrade Module Works

  The primary tool provided by the upgrade module is called the `UpgradeModule`.
  This is a service that can bootstrap and manage hybrid applications that support
@ -230,7 +230,7 @@ include ../_util-fns
  framework can interoperate with those from the other framework. This happens
  in three main areas: Dependency injection, the DOM, and change detection.

-  ### Dependency Injection
+  #### Dependency Injection

  Dependency injection is front and center in both Angular 1 and
  Angular 2, but there are some key differences between the two
@ -278,7 +278,7 @@ figure.image-display
  img(src="/resources/images/devguide/upgrade/injectors.png" alt="The two injectors in a hybrid application" width="700")

 :marked
-  ### Components and the DOM
+  #### Components and the DOM

  What we'll find in the DOM of a hybrid application are components and
  directives from both Angular 1 and Angular 2. These components
@ -335,7 +335,7 @@ figure.image-display
  use Angular 1 component directives from Angular 2.

 :marked
-  ### Change Detection
+  #### Change Detection

  Change detection in Angular 1 is all about `scope.$apply()`. After every
  event that occurs, `scope.$apply()` gets called. This is done either
@ -386,7 +386,7 @@ figure.image-display
  as regular Angular 2 inputs and set onto the scope (or controller) when
  they change.

-  ## Using UpgradeModule with Angular 2 _NgModules_
+  ### Using UpgradeModule with Angular 2 _NgModules_

  Both Angular 1 and Angular 2 have their own concept of modules
  to help organize an application into cohesive blocks of funcionality.
@ -406,7 +406,7 @@ figure.image-display
    Learn more about Angular 2 modules at the [NgModule guide](ngmodule.html).
  
 :marked
-  ## Bootstrapping Hybrid Angular 1+2 Applications
+  ### Bootstrapping Hybrid Angular 1+2 Applications

  The first step to upgrading an application using the `UpgradeModule` is
  always to bootstrap it as a hybrid that supports both Angular 1 and
@ -458,7 +458,7 @@ figure.image-display
  existing Angular 1 code works as before _and_ you're ready to run Angular 2 code.

 :marked
-  ## Using Angular 2 Components from Angular 1 Code
+  ### Using Angular 2 Components from Angular 1 Code
 figure
  img(src="/resources/images/devguide/upgrade/a1-to-a2.png" alt="Using an Angular 2 component from Angular 1 code" align="left" style="width:250px; margin-left:-40px;margin-right:10px" )
 :marked
@ -550,7 +550,7 @@ figure
 +makeExample('upgrade-module/ts/index-downgrade-io.html', 'userepeatedcomponent')

 :marked
-  ## Using Angular 1 Component Directives from Angular 2 Code
+  ### Using Angular 1 Component Directives from Angular 2 Code
 figure
  img(src="/resources/images/devguide/upgrade/a2-to-a1.png" alt="Using an Angular 1 component from Angular 2 code" align="left" style="width:250px; margin-left:-40px;margin-right:10px" )
 :marked
@ -652,7 +652,7 @@ table


 :marked
-  ## Projecting Angular 1 Content into Angular 2 Components
+  ### Projecting Angular 1 Content into Angular 2 Components
 figure
  img(src="/resources/images/devguide/upgrade/a1-to-a2-with-projection.png" alt="Projecting Angular 1 content into Angular 2" align="left" style="width:250px; margin-left:-40px;margin-right:10px" )
 :marked
@ -680,7 +680,7 @@ figure
    remains in "Angular 1 land" and is managed by the Angular 1 framework.

 :marked
-  ## Transcluding Angular 2 Content into Angular 1 Component Directives
+  ### Transcluding Angular 2 Content into Angular 1 Component Directives
 figure
  img(src="/resources/images/devguide/upgrade/a2-to-a1-with-transclusion.png" alt="Projecting Angular 2 content into Angular 1" align="left" style="width:250px; margin-left:-40px;margin-right:10px" )
 :marked
@ -707,7 +707,7 @@ figure
 +makeExample('upgrade-module/ts/app/2-to-1-transclusion/container.component.ts', null, 'container.component.ts')

 :marked
-  ## Making Angular 1 Dependencies Injectable to Angular 2
+  ### Making Angular 1 Dependencies Injectable to Angular 2

  When running a hybrid app, we may bump into situations where we need to have
  some Angular 1 dependencies to be injected to Angular 2 code. This may be
@ -740,7 +740,7 @@ figure
    provider can be upgraded.

 :marked
-  ## Making Angular 2 Dependencies Injectable to Angular 1
+  ### Making Angular 2 Dependencies Injectable to Angular 1

  In addition to upgrading Angular 1 dependencies, we can also *downgrade*
  Angular 2 dependencies, so that we can use them from Angular 1. This can be
@ -774,7 +774,7 @@ figure

 .l-main-section
 :marked
-  # PhoneCat Upgrade Tutorial
+  ## PhoneCat Upgrade Tutorial

  In this section and we will look at a complete example of
  preparing and upgrading an application using the `upgrade` module. The app
@ -861,7 +861,7 @@ figure
    [Organizing Tests](https://github.com/johnpapa/angular-styleguide/blob/master/a1/README.md#style-y197).

 :marked
-  ## Switching to TypeScript
+  ### Switching to TypeScript

  Since we're going to be writing our Angular 2 code in TypeScript, it makes sense to
  bring in the TypeScript compiler even before we begin upgrading.
@ -1009,7 +1009,7 @@ code-example(format="").
  factory. So we won't be doing anything to it in the preparation stage.
  We'll instead turn it directly into an Angular 2 service.

-  ## Installing Angular 2
+  ### Installing Angular 2

  Having completed our preparation work, let's get going with the Angular 2
  upgrade of PhoneCat. We'll do this incrementally with the help of the
@ -1066,7 +1066,7 @@ code-example(format="").
 +makeExample('upgrade-phonecat-2-hybrid/ts/systemjs.config.1.js', 'paths', 'systemjs.config.js')

 :marked
-  ## Creating the _AppModule_
+  ### Creating the _AppModule_

  Now create the root `NgModule` class called `AppModule`.
  There is already a file named `app.module.ts` that holds the Angular 1 module. 
@ -1081,7 +1081,7 @@ code-example(format="").
 +makeExample('upgrade-phonecat-2-hybrid/ts/app/app.module.ts', 'bare', 'app.module.ts')

 :marked
-  ## Bootstrapping a hybrid 1+2 PhoneCat
+  ### Bootstrapping a hybrid 1+2 PhoneCat

  What we'll do next is bootstrap the application as a *hybrid application*
  that supports both Angular 1 and Angular 2 components. Once we've done that
@ -1116,7 +1116,7 @@ code-example(format="").

 .l-sub-section
  :marked
-    ### Why declare _angular_ as _angular.IAngularStatic_?
+    #### Why declare _angular_ as _angular.IAngularStatic_?
    
    `@types/angular` is declared as a UMD module, and due to the way 
    <a href="https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#support-for-umd-module-definitions" target="_blank">UMD typings</a>
@ -1135,7 +1135,7 @@ code-example(format="").
    and still have full typing support.

 :marked
-  ## Upgrading the Phone service
+  ### Upgrading the Phone service

  The first piece we'll port over to Angular 2 is the `Phone` service, which
  resides in `app/core/phone/phone.service.ts` and makes it possible for components
@ -1230,7 +1230,7 @@ code-example(format="").
    reduce the amount of changes needed in the component controllers.

 :marked
-  ## Upgrading Components
+  ### Upgrading Components

  Next, let's upgrade our Angular 1 components to Angular 2 components. We'll
  do it one at a time, while still keeping the application in hybrid mode.
@ -1264,7 +1264,7 @@ code-example(format="").
 +makeExample('upgrade-phonecat-2-hybrid/ts/app/phone-list/phone-list.template.html', 'list', 'app/phone-list/phone-list.template.html (phones)')(format='.')

 :marked
-  ### No Angular 2 _filter_ or _orderBy_ filters
+  #### No Angular 2 _filter_ or _orderBy_ filters
  The built-in Angular 1 `filter` and `orderBy` filters do not exist in Angular 2,
  so we need to do the filtering and sorting ourselves. 
  
@ -1344,7 +1344,7 @@ code-example(format="").
 :marked
  We should now also remove the phone detail component &lt;script&gt; tag from `index.html`.

-  ### Add the _CheckmarkPipe_
+  #### Add the _CheckmarkPipe_

  The Angular 1 directive had a `checkmark` _filter_.
  Let's turn that into an Angular 2 **pipe**.
@ -1364,7 +1364,7 @@ code-example(format="").
 +makeExample('upgrade-phonecat-2-hybrid/ts/app/app.module.ts', 'checkmarkpipe', 'app.module.ts')

 :marked
-  ## Switching To The Angular 2 Router And Bootstrap
+  ### Switching To The Angular 2 Router And Bootstrap

  At this point we've replaced all Angular 1 application components with
  their Angular 2 counterparts. 
@ -1375,7 +1375,7 @@ code-example(format="").
  1. Switch to the Angular 2 router.
  1. Bootstrap as a pure Angular 2 app.

-  ### Switch to the Angular 2 router
+  #### Switch to the Angular 2 router
  Angular 2 has an [all-new router](router.html).

  Like all routers, it needs a place in the UI to display routed views.
@ -1400,7 +1400,7 @@ code-example(format="").
 +makeExample('upgrade-phonecat-3-final/ts/index.html', 'appcomponent', 'index.html (body)')(format='.')

 :marked
-  ### Create the _Routing Module_
+  #### Create the _Routing Module_
  A router needs configuration whether it's the Angular 1 or Angular 2 or any other router.
  
  The details of Angular 2 router configuration are best left to the [Routing documentation](router.html) 
@ -1428,7 +1428,7 @@ code-example(format="").

 +makeExample('upgrade-phonecat-3-final/ts/app/phone-detail/phone-detail.component.ts', null, 'app/phone-detail/phone-detail.component.ts')
 :marked
-  ### Generate links for each phone
+  #### Generate links for each phone

  We no longer have to hardcode the links to phone details in the phone list. 
  We can generate them data binding each phone's `id` to the `routerLink` directive
@ -1440,7 +1440,7 @@ code-example(format="").
    See the [Routing](router.html) page for details.

 :marked
-  ### Bootstrap as an Angular 2 app
+  #### Bootstrap as an Angular 2 app

  You may have noticed one extra `bootstrap` metadata property added to the `AppModule`
 +makeExample('upgrade-phonecat-3-final/ts/app/app.module.ts', 'bootstrap', 'app/app.module.ts (bootstrap)')(format='.')
@ -1460,7 +1460,7 @@ code-example(format="").
 :marked
  You are now running a pure Angular 2 application!

-  ## Say Goodbye to Angular 1
+  ### Say Goodbye to Angular 1

  It is time to take off the training wheels and let our application begin
  its new life as a pure, shiny Angular 2 app. The remaining tasks all have to
@ -1503,13 +1503,13 @@ code-example(format="").

 .l-main-section
 :marked
-  # Appendix: Upgrading PhoneCat Tests
+  ## Appendix: Upgrading PhoneCat Tests

  Tests can not only be retained through an upgrade process, but they can also be
  used as a valuable safety measure when ensuring that the application does not
  break during the upgrade. E2E tests are especially useful for this purpose.

-  ## E2E Tests
+  ### E2E Tests

  The PhoneCat project has both E2E Protractor tests and some Karma unit tests in it.
  Of these two, E2E tests can be dealt with much more easily: By definition,
@ -1617,7 +1617,7 @@ code-example(format="").
 +makeExample('upgrade-phonecat-3-final/e2e-spec.ts', 'links', 'e2e-tests/scenarios.ts')

 :marked
-  ## Unit Tests
+  ### Unit Tests

  For unit tests, on the other hand, more conversion work is needed. Effectively
  they need to be *upgraded* along with the production code.