Specify the rendering of <details> in more detail.

[dbaron]

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 last child with a note that the order is not observable.
• 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; see bug 157323.)
• It removes the restriction that <details> is a block and cannot be changed. This is prototyped in Chromium and Gecko. This fixes #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 https://github.com/w3c/csswg-drafts/issues/9879 and https://github.com/w3c/csswg-drafts/issues/9951 for more background.

• [ ] At least two implementers are interested (and none opposed):
  • Chromium, see issue 40068507
  • Gecko has shown partial interest based on bug 1856374 but that's only a piece of this.
• [ ] Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-001.tentative.html
  • https://wpt.fyi/results/html/rendering/the-details-element/details-display-type-002.tentative.html
  • https://wpt.fyi/results/html/rendering/the-details-element/details-pseudo-elements-001.tentative.html
  • https://wpt.fyi/results/html/rendering/the-details-element/details-pseudo-elements-002.tentative.html
  • Note: still needs additional tests and PR to make non-tentative
• [ ] Implementation bugs are filed:
  • Chromium: issue 40068507
  • Gecko: partly covered by bug 1856374 but needs an additional bug
  • WebKit: …
• [ ] MDN issue is filed: …
• [X] The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/rendering.html ( diff )

[dbaron]

Sorry, apparently Shift-enter submits the form, I wasn't quite ready to submit and I'll continue editing the above comment.

[domenic]

• 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.

Are these differences observable? If not, then perhaps the spec can be clearer about that, so that people understand any implementation strategy that achieves equivalent results is fine.

[dbaron]

Are these differences observable? If not, then perhaps the spec can be clearer about that, so that people understand any implementation strategy that achieves equivalent results is fine.

That's a good question. When I wrote it I was (for some reason) thinking that the ordering was observable via selectors, but now that I think about it again I think it's not. We do need to get the exact CSS definitions of what does and doesn't apply sorted out, though, to make sure. But I think as long as (a) link or style in the shadow tree are display:none and can't be changed and (b) the relative positions of the elements in the shadow tree can't be determined by selectors, then I think it's not observable. (The relative positions of displayable elements in the shadow tree can be determined by layout differences, probably most easily with display: grid.)

[dbaron]

Are these differences observable? If not, then perhaps the spec can be clearer about that, so that people understand any implementation strategy that achieves equivalent results is fine.

Can we describe it as two child elements and an associated style sheet? It seems like it should be immaterial how the style sheet is associated with the shadow tree. It just needs to have one.

I've revised the change to go mostly in this direction: I still describe the style as an element, explicitly note that the order isn't observable, and note that its association using an element isn't observable either (although I don't know what other standard mechanism we'd describe the styles with). I also now describe it as the third child rather than the first, since in hindsight it seems nice to use "first" and "second" for the first and second rendered children. But I didn't go so far as to just handwave about how the association is made. Does that seem reasonable?

[emilio]

I've revised the change to go mostly in this direction: I still describe the style as an element, explicitly note that the order isn't observable, and note that its association using an element isn't observable either (although I don't know what other standard mechanism we'd describe the styles with).

Adopted stylesheets would be an option fwiw.

I also now describe it as the third child rather than the first, since in hindsight it seems nice to use "first" and "second" for the first and second rendered children. But I didn't go so far as to just handwave about how the association is made. Does that seem reasonable?

Works for me.

[dbaron]

One substantive thing that I'm thinking of changing here: right now the ::details-content is a pseudo-element that addresses an element that is internally a <slot>. <slot> elements default to display: contents. This is somewhat inconvenient since some styles don't work on elements that are display: contents. So I think probably it should be display: block by default all of the time (rather than only when it's hidden).

(This has tripped me up multiple times while writing examples, and I think it's probably better to change it if it doesn't break anything, which I don't think it will.)

[bramus]

I think probably it should be display: block by default all of the time (rather than only when it's hidden).

In all my experiments (here, here, and here) I have done this, so +1 on using display: block by default.

[dbaron]

I think this is ready for another look. There are a few additional changes since the last round of reviews; the draft commit message above is updated to reflect them.

(There's one checkbox still unchecked, but that's just because I'm waiting to make a PR to make the tests not tentative until the last tentative test lands, hopefully later today or Thursday.)