Replace Accordion with Details and Card

[eirikbacker]

Reasoning in #2364 (comment)

---

Description

• Any opinions on Accordion often being used with only one Accordion.Item? Today we require that Accordion.Item is always wrapped in a grouping component, but can it occasionally not be a group? ☺️ See other systems operate with slightly different solutions; some call it Collapsible or Expandable so it is less related to it being in a group context.
• And, there is currently no way to set that only one should be open at a time - all Accordion.Items can be opened and closed independently of each other, but maybe that is the intention? ☺️
• Hover behind chevron: this is a design choice - marked that the designers in the Norwegian Food Safety Authority were confused by whether it was a UU requirement, but thoughts about hoover should be kept on only the chevron, or possibly the whole field?

Feedback from @Thunear :

• I am often uses accordion with only 1 item on several different websites in the Digdir universe e.g. in the table of contents.
• Will create an admin interface in the near future where I want only 1 accordion item in the left menu to be open at a time. Should perhaps be part of the component?
• Hover on Chevron feels a bit weird, we should consider moving hover to the entire surface.

Response from @eirikbacker:

Agree - then think that Expandable is perhaps a better naming convention, as Accordion gives the expectation of grouping and one open at a time. I also think that Expandable can be used without any wrapper around it - it is entirely possible to get rounded edges etc. with pure CSS that looks for the previous and next element, so that:

<p>Some text before</p>
<Expandable>...<Expandable>
<Expandable>...<Expandable>
<p>Some text after</p>

will "connect with each other" and run as a group, while

<p>Some text before</p>
<Expandable>...<Expandable>
<p>Some text between</p>
<Expandable>...<Expandable>
<p>Some text after</p>

rendered separately.
The only annoying thing is that you then have to color each Expandable:

<p>Some text before</p>
<Expandable color="brand1">...<Expandable>
<Expandable color="brand1">...<Expandable>
<p>Some text after</p>

Alternatively, we can offer an Expandable.Group to have a quick way to wrap everyone, but that it is optional. It can be nice, but also a little assessment of how much we should do for people, because they will anyway often loop over content when they generate such groupings, and then they can put props there immediately (a bit the same as we landed on in ToggleGroup).

Regarding one open Expandable at a time; If we implement on top of native <details>, we can offer name="..." to group - when several Expandables have the same name, they are automatically linked together - in exactly the same way as input type="radio" works :relaxed :

[eirikbacker]

Related to #2363

[mrosvik]

ARIA skiller mellom "Accordion" og "Disclosure": https://www.w3.org/WAI/ARIA/apg/patterns/

[eirikbacker]

...og HTML kaller det details - "the details disclosure element"
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
Se også første notis fra W3C spesifikasjonen: https://html.spec.whatwg.org/multipage/interactive-elements.html#the-details-element:the-details-element-2

[Barsnes]

If anything, I suggest going for Collapsible, if we don't want to use Accordion. Could also just use the native name for this, which I feel is the best option.

it is entirely possible to get rounded edges etc. with pure CSS that looks for the previous and next element, so that:

Yes, but what if the accordion is in a layout that adds gap between elements? We can't ensure that we can remove the spacing.
I suggest we still have a *.Group, to remove any confusion and possible issues.

Ref for Collapsible:
https://www.radix-ui.com/primitives/docs/components/collapsible
https://getbootstrap.com/docs/4.0/components/collapse/

[eirikbacker]

Agreed ☺️ Like the .Group, and both Collapsible and Expandable are good alternatives in my opinion

[mimarz]

Why not call the Collapsible/Expandable for Details since we are using the details element?

Thinking out loud here:

For single use:

<Details>
  <Details.Summary> // or just <Summary>?
  …
<Details>

Now, if you want it to act like an Accordion

<Accordion>
  <Details>
  <Details>
  <Details>
</Accordion>

What do you guys think?

[eirikbacker]

That could work 🙌 It correlates nicely with details / u-datails for HTML-users as well.
I think we might want Details.Group though?
Just a thought then; should Accordion also affect the behavior or only design?
In pure HTML, if the user wants only one details open at the time, they should add matching name to all <details> elements - aka. the "Accordion" wrapper does nothing to change behavior, it only affects design.

In React though, we can use context to add single/multiple open-at-the-time logic to Accordion: <Accordion multiple> vs <Accordion>, but this would then be a deviation between React/HTML. Also; one open-at-the-time should be avoided, so maybe it is okay to require actually setting name in React as well?

[mimarz]

That could work 🙌 It correlates nicely with details / u-datails for HTML-users as well. I think we might want Details.Group though? Just a thought then;

What would the Details.Group do?
We have no .Group sub-components now.
We moved away from .Group on Checkbox and Radio in favour of hooks.
First though here is we need to keep consistency with component usage/api.

should Accordion also
affect the behavior or only design? In pure HTML, if the user wants only one details open at the time, they should add matching name to all <details> elements - aka. the "Accordion" wrapper does nothing to change behavior, it only affects design.

In React though, we can use context to add single/multiple open-at-the-time logic to Accordion: <Accordion multiple> vs <Accordion>, but this would then be a deviation between React/HTML. Also; one open-at-the-time should be avoided, so maybe it is okay to require actually setting name in React as well?

Yeah, my though aswell. Accordion is just visual sugar and we expect people to use the "native" Details the way its meant to. If we want to provide some more DX, maybe a useAccordion hook, the same way we have for useRadioGroup which applies name on Radio.

Suggest we first try the most simplest approach, and then we can see how the DX feels and iterate on that.

[mimarz]

Meeting 22.11.2024 with @eirikbacker @Febakke @mimarz

We decided to try the following in regards to Accordion.

• New component, Details and Details.Summary
  • This component reflects the native details and summary element
• Accordion will be removed in favour for composition of Details and Card
  • The only thing Accordion really did was a div with border and rounded corners around a list of <details> elements
  • Accordion without border can be achieved by just listing Details components
• Accordion.Content will be removed and styling moved to Details
  • Animation might not work on some browsers but thats an okay tradeoff than having a superfluous Details.Content
• Add stories to both Card and Details on composing them to make them behave like an accordion, with use of name

New Details component

<Details>
  <Details.Summary>
  …
<Details>

New approach for equivalent <Accordion>

<>
  <Details>
  <Details>
  <Details>
</>

New approach for equivalent <Accordion border>

<Card>
  <Details>
  <Details>
  <Details>
</Card>