Csswg-drafts: Ability to style <details>/<summary> to be open (e.g. for print styles)

[patrickhlauke]

(Not quite sure which spec this would relate to specifically, sorry)

If a page uses <details>/<summary> expand/collapse blocks, there currently appears to be no way to open these via CSS. This poses problems for print styling: if I wanted to have these blocks appear open when printed, it seems that the only solution is to first run JS over the document and add the open attribute on the <details>.

[patrickhlauke]

/cc @tabatkins @fantasai

[Heydon]

Would be great it was specified to be open for print media by default (which I guess is what you mean?)

[patrickhlauke]

Either that, or have some way to control it (like you'd want to control any other aspects when making decisions on how something should appear when printed). Currently, it's "style-resistant"...

[Heydon]

Aye, probably both.

[iandevlin]

Nice idea.

[upsuper]

I'm thinking about whether it is possible to describe the behavior of <details>/<summary> in CSS rather than having them being HTML rendering magic.

The most straightforward approach might be defining a new pseudo-element (something like ::details-content) for wrapping content in <details> other than the effective <summary>. But generally, browser vendors would be against adding this kind of pseudo-element wrapper, because they can bring lots of unnecessary complexity.

Maybe we can have that pseudo-element, but only allow display property with none or contents. This should make it easy to implement, I suppose.

[tabatkins]

I'm down with that approach. The UA stylesheet is then extremely trivial:

details::details-content { display: none; }
details[open]::details-content { display: contents; }

And overriding it is super easy. :+1: from me.

[AmeliaBR]

+1 to any strategy that makes it possible to describe the behavior of <details>/<summary> in standard CSS. It would make it much more useful in responsive design (e.g., for a collapsible menu) if you could auto-expand (and optionally hide the toggle <summary> button) when there is room for the full content.

Another way to approach this would be to have a generic selector for anonymous text nodes.

So the default style rule for <details>/<summary> would look something like:

details:not([open]) > *:not(summary),
details:not([open]) > *text* {
  /* any direct child elements other than summary, or any direct child text nodes */
  display: none;
}

There are other cases where it could be useful for authors to override default HTML renderings for anonymous text nodes, like <meter>/<progress>, where the anonymous text content inside is a formatted representation of the value, but is currently never rendered in supporting browsers.

A *text* selector could also simplify other browser styles, e.g. the way MS Edge adds a solid-color background to all anonymous text spans in high-contrast mode.

[js-choi]

@AmeliaBR I had been planning to propose pseudo-elements for anonymous text boxes, first to the WICG then eventually here. For instance, a pseudo-element for anonymous block boxes would be generally useful in other cases as an approximate analogue to HTML’s paragraphs, e.g., anonymous-block “paragraphs” such as those in <h1>First block</h1> This is the <em>second</em> block in this example. <p>This is the third.</p> <ul> <li>Fourth.</li> <li> <p>Fifth.</p> <p>Sixth.</p> </li> </ul>. Such pseudo-elements, however, might have broad ramifications for rendering performance, so I had planned on courting authors in the WICG before the CSSWG to bolster my case. This is the first mention of this idea I have yet seen elsewhere on the web, so it’s good to have another use case.

Having said all that, it is precisely the broadness in scope of such an anonymous-box selector that may make a ::details-content pseudo-element more feasible in the short term. An anonymous-box selector also may not actually match all of the non-summary content in a <details> element: <details> <summary>A</summary> <p> B <p> C </details>. I still do plan to make a formal proposal for anonymous-box selectors in general, unless someone else beats me to it.

[jonjohnjohnson]

Big fan of @tabatkins idea...

details::details-content { display: none; }
details[open]::details-content { display: contents; }

But @Loirooriol, any idea how you could make this work with your ::contents proposal? Even if the summary is a child of the details element? I know there are cases where the tree is shuffled around for layout, like display: run-in?

As an aside, could we also get a ::details-marker pseudo element in the spec at the same time? I know webkit already has their own version, but it would be great to more seamlessly style the summary (or lack thereof) taking control over the generated contents arrow/marker. Could it be possible to steal the list items marker box ::marker pseudo element for reuse? Since it seems that...

Fully standards-compliant implementations automatically apply the CSS display: list-item to the summary element

But make the ::marker available even when details has no summary?

MDN Ref - ::-webkit-details-marker

[AmeliaBR]

As an aside, could we also get a ::details-marker pseudo element

The regular ::marker on the <summary> element will apply to it.

But make the ::marker available even when details has no summary?

In that case, it makes more sense to define a pseudoelement for the auto-generated summary toggle, and allow it to have stacked psuedoelements on it:

details::details-summary::marker,
details summary::marker {
  /* styles for the disclosure marker */
}

[jonjohnjohnson]

@AmeliaBR as well as something like this?

details::details-summary {
  content: 'Details';
  display: list-item;
}

[AmeliaBR]

@jonjohnjohnson Exactly! As I said earlier in the thread, I would very much like to get to the point where all of details/summary layout & rendering can be defined with a CSS model & customized by media queries. I hadn't been thinking about auto-generated summary toggles, but they definitely should be part of that.

[Loirooriol]

@jonjohnjohnson I don't think this would be a good fit for my ::contents proposal. Here you want to select only some children of the <details> but not the <summary>. The ::wrap proposal (#588) allows this bit doesn't seem a feasible feature, since it allows authors to produce non-tree DAGs.

there are cases where the tree is shuffled around for layout, like display: run-in

But this reparenting happens in the box tree. I think ::contents should live in the element tree just like ::before and ::after, so that things stay well-defined.

Then I think new pseudo-elements for detail parts would be better.

[nickcolley]

I hope it's OK to chip in with an example of where this has stopped us from using details:

At GDS we were considering creating our new accordion component using details elements as it would allow for better functionality when JavaScript is not available, we're deciding not to use the element for now but I think if this were possible to style when printed we'd likely use it.

[tabatkins]

See also #3126, where Anne relays some requests for the ability to put ::before/::after in the contents of a details (so ::before comes after the summary, and they're both hidden when the details is closed); providing a ::details-content pseudo-element that allows ::before/::after on itself would also solve that problem.

[chbndrhnns]

I am making heavy use of these twisties for hiding diagrams or code snippets on markdown documentation pages (that get rendered to HTML). I have some styles that are activated when printing the document and for that purpose, I would also welcome a way to set <details> to open via pure CSS.