Ability to style default summary in <details>

[jakearchibald]

<details>
  Hello!
</details>

Unless I'm missing something, there doesn't seem to be a way to style the auto-generated <summary> for <details>.

Should we add something like this:

details::default-summary {
  /* … */
}

That also means the styling of the <summary> can move entirely into the UA sheet:

details > summary:first-of-type,
details::default-summary {
  /* … */
}

[bkardell]

Just out of curiosity, why limit that to the 'default summary' instead of making it apply to the 'active summary' (ie, whatever the part internally playing the summary role is). I don't have a good name for that, so I'll just use ::summary-part to illustrate what I mean..

The UA sheet would just be:

details::summary-part {
  /* … */
}

And so would most actual stylesheets, I expect.

If that makes any sense, it needs a better name.

[jakearchibald]

I couldn't think of any other case where a pseudo-element selector selected something that wasn't a pseudo-element, or shadow DOM.

[bkardell]

I guess I was suggesting that maybe it isn't the <summary> you want to style after all but kind of the (inspecting the chrome shadow dom anyway) details-summary slot, and we'd expose... basically that (handwavingly)

[jakearchibald]

Yeah, that could work. I see the appeal of having a single selector for it. Not sure what to name it, but I'm sure there's a name out there.

[zcorpan]

This seems reasonable to me. You should probably file an issue for the CSS WG as well. cc @whatwg/css

[jakearchibald]

We may as well, at the same time, expose the details content. It'd be nice to allow CSS to override the open/close state.

[scottaohara]

That seems like it could create misalignments with how the details summary could expose the content as in the collapsed state, but it would actually be shown. And vice versa.

Likely could be done, but just needs to be on the checklist of things to do if allowing that

[nt1m]

We may as well, at the same time, expose the details content. It'd be nice to allow CSS to override the open/close state.

#8884

[jakearchibald]

@scottaohara fwiw, <dialog> already has these misalignments. You can display a closed dialog.

[scottaohara]

@jakearchibald true, but there is no native HTML element that triggers a dialog that would expose an expanded/collapsed state. So not a 1:1 comparison with details/summary where if you make the contents of the details visible by CSS then the state communicated when someone interacts with the summary element would also need to change based on this modification.

[dbaron]

Given that all major engines (Chromium, Gecko, WebKit) implement details in terms of shadow DOM, it's also possible we could do this by moving towards (a) standardizing that shadow DOM (or the necessary aspects of it) and (b) exposing parts that could be styled using ::part() (as selectmenu does).

(Also see an explainer I'm working on about improving stylability of details.)

[annevk]

I'm not sure there's agreement that. In particular I find it rather inconsistent with existing elements to use userland shadow tree APIs. The internal shadow tree is defined already (in the Rendering section) and defining built-in pseudo-elements for it as suggested upthread seems reasonable.