Remove a <div> with no attributes.

index.bs

@@ -695,32 +695,29 @@ authorizing an authenticator with which to complete the operation.
     };
 </pre>
 
-<div>
-    Clients may communicate with authenticators using a variety of mechanisms. For example, a client may use a platform-specific
-    API to communicate with an authenticator which is physically bound to a platform. On the other hand, a client may use a
-    variety of standardized cross-platform transport protocols such as Bluetooth (see [[#transport]]) to discover and
-    communicate with <a>cross-platform attached</a> authenticators. We define authenticators that are part of the client's
-    platform as having a <a>platform attachment</a>, and refer to them as <dfn>platform authenticators</dfn>. While those that
-    are reachable via cross-platform transport protocols are defined as having <a>cross-platform attachment</a>, and refer to
-    them as <dfn>roaming authenticators</dfn>.
-
-    <ul>
-        <li><dfn>platform attachment</dfn> - the respective authenticator is attached
-            using platform-specific transports.  Usually, authenticators of
-            this class are non-removable from the platform.
-        <li><dfn lt="cross-platform attached|cross-platform attachment">cross-platform attachment</dfn> - the respective
-            authenticator is attached using cross-platform transports. Authenticators of this class are removable from, and can
-            "roam" among, client platforms.
-    </ul>
-
-    This distinction is important because there are use-cases where only <a>platform authenticators</a> are acceptable to a
-    [RP], and conversely ones where only <a>roaming authenticators</a> are employed. As a concrete example of the former, a
-    credential on a <a>platform authenticator</a> may be used by [RPS] to quickly and conveniently reauthenticate the user with
-    a minimum of friction, e.g., the user will not have to dig around in their pocket for their key fob or phone. As a concrete
-    example of the latter, when the user is accessing the [RP] from a given client for the first time, they may be required to
-    use a <a>roaming authenticator</a> which was originally registered with the [RP] using a different client.
+Clients may communicate with authenticators using a variety of mechanisms. For example, a client may use a platform-specific
+API to communicate with an authenticator which is physically bound to a platform. On the other hand, a client may use a
+variety of standardized cross-platform transport protocols such as Bluetooth (see [[#transport]]) to discover and
+communicate with <a>cross-platform attached</a> authenticators. We define authenticators that are part of the client's
+platform as having a <a>platform attachment</a>, and refer to them as <dfn>platform authenticators</dfn>. While those that
+are reachable via cross-platform transport protocols are defined as having <a>cross-platform attachment</a>, and refer to
+them as <dfn>roaming authenticators</dfn>.
+
+<ul>
+    <li><dfn>platform attachment</dfn> - the respective authenticator is attached
+        using platform-specific transports.  Usually, authenticators of
+        this class are non-removable from the platform.
+    <li><dfn lt="cross-platform attached|cross-platform attachment">cross-platform attachment</dfn> - the respective
+        authenticator is attached using cross-platform transports. Authenticators of this class are removable from, and can
+        "roam" among, client platforms.
+</ul>
 
-</div>
+This distinction is important because there are use-cases where only <a>platform authenticators</a> are acceptable to a
+[RP], and conversely ones where only <a>roaming authenticators</a> are employed. As a concrete example of the former, a
+credential on a <a>platform authenticator</a> may be used by [RPS] to quickly and conveniently reauthenticate the user with
+a minimum of friction, e.g., the user will not have to dig around in their pocket for their key fob or phone. As a concrete
+example of the latter, when the user is accessing the [RP] from a given client for the first time, they may be required to
+use a <a>roaming authenticator</a> which was originally registered with the [RP] using a different client.
 
 
 ## Web Authentication Assertion (interface <dfn interface>AuthenticationAssertion</dfn>) ## {#iface-assertion}