Proposal for improvements to <details> styling

[dbaron]

I've written a (still rather vague) proposal for improvements to <details> styling, which is somewhat related to the proposal in #725. I'm interested in thoughts (probably here rather than in that repo) for what folks think about these ideas.

[brechtDR]

I gave it a read, really interested in hearing other peoples thoughts about this.

As for me, I really like the proposal for using :part() for this. It feels consistent with the selectmenu terminology.

I do believe Improved ::marker styling could work as well, but this might cause some issues.
I believe a lot of developers added some styling to ::marker that just doesn't work and left it in there. Not sure if this is something we need to take into account(?). Still wanted to raise a potential issue there.

Another mention i'd like to give: A much-asked feature for developers when it comes to the details element is the need for better animation control. Animating / transitioning to auto height might be needed for this. ( if i'm not mistaken, the CSSWG is working on that). As for the moment, developers need to rely on JS for this.

[dbaron]

Discussed in today's OpenUI telecon (but github-bot had an error when trying to comment because github was partly down at the time of the call... or when I first tried to add this comment earlier today)

[brennanyoung]

I had a look through this. I'd like to make sure that a very common use case would be supported in any implementation. Namely "spoiler" content (very common in discussions about games and fiction), and also "NSFW" content, both of which are semantically very similar to what is offered by details/summary.

The most common idiom for "spoilers" and "NSFW" content is to show the content box for the hidden element in an obscured but visible style, e.g. black text on black background, so that the content is not visible until it is clicked. Images are often shown as blurred or greyed-out. These spoiler widgets found on the web are often "home cooked", do not use details/summary, and rarely show consideration for assistive technology users - screen readers can usually read the hidden content, which is a design failure.

Implementing "spoilers" and "NSFW" content using details/summary would require that the details should be available for styling, even when the widget is not open. Currently not possible on most platforms. AT users would benefit from spoiler/NSFW widgets built around details/summary.

So, the exact presentation of the details content when not open, should be up to the content author, although simply hiding the content is still good as the default.

Please make sure these use cases are considered in any implementation.

[jimmyfrasche]

details/summary cannot be used inline. there is a thread for spoilers: #772

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[Que-tin]

Are there any news on the work that has been done here?

I stumbled across a problem with animatability last year and @una referenced this proposal after talking to Joey Quote:

david baron has been working on improvements to the details elements and i think that making this animatable is one of the things he was considering investigating."

[dbaron]

I think much of the discussion at this point has moved to w3c/csswg-drafts#9879 and whatwg/html#10265 for the CSS and HTML parts of this respectively. There's also the separate work on calc-size() (see explainer for details) which can be used for open/close animation.

Sorry I missed #744 (comment) earlier. With the current proposal providing an alternative "closed" style should be possible with something like this (which I just tested works in Chrome's prototype):

details:not([open])::details-content {
  /* override the default styles */
  content-visibility: visible;

  /* provide new styles */
  filter: blur(10px);
}