Specify the rendering of <details> in more detail.

This makes a number of related changes to specify the rendering of the
<details> element:

* It specifies the structure of the user agent shadow tree.  This
  appears largely interoperable between implementations with the
  exception of the style or link element for the default summary styles:
  Gecko uses a link element as the first child, Chromium uses a style
  element as the last child, and WebKit does not use a style element
  (see below).  This specifies a style or link as the first child.
* It specifies the existence of the default summary and the presence of
  UA dependent text inside of it.  This is present in all of Chromium,
  Gecko, and WebKit.
* It specifies the styles needed for the default summary.  These match
  Chromium and Gecko.  (These are not present in WebKit because WebKit's
  mechanism for styling the marker does not match the existing spec.)
* It removes the restriction that <details> is a block and cannot be
  changed.  This is prototyped in Chromium and Gecko.  This fixes whatwg#9830.
* It specifies that the summary element is display: block by default.
  This matches all of Chromium, Gecko, and WebKit.
* It specifies which element matches the ::details-content
  pseudo-element.  (TODO: This needs to be specified in CSS)  This is
  prototyped in Chromium.

See w3c/csswg-drafts#9879 and
w3c/csswg-drafts#9951 for more background.

source

@@ -134169,6 +134169,9 @@ input[type=image i][align=bottom i], object[align=bottom i] {
 
   <pre><code class="css">@namespace "http://www.w3.org/1999/xhtml";
 
+details, summary {
+  display: block;
+}
 details > summary:first-of-type {
   display: list-item;
   counter-increment: list-item 0;
@@ -134178,28 +134181,53 @@ details[open] > summary:first-of-type {
   list-style-type: disclosure-open;
 }</code></pre>
 
-  <p>The <code>details</code> element is expected to render as a <span>block box</span>. The element
-  is also expected to have an internal <span>shadow tree</span> with two <span
-  data-x="concept-slot">slots</span>. The first <span data-x="concept-slot">slot</span> is expected
-  to take the <code>details</code> element's first <code>summary</code> element child, if any. The
-  second <span data-x="concept-slot">slot</span> is expected to take the <code>details</code>
-  element's remaining descendants, if any.</p>
-
-  <p>The <code>details</code> element's first <code>summary</code> element child, if any, is
-  expected to allow the user to request the details be shown or hidden.</p>
-
-  <p>The <code>details</code> element's second <span data-x="concept-slot">slot</span> is expected
-  to have its <code data-x="attr-style">style</code> attribute set to "<code data-x="">display:
-  block; content-visibility: hidden;</code>" when the <code>details</code> element does not have an
-  <code data-x="attr-details-open">open</code> attribute. When it does have the <code
-  data-x="attr-details-open">open</code> attribute, the <code data-x="attr-style">style</code>
-  attribute is expected to be removed from the second <span data-x="concept-slot">slot</span>.</p>
-
-  <p class="note">Because the slots are hidden inside a shadow tree, this <code
-  data-x="attr-style">style</code> attribute is not directly visible to author code. Its impacts,
-  however, are visible. Notably, the choice of <code data-x="">content-visibility: hidden</code>
-  instead of, e.g., <code data-x="">display: none</code>, impacts the results of various APIs that
-  query layout information.</p>
+  <p>The <code>details</code> element is expected to have an internal <span>shadow tree</span> with
+  three child elements:</p>
+
+  <ol>
+   <li>
+    <p>The first child element is either a <code>link</code> or <code>style</code>
+    element with the following styles for the <span>default summary</span>:</p>
+    <pre><code class="css">:host summary {
+  display: list-item;
+  counter-increment: list-item 0;
+  list-style: disclosure-closed inside;
+}
+:host([open]) > summary {
+  list-style-type: disclosure-open;
+}</code></pre>
+   </li>
+
+   <li>
+    <p>The second child element is a <code>slot</code> that is expected to take the
+    <code>details</code> element's first <code>summary</code> element child, if any.  This element
+    has a single child <code>summary</code> element called the <dfn>default summary</dfn> which has
+    text content that is <span>implementation-defined</span> (and probably locale-specific).</p>
+
+    <p>The <code>summary</code> element that this slot <span>represents</span> is expected to allow
+    the user to request the details be shown or hidden.</p>
+   </li>
+
+   <li>
+    <p>The third child element is a <code>slot</code> that is expected to take the
+    <code>details</code> element's remaining descendants, if any.  This element has no contents.</p>
+
+    <!-- TODO: link to CSS definition when spec is ready -->
+    <p>This element is expected to match the '::details-content' pseudo-element.</p>
+
+    <p>This element is expected to have its <code data-x="attr-style">style</code> attribute set to
+    "<code data-x="">display: block; content-visibility: hidden;</code>" when the
+    <code>details</code> element does not have an <code data-x="attr-details-open">open</code>
+    attribute. When it does have the <code data-x="attr-details-open">open</code> attribute, the
+    <code data-x="attr-style">style</code> attribute is expected to be removed.</p>
+
+    <p class="note">Because the slots are hidden inside a shadow tree, this <code
+    data-x="attr-style">style</code> attribute is not directly visible to author code. Its impacts,
+    however, are visible. Notably, the choice of <code data-x="">content-visibility: hidden</code>
+    instead of, e.g., <code data-x="">display: none</code>, impacts the results of various APIs that
+    query layout information.</p>
+   </li>
+  </ol>
 
   <!-- https://mail.gnome.org/archives/usability/2006-June/msg00015.html -->