Remove .html extension from links

chrome/common/extensions/docs/templates/articles/contentSecurityPolicy.html

 <h1>Content Security Policy (CSP)</h1>
 
 
 <p>
   In order to mitigate a large class of potential cross-site scripting issues,
   Chrome's extension system has incorporated the general concept of
   <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html">
     <strong>Content Security Policy (CSP)</strong>
   </a>. This introduces some fairly strict policies that will make extensions
   more secure by default, and provides you with the ability to create and
   enforce rules governing the types of content that can be loaded and executed
   by your extensions and applications.
 </p>
 
 <p>
   In general, CSP works as a black/whitelisting mechanism for resources loaded
   or executed by your extensions. Defining a reasonable policy for your
   extension enables you to carefully consider the resources that your extension
   requires, and to ask the browser to ensure that those are the only resources
   your extension has access to. These policies provide security over and above
-  the <a href="declare_permissions.html">host permissions</a> your extension
+  the <a href="declare_permissions">host permissions</a> your extension
   requests; they're an additional layer of protection, not a replacement.
 </p>
 
 <p>
   On the web, such a policy is defined via an HTTP header or <code>meta</code>
   element. Inside Chrome's extension system, neither is an appropriate
   mechanism. Instead, an extension's policy is defined via the extension's
-  <a href="manifest.html"><code>manifest.json</code></a> file as follows:
+  <a href="manifest"><code>manifest.json</code></a> file as follows:
 </p>
 
 <pre data-filename="manifest.json">
 {
   ...,
   "content_security_policy": "[POLICY STRING GOES HERE]"
   ...
 }
 </pre>
 
 <p class="note">
   For full details regarding CSP's syntax, please take a look at
   <a href="http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#syntax">
     the Content Security Policy specification
   </a>, and the <a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/">
     "An Introduction to Content Security Policy"
   </a> article on HTML5Rocks.
 </p>
 
 <h2 id="restrictions">Default Policy Restrictions</h2>
 
 <p>
-  Packages that do not define a <a href="manifestVersion.html">
+  Packages that do not define a <a href="manifestVersion">
     <code>manifest_version</code>
   </a> have no default content security policy. Those that select
   <code>manifest_version</code> 2, have a default content security policy
   of:
 </p>
 
 <pre>script-src 'self'; object-src 'self'</pre>
 
 <p>
   This policy adds security by limiting extensions and applications in three 
@@ skipping 28 matching lines @@
  <code>&lt;script&gt;</code> blocks <strong>and</strong> inline event handlers
  (e.g. <code>&lt;button onclick="..."&gt;</code>).
 </p>
 
 <p>
   The first restriction wipes out a huge class of cross-site scripting attacks
   by making it impossible for you to accidentally execute script provided by a
   malicious third-party. It does, however, require you to write your code with a
   clean separation between content and behavior (which you should of course do
   anyway, right?). An example might make this clearer. You might try to write a
-  <a href="browserAction.html#popups">Browser Action's popup</a> as a single
+  <a href="browserAction#popups">Browser Action's popup</a> as a single
   <code>popup.html</code> containing:
 </p>
 
 <pre data-filename="popup.html">
 &lt;!doctype html&gt;
 &lt;html&gt;
   &lt;head&gt;
     &lt;title&gt;My Awesome Popup!&lt;/title&gt;
     &lt;script&gt;
       function awesome() {
@@ skipping 192 matching lines @@
 
 <p class="note">
   Note that both <code>script-src</code> and <code>object-src</code> are defined
   by the policy. Chrome will not accept a policy that doesn't limit each of
   these values to (at least) <code>'self'</code>.
 </p>
 
 <p>
   Making use of Google Analytics is the canonical example for this sort of
   policy definition. It's common enough that we've provided an Analytics
-  boilerplate of sorts in the <a href="samples.html#event-tracking-with-google-analytics">Event Tracking
+  boilerplate of sorts in the <a href="samples#event-tracking-with-google-analytics">Event Tracking
   with Google Analytics</a> sample extension, and a
-<a href="tut_analytics.html">brief tutorial</a> that goes into more detail.
+<a href="tut_analytics">brief tutorial</a> that goes into more detail.
 </p>
 
 <h3 id="relaxing-eval">Evaluated JavaScript</h3>
 
 <p>
   The policy against <code>eval()</code> and its relatives like
   <code>setTimeout(String)</code>, <code>setInterval(String)</code>, and
   <code>new Function(String)</code> can be relaxed by adding
   <code>'unsafe-eval'</code> to your policy:
 </p>
 
 <pre data-filename="manifest.json">
 "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"
 </pre>
 
 <p>
   However, we strongly recommend against doing this. These functions are
   notorious XSS attack vectors.
 </p>
 
 <h2 id="tightening">Tightening the default policy</h2>
 
 <p>
   You may, of course, tighten this policy to whatever extent your extension
   allows in order to increase security at the expense of convenience. To specify
   that your extension can only load resources of <em>any</em> type (images, etc)
   from its own package, for example, a policy of <code>default-src 'self'</code>
-  would be appropriate. The <a href="samples.html#mappy">Mappy</a> sample
+  would be appropriate. The <a href="samples#mappy">Mappy</a> sample
   extension is a good example of an extension that's been locked down above and
   beyond the defaults.
 </p>