🌟Feature request: Accordion should use details/summary

[alexbjorlig]

Is your feature request related to a problem? Please describe.
If the accordion remove elements from the DOM, it's not very good for form elements.

Describe the solution you'd like
Details/summary instead.

Describe alternatives you've considered
N/A

Additional context
Details/summary have some cool features on Chrome/Edge, where they will auto-open when the user searches for something on the page.

[TGlide]

I'm not sure if I can promise that'll we'll use details summary, but I'll try! In any case, we should solve the form issue.

[alexbjorlig]

What's the argument for not using details/summary - just trying to understand. From what I understand, details/summary is exactly what an accordion is. But I might miss some perspectives.

[TGlide]

What's the argument for not using details/summary - just trying to understand. From what I understand, details/summary is exactly what an accordion is. But I might miss some perspectives.

We're overriding a lot of custom behaviour in our components to provide custom controls, kbd navigation and accessibility, so I worry about compatability. Same reason why we don't use a <dialog /> element on our Dialog component.

[AndreasHald]

I understand your concerns @TGlide, maybe it won't work - however I just wanted to chime in to say that if it could work, it would be amazing for progressive enhancement as well, since it would work even without js loaded

[TGlide]

I understand your concerns @TGlide, maybe it won't work - however I just wanted to chime in to say that if it could work, it would be amazing for progressive enhancement as well, since it would work even without js loaded

I agree with the benefits. I'd really like to address progressive enhancement at some point, per issue #103. I'm a big defender of progressive enhancement, and try to apply it whenever I can, but it's a bit tough with a library like Radix. Nonetheless, it'd be nice to have a discussion around it, at least.