Fix Bikeshed errors/warnings

Fixes some definition links, algorithm name, example ID, and RFC2119 keyword lint warning.

Author: christhompson

fetch.bs

@@ -2141,7 +2141,7 @@ Unless stated otherwise, it is false.
 <p>A <a for=/>request</a> has an associated
 <dfn export for=request id=https-upgrade-fallback-url>https-upgrade-fallback-url</dfn>. It is a copy
 of the <a for=/>request</a>'s original <a for=/>URL</a> before <a for=/>request</a> is
-<a for="#https-upgrades-upgrade">optionally upgraded to HTTPS</a>. Unless stated otherwise, it is
+<a href="#https-upgrades-upgrade">optionally upgraded to HTTPS</a>. Unless stated otherwise, it is
 unset.
 
 <p class=note>This flag is for exclusive use by https-upgrades algorithm.
@@ -3252,11 +3252,11 @@ through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in
 
 <h3 id=https-upgrades>HTTPS upgrading</h3>
 
-<div algorithm>
+<div algorithm="https-upgrades">
 
-<p>User agents may optionally upgrade requests with <a>potentially untrustworthy URL</a>s
-to attempt to fetch them over <a>potentially trustworthy URL</a>s. If an upgraded request
-fails with a network error, it is retried over the original URL.
+<p>User agents may optionally upgrade requests with URLs that are not
+<a>potentially trustworthy URLs</a> to attempt to fetch them over <a>potentially trustworthy URL</a>s.
+If an upgraded request fails with a network error, it is retried over the original URL.
 
 <p>The HTTPS upgrading algorithm consists of Upgrade and Fallback algorithms, with the following
 steps:
@@ -3280,9 +3280,10 @@ steps:
       <li><p><var>request</var>'s <a for="request">URL</a>'s <a for="url">host</a> is exempted from
       upgrades in an <a>implementation-defined</a> way.
 
-      <p class="example">If <a for=url>host</a> is a non-registrable or non-assignable domain name
-      such as .local or an IP address that falls in a range reserved for non-publicly routable
-      networks, the implementation might return without modifying <var>request</var>.
+      <p class="example" id="example-https-upgrades-exempted-hosts">If <a for=url>host</a> is a
+      non-registrable or non-assignable domain name such as .local or an IP address that falls in a
+      range reserved for non-publicly routable networks, the implementation might return without
+      modifying <var>request</var>.
     </ul>
   </li>
 
@@ -3313,7 +3314,7 @@ To run <dfn>HTTPS upgrade fallback</dfn> given a <a for=/>request</a>
     <p>If <var>response</var> is a network error, run the following steps:
     <p class="note">This means that the upgrade failed and initiates a fallback load.
      <ol>
-      <li><p>Let <var>fallbackResponse</var> be a new <a>Response</a> with its <code>Location</code> header set to
+      <li><p>Let <var>fallbackResponse</var> be a new <a for=/>Response</a> with its <code>Location</code> header set to
       <code>https-upgrade-fallback-url</code>, and its <a for="response">status</a> set to 307.
       <li>Return <var>fallbackResponse</var>.
      </ol>
@@ -3324,12 +3325,12 @@ To run <dfn>HTTPS upgrade fallback</dfn> given a <a for=/>request</a>
 </ol>
 
 <p class=note>
-User agents may implement an optional fast-fallback path by canceling slow fetches on upgraded
-requests and quickly initiate a fallback http load.
+User agents can implement a fast-fallback path by canceling slow fetches on upgraded
+requests, in order to quickly initiate a fallback http load.
 
 </div>
 
-<h4>Examples</h4>
+<h4 id=http-upgrades-examples>Examples</h4>
 
 <div id=example-https-upgrade-good-https class=example>
  <p>