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 Don't force <details> to be a block. #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.

• 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: …
• 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.)

[annevk]

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.

[annevk]

Should we recommend here that it follows from the node's language? I think that's what we do for form controls today even though it's not (yet) implemented?

[dbaron]

This matches the current wording for the default text of submit/reset buttons and (except for "possibly" versus "probably") the text of the "Choose file" button in <input type=file>. The only wording I found that seems like what you're thinking of was the wording about presentation of dates, times, and numbers. This seems more similar to submit/reset and to the file chooser button than it it does to presentation of dates, in that it feels a bit odd to make this differ from those.

[annevk]

I suspect that when we changed the wording for dates, times, and numbers, the button language was overlooked. But I guess we can sort that out in a follow-up.

[annevk]

Should this also be mentioned in HTML's Selectors section?

[dbaron]

I'm not sure. The one existing pseudo-element (::file-selector-button) is not currently mentioned there. It seems like it might be useful to mention the pseudo-elements in that section, but it also seems like maybe (unlike for the pseudo-classes) if we do so, perhaps the pseudo-elements part of that section should be more like an index than the location of the formal definition?

[annevk]

Yeah, I guess that's correct. In which case maybe it's not worth it.

[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?

[domenic]

Editorially LGTM. Happy to merge when we have the checkboxes filled out. Let us know if you have other people (e.g. @emilio) whose reviews you want to block on before merging.

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

[emilio]

You can probably use :host > summary for parallelism with the rule below right? (or just summary?)