--- a/encrypted-media/encrypted-media-respec.html	Fri Oct 10 14:44:12 2014 -0700
+++ b/encrypted-media/encrypted-media-respec.html	Fri Oct 10 14:44:34 2014 -0700
@@ -127,16 +127,17 @@
     <section id="definitions">
     <h3>Definitions</h3>
 
-    <section id="cdm">
-    <h4>Content Decryption Module (CDM)</h4>
+    <dl>
+      <dt id="cdm">Content Decryption Module (CDM)</dt>
+      <dd>
     <p>The Content Decryption Module (CDM) is a generic term for the client component that provides the functionality, including decryption, for one or more <a href="#key-system">Key Systems</a>.</p>
     <p class="note">Implementations may or may not separate the implementations of CDMs or treat them as separate from the user agent.
     This is transparent to the API and application.
     A user agent may support one or more CDMs.</p>
-    </section>
+      </dd>
 
-    <section id="key-system">
-    <h4>Key System</h4>
+      <dt id="key-system">Key System</dt>
+      <dd>
     <p>A Key System is a generic term for a decryption mechanism and/or content protection provider.
     Key System strings provide unique identification of a Key System.
     They are used by the user agent to select the <a href="#cdm">Content Decryption Modules</a> and identify the source of a key-related event.
@@ -152,10 +153,10 @@
     For example, "com.example.somesystem.1" and "com.example.somesystem.1_5".
     Key System providers should keep in mind that these will be used for comparison and discovery, so they should be easy to compare and the structure should remain reasonably simple.
     </p>
-    </section>
+      </dd>
 
-    <section id="key-session">
-    <h4>Key Session</h4>
+      <dt id="key-session">Key Session</dt>
+      <dd>
     <p>A Key Session, or simply Session, provides a context for message exchange with the CDM as a result of which key(s) are made available to be <a href="#cdm">CDM</a>.
     Sessions are embodied as <a def-id="mediakeysession"></a> objects.
     Each Key session is associated with a single instance of <a href="#initialization-data">Initialization Data</a> provided in the <a def-id="generateRequest"></a> call.
@@ -164,10 +165,10 @@
     Other <a def-id="mediakeys"></a> objects, <a href="#cdm">CDM</a> instances, and media elements may <em>not</em> access the key session or use its key(s).
     Key sessions and the keys they contain are no longer usable by the CDM for decryption when the <a href="#algorithms-session-close">session is closed</a>, including when the <a def-id="mediakeysession"></a> object is destroyed.
     </p>
-    </section>
+      </dd>
 
-    <section id="session-id">
-    <h4>Session ID</h4>
+      <dt id="session-id">Session ID</dt>
+      <dd>
     <p>A Session ID is a unique string identifier generated by the <a href="#cdm">CDM</a> that can be used by the application to identify <a def-id="mediakeysession"></a> objects.</p>
 
     <p>A new Session ID is generated each time the user agent and CDM successfully create a new session.</p>
@@ -177,10 +178,10 @@
     </p>
 
     <p class="note">The underlying content protection protocol does not necessarily need to support Session IDs.</p>
-    </section>
+      </dd>
 
-    <section id="decryption-key">
-    <h4>Key</h4>
+      <dt id="decryption-key">Key</dt>
+      <dd>
     <p>Unless otherwise stated, key refers to a decryption key that can be used to decrypt blocks within <a def-id="media-data"></a>.
     Each such key is uniquely identified by a <a href="#decryption-key-id">key ID</a>.
     A key is associated with the <a href="#key-session">session</a> used to provide it to the CDM. (The same key may be present in multiple sessions.)
@@ -189,25 +190,25 @@
     
     <p>A key is considered <em>usable</em> if the CDM is certain the key is currently usable for decryption.</p>
     <p class="note">For example, a key is not usable if its license has expired.</p>
-    </section>
+      </dd>
 
-    <section id="decryption-key-id">
-    <h4>Key ID</h4>
+      <dt id="decryption-key-id">Key ID</dt>
+      <dd>
     <p>A <a href="#decryption-key">key</a> is associated with a key ID, which uniquely identifies a key.
     The container specifies the ID of the key that can decrypt a block or set of blocks within the <a def-id="media-data"></a>.
     <a href="#initialization-data">Initialization Data</a> may contain key ID(s) to identify the keys that are needed to decrypt the media data.
     However, there is no requirement that Initialization Data contain any or all key IDs used in the <a def-id="media-data"></a> or <a def-id="media-resource"></a>.
     <a href="#license">Licenses</a> provided to the CDM associate each key with a key ID so the <a href="#cdm">CDM</a> can select the appropriate key when decrypting an encrypted block of media data.
     </p>
-    </section>
+      </dd>
 
-    <section id="license">
-    <h4>License</h4>
+      <dt id="license">License</dt>
+      <dd>
     <p>A license is key system-specific state information that includes one or more <a href="#decryption-key">key(s)</a> - each associated with a <a href="#decryption-key-id">key ID</a> - and potentially other information about key usage.</p>
-    </section>
+      </dd>
 
-    <section id="initialization-data">
-    <h4>Initialization Data</h4>
+      <dt id="initialization-data">Initialization Data</dt>
+      <dd>
     <p class="note">
     <a href="#key-system">Key Systems</a> usually require a block of initialization data containing information about the stream to be decrypted before they can construct a license request message.
     This block could be a simple key or content ID or a more complex structure containing such information.
@@ -231,23 +232,24 @@
     The Encrypted Media Extensions Stream Format and Initialization Data Format Registry [[EME-REGISTRY]]
     provides the mapping from initialization data type string to the specification for each format.
     </p>
-    </section>
+      </dd>
 
-    <section id="cross-origin">
-    <h4>Cross Origin Limitations</h4>
+      <dt id="cross-origin">Cross Origin Limitations</dt>
+      <dd>
     <p>During playback, embedded media data is exposed to script in the embedding <a def-id="origin"></a>.
     In order for the API to provide <a href="#initialization-data">Initialization Data</a> in the <a def-id="encrypted"></a> event, <a def-id="media-data"></a> must be <a def-id="cors-same-origin"></a> with the embedding page.
     If <a def-id="media-data"></a> is cross-origin with the embedding document, authors should use the <a def-id="media-crossorigin"></a> attribute
     on the <a href="#htmlmediaelement-extensions">media element</a> and CORS headers on the <a def-id="media-data"></a> response to make it <a def-id="cors-same-origin"></a>.
     </p>
-    </section>
+      </dd>
 
-    <section id="mixed-content">
-    <h4>Mixed Content Limitations</h4>
+      <dt id="mixed-content">Mixed Content Limitations</dt>
+      <dd>
     <p>During playback, embedded media data is exposed to script in the embedding <a def-id="origin"></a>.
     In order for the API to provide <a href="#initialization-data">Initialization Data</a> in the <a def-id="encrypted"></a> event, <a def-id="media-data"></a> must not be mixed content as defined in [MIXED-CONTENT].
     </p>
-    </section>
+      </dd>
+    </dl>
     </section>
     </section>