Rearrange tables so that navigation can be added back to certain pages.

native_client_sdk/doc_generated/devguide/devcycle/running.html

-{{+bindTo:partials.standard_nacl_api}}
+{{+bindTo:partials.standard_nacl_article}}
 
 <section id="running">
-<h1 id="running">Running</h1>
+<span id="devcycle-running"></span><h1 id="running"><span id="devcycle-running"></span>Running</h1>
 <div class="contents local" id="contents" style="display: none">
 <ul class="small-gap">
 <li><a class="reference internal" href="#introduction" id="id5">Introduction</a></li>
 <li><a class="reference internal" href="#portable-native-client-pnacl-applications" id="id6">Portable Native Client (PNaCl) applications</a></li>
 <li><a class="reference internal" href="#native-client-applications-and-the-chrome-web-store" id="id7">Native Client applications and the Chrome Web Store</a></li>
 <li><p class="first"><a class="reference internal" href="#prerequisites" id="id8">Prerequisites</a></p>
 <ul class="small-gap">
 <li><a class="reference internal" href="#browser-and-pepper-versions" id="id9">Browser and Pepper versions</a></li>
 <li><a class="reference internal" href="#chrome-cache" id="id10">Chrome Cache</a></li>
 </ul>
@@ skipping 49 matching lines @@
 every time you want to run a new build of your application, but there are four
 alternative techniques you can use to run the application during development.
 These techniques are listed in the following table and described in detail
 below. Each technique has certain requirements (NaCl flag, web server, and/or
 CWS metadata); these are explained in the <a class="reference internal" href="#requirements"><em>Requirements</em></a>
 section below.</p>
 <table border="1" class="docutils">
 <colgroup>
 </colgroup>
 <thead valign="bottom">
-<tr class="row-odd"><th class="head">#</th>
-<th class="head">Technique</th>
-<th class="head">Requires NaCl flag</th>
-<th class="head">Requires Web Server</th>
-<th class="head">Requires CWS Metadata</th>
-<th class="head">Description</th>
+<tr class="row-odd"><th class="head" colspan="2">Technique</th>
+<th class="head">Requires
+Web
+Server</th>
+<th class="head">Requires
+CWS
+Metadata</th>
 </tr>
 </thead>
 <tbody valign="top">
-<tr class="row-even"><td>1</td>
-<td>Local server</td>
+<tr class="row-even"><td colspan="2"><p class="first"><strong>1. Local server</strong></p>
+<blockquote class="last">
+<div><blockquote>
+<div><p>Run a local server and simply point your browser to
+your application on the server.</p>
+<aside class="note">
+This technique requires the NaCl flag.
+</aside>
+</div></blockquote>
+</div></blockquote>
+</td>
+<td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
+<td>&nbsp;</td>
+</tr>
+<tr class="row-odd"><td colspan="2"><p class="first"><strong>2. Packaged application loaded as an unpacked
+extension</strong></p>
+<blockquote class="last">
+<div><blockquote>
+<div>Load your packaged application into Chrome as an
+unpacked extension and run it without a server. An
+unpacked extension is an application whose source and
+metadata files are located in an unzipped folder on
+your development machine. The CWS manifest file
+(explained below) must specify a local_path field.</div></blockquote>
+</div></blockquote>
+</td>
+<td>&nbsp;</td>
+<td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
+</tr>
+<tr class="row-even"><td colspan="2"><p class="first"><strong>3. Hosted application loaded as an unpacked
+extension</strong></p>
+<blockquote class="last">
+<div><blockquote>
+<div>Load your hosted application into Chrome as an
+unpacked extension and run it from a server (which can
+be a local server). The CWS manifest file must specify
+a web_url field.</div></blockquote>
+</div></blockquote>
+</td>
 <td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
 <td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
-<td>&nbsp;</td>
-<td>Run a local server and simply point your browser to your application on
-the server.</td>
 </tr>
-<tr class="row-odd"><td>2</td>
-<td>Packaged application loaded as an unpacked extension</td>
-<td>&nbsp;</td>
+<tr class="row-odd"><td colspan="2"><p class="first"><strong>4. CWS application with untrusted testers</strong></p>
+<blockquote class="last">
+<div><blockquote>
+<div>The standard technique for distributing a packaged or
+hosted application in the CWS. You can limit the
+application to trusted testers. This technique
+requires a server if your application is a hosted
+application.</div></blockquote>
+</div></blockquote>
+</td>
 <td>&nbsp;</td>
 <td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
-<td>Load your packaged application into Chrome as an unpacked extension and
-run it without a server. An unpacked extension is simply an application
-whose source and metadata files are located in a plain (unzipped) folder
-on your development machine. The CWS manifest file (explained below) must
-specify a <code>local_path</code> field.</td>
-</tr>
-<tr class="row-even"><td>3</td>
-<td>Hosted application loaded as an unpacked extension</td>
-<td>&nbsp;</td>
-<td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
-<td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
-<td>Load your hosted application into Chrome as an unpacked extension and run
-it from a server (which can be a local server). The CWS manifest file
-must specify a <code>web_url</code> field.</td>
-</tr>
-<tr class="row-odd"><td>4</td>
-<td>CWS application with untrusted testers</td>
-<td>&nbsp;</td>
-<td>&nbsp;</td>
-<td><img alt="CHK" src="/native-client/images/check-red.png" /></td>
-<td>This is the standard technique for distributing a packaged or hosted
-application in the CWS, but you can limit the application to a few
-trusted testers. This technique requires a server if your application is
-a hosted application.</td>
 </tr>
 </tbody>
 </table>
 <p>Which of the above techniques you use to run your application during development
 is largely a matter of personal preference (i.e., would you rather start a local
 server or create CWS metadata?). As a general rule, once you have an idea of how
 you plan to distribute your application, you should use the corresponding
 technique during development. Choosing a distribution option depends on a number
 of factors such as application size, application start-up time, hosting costs,
 offline functionality, etc. (see <a class="reference internal" href="/native-client/devguide/distributing.html"><em>Distributing Your Application</em></a> for details), but you don&#8217;t need to make a decision about how
@@ skipping 287 matching lines @@
 be able to find the application by searching in the CWS.</li>
 </ul>
 </li>
 </ol>
 <p>To publish an application to the world after publishing it to test accounts,
 you must first unpublish the application. For additional information see
 <a class="reference external" href="/webstore/docs/publish">Publishing Your App</a>, and in particular <a class="reference external" href="/webstore/publish#testaccounts">Publishing
 to test accounts</a>.</p>
 </section>
 
-{{/partials.standard_nacl_api}}
+{{/partials.standard_nacl_article}}