Remove .html extension from links

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

 <h1>Chrome 33 Hosting Changes</h1>

[mkearney1, 2014/05/14 19:56:06]

General question: when removing the header IDs, what will happen to urls that
link to these? I've included another comment in this doc that is an example of
this.

[ahernandez, 2014/05/14 20:13:45]

I don't think I quite understand your question. There shouldn't be any urls that
link to these headers since they don't exist in the current code base, if that's
what you mean.

 
 <p>As a follow-up to our blog post on
 <a href="http://blog.chromium.org/2013/11/protecting-windows-users-from-malicious.html">protecting Windows users from malicious extensions</a>,
 we’re enforcing the following changes starting in Chrome 33 Beta and stable channels for Windows:<p>
 
 <ul>
   <li>Users can only install extensions hosted in the Chrome Web store, except for installs via
 <a href="https://support.google.com/chrome/a/answer/188453">enterprise policy</a>
-or <a href="http://developer.chrome.com/extensions/getstarted.html#unpacked">developer mode</a>.</li>
+or <a href="http://developer.chrome.com/extensions/getstarted#unpacked">developer mode</a>.</li>
   <li>Extensions that were previously installed, but not hosted on the Chrome Web Store will be
 <a href="https://support.google.com/chrome/answer/2811969">hard-disabled</a>
 (i.e the user cannot enable these extensions again), except for installs via
 <a href="https://support.google.com/chrome/a/answer/188453">enterprise policy</a>
-or <a href="http://developer.chrome.com/extensions/getstarted.html#unpacked">developer mode</a>.</li>
+or <a href="http://developer.chrome.com/extensions/getstarted#unpacked">developer mode</a>.</li>
 </ul>
 
-<h2>What’s the rationale for this measure?</h2>
+<h2 id="rationale">What’s the rationale for this measure?</h2>
 
 <p>See <a href="http://blog.chromium.org/2013/11/protecting-windows-users-from-malicious.html">Protecting Windows users from malicious extensions</a>.</p>
 
-<h2>For extensions that are currently hosted outside the Chrome Web Store, what should be done and by when?</h2>
+<h2 id="externally_hosted">For extensions that are currently hosted outside the Chrome Web Store, what should be done and by when?</h2>
 
 <p>If your extensions are currently hosted outside the Chrome Web Store,
 you should migrate them to the Chrome Web Store as soon as possible.
 The above changes are already effective on Chrome 33 Beta for Windows and
 will be effective on Chrome 33 stable for Windows (around end of  Feb 2014).
 Once you migrate your extensions to the Chrome Web Store,
 there will be no impact to your users,
 who will still be able to use your extension as if nothing changed.
 And if you have a dedicated installation flow from your own website,
 you can make use of the existing
 <a href="https://developers.google.com/chrome/web-store/docs/inline_installation">inline installs</a> feature.
 If you’re migrating your extensions to the Chrome Web Store, start testing with Chrome 33 right away.</p>
 
-<h2>What will happen if I migrate the extension to the Chrome Web Store sometime in the future? Will I lose all my users?</h2>
+<h2 id="migration">What will happen if I migrate the extension to the Chrome Web Store sometime in the future? Will I lose all my users?</h2>
 
 <p>Users will have their off-store extensions hard-disabled once the enforcement rolls out in Chrome 33 stable/beta for Windows.
 However, if the extension is migrated to the Chrome Web Store after the rollout,
 users would be able to manually to enable the migrated extension from extensions settings page (chrome://extensions)
 or from the Chrome Web Store listing.</p>
 
-<h2>What if I want to restrict access to certain users or prevent my extension from being listed on the Chrome Web Store?</h2>
+<h2 id="access_restriction">What if I want to restrict access to certain users or prevent my extension from being listed on the Chrome Web Store?</h2>
 
 <p>You can restrict access to your extension by limiting its visibility to Trusted Tester or
 by unlisting the extension from the Chrome Web Store.</p>
 
-<h2>Which operating systems and Chrome channels are affected by this change?</h2>
+<h2 id="effective_changes">Which operating systems and Chrome channels are affected by this change?</h2>
 
 <p>The changes are effective only for Windows stable and beta channels starting with Chrome 33.</p>
 
-<h2>Will this affect my ability to develop my extensions on Windows?</h2>
+<h2 id="unpacked">Will this affect my ability to develop my extensions on Windows?</h2>
 
 <p>No. You can still load unpacked extensions in
-<a href="http://developer.chrome.com/extensions/getstarted.html#unpacked">developer mode</a>
+<a href="http://developer.chrome.com/extensions/getstarted#unpacked">developer mode</a>

[mkearney1, 2014/05/14 19:56:06]

Will this link still work if you remove "unpacked" id?

[ahernandez, 2014/05/14 20:13:45]

If I remove 'id="unpacked"', the link will still work since it's linking to a
different file.

 on Windows.
 Also, you can continue to develop extensions on Chrome Dev channel/Canary,
 where these changes are not effective.</p>
 
-<h2>How can I distribute my extension if I cannot upload it to the Chrome Web Store for policy reasons?</h2>
+<h2 id="policies">How can I distribute my extension if I cannot upload it to the Chrome Web Store for policy reasons?</h2>
 
 <p>These changes are effective only on Windows stable and beta channel.
 Users who want to get extensions that are not hosted on the Chrome Web Store can do so on
 <a href="http://www.chromium.org/getting-involved/dev-channel">Chrome dev/canary channels in Windows</a>
 or on all Chrome channels in other operating systems.</p>
 
-<h2>Why couldn't this problem be solved by having a setting/option to load extensions that are not hosted in the Chrome Web Store?</h2>
+<h2 id="sandboxing">Why couldn't this problem be solved by having a setting/option to load extensions that are not hosted in the Chrome Web Store?</h2>
 
 <p>Unlike modern mobile operating systems,
 Windows does not sandbox applications.
 Hence we wouldn’t be able to differentiate between a user opting in
 to this setting versus a malicious native app overriding the user’s setting.</p>
 
-<h2>What are the supported deployment options for extensions after this change?</h2>
+<h2 id="deployment">What are the supported deployment options for extensions after this change?</h2>
 
 <p>Apart from users installing extensions from the Chrome Web Store,
 the following deployment options will be supported:</p>
 
 <ul><li>For OSX and Linux, extensions can be installed via a
-<a href="http://developer.chrome.com/extensions/external_extensions.html#preferences">preferences JSON file</a>.</li>
+<a href="http://developer.chrome.com/extensions/external_extensions#preferences">preferences JSON file</a>.</li>
 <li>For Windows, extensions can be installed via the
-<a href="http://developer.chrome.com/extensions/external_extensions.html#registry">Windows registry</a>.
+<a href="http://developer.chrome.com/extensions/external_extensions#registry">Windows registry</a>.
 In the Windows registry,
 ensure that the update_url registry key points to the following URL:
 <a href="https://clients2.google.com/service/update2/crx">https://clients2.google.com/service/update2/crx</a>.
 Local .crx installs via the path registry key are deprecated.
 Note that this deployment option works only for Chrome Web Store hosted extensions,
 and update_url cannot point to any other host other than
 <a href="https://clients2.google.com/service/update2/crx">https://clients2.google.com/service/update2/crx</a>.</li>
 <li>For Enterprises, we’ll continue to support
 <a href="https://support.google.com/chrome/a/answer/188453?hl=en" style="background-color:transparent">group policy</a>
 to install extensions, irrespective of where the extensions are hosted.
 Note that the user's machine has to join a domain for GPO policy pushes to be effective.</li>
 </ul>
 
-<h2>Are there any other considerations to be aware of for extensions that depend on a native application binary?</h2>
+<h2 id="other_considerations">Are there any other considerations to be aware of for extensions that depend on a native application binary?</h2>
 
 <p>Previously when off-store extensions were supported,
 it was possible to have the third party application binaries and the sideloaded extension be updated in lockstep.
 However, extensions hosted on the Chrome Web Store are updated via the Chrome update mechanism
 which developers do not control.
 Extension developers should be careful about updating extensions that have a dependency on the native application binary
 (for example, extensions using
-<a href="https://developer.chrome.com/extensions/messaging.html#native-messaging">native messaging</a>
+<a href="https://developer.chrome.com/extensions/messaging#native-messaging">native messaging</a>
 or legacy extensions using
-<a href="http://developer.chrome.com/extensions/npapi.html">NPAPI</a>).</p>
+<a href="http://developer.chrome.com/extensions/npapi">NPAPI</a>).</p>
 
-<h2>What will users see when their off-store extension is disabled as a result of this rollout?</h2>
+<h2 id="disabled_extension">What will users see when their off-store extension is disabled as a result of this rollout?</h2>
 
 <p>They will get a notification that says:
 “Suspicious Extensions Disabled” with a link to the following
 <a href="https://support.google.com/chrome/answer/2811969">support article</a>.</p>
 
-<h2>Why do I see a bubble about “Disable developer mode extensions” when loading an unpacked extension in Windows stable/beta channels?</h2>
+<h2 id="diable_developer_mode">Why do I see a bubble about “Disable developer mode extensions” when loading an unpacked extension in Windows stable/beta channels?</h2>
 
 <p>We do not want the developer mode to be used as an attack vector for spreading malicious extensions.
 Hence we’re informing users about developer mode extensions on Windows stable/beta channels and
 giving them an option to disable these extensions.</p>