Provide a new render element for accordion

Working on it.

First throw at adding a accordion render element.

I used the same approach as vertical_tabs does, but was considering adding process and pre-render from RenderElement class directly, maybe someone could shed a light why it is done using that intermediary details element?

We should define which behaviors are supported, think a default open item or
controlled accordion (opening an item will close all the others).
Also handling open / closed state is not implemented yet.

Some feedback would be much appreciated.

First, you're going to have to explain what "accordion list" means. I've encountered the word "accordion" used many designers and developers, who understood it to mean different things. In my experience, I always have to ask for clarification about the intended behaviour. What special difference does the "list" part make?

Adding a new render element probably doesn't qualify as minor.

diff --git a/core/lib/Drupal/Core/Entity/ContentEntityForm.php b/core/lib/Drupal/Core/Entity/ContentEntityForm.php
index 75bde9fe35..aec4885714 100644
--- a/core/lib/Drupal/Core/Entity/ContentEntityForm.php
+++ b/core/lib/Drupal/Core/Entity/ContentEntityForm.php
@@ -108,7 +108,7 @@ public function form(array $form, FormStateInterface $form_state) {
       // Advanced tab must be the first, because other fields rely on that.
       if (!isset($form['advanced'])) {
         $form['advanced'] = [
-          '#type' => 'vertical_tabs',
+          '#type' => 'accordion',
           '#weight' => 99,
         ];
       }

This is out of scope, surely? The issue summary says the scope is to add a new render element type, but this changes an actual form.

The new render element type is called "accordion" here, not accordion list.

I agree with @andrewmacpherson that it should be called accordion, not accordion list.

@andrewmacpherson Usually when we create new render elements or theme hooks its great if we can add at least one usage of that component into core. This way we can ensure that it at least works in the use case of node sidebar. Given that, in my opinion, making node form sidebar use accordion would be nice to include in the scope of this issue.

Re. #8;

I agree with @andrewmacpherson that it should be called accordion, not accordion list.

I didn't actually say what it should be called. Rather, I was asking for clarification about what both terms mean.

I ask because in my experience accordion is used to mean various different things, and there's confusion around the expected usage and behaviour. When I'm told there's going to be an accordion, I always have to ask what sort of accordion they mean. Here are some of the assumptions that I've encountered before:

1. A single collapsible disclosure grouping. Basically another name for the details element.
2. A sequence of details elements.
3. A sequence of details elements, with special styling to convey that these details elements are somehow related to each other. Usually this comes as a visual design detail, and it isn't clear how screen reader users are supposed to understand the relationship.
4. A sequence of details, where any can be open/closed at a given time.
5. Or, constraints about how many can be open at a given time: 0-1, 1 or more, exactly 1, etc..
6. More than one can be open at once, but only if they are adjacent. (Bizarre IMO, but I've heard this described as the defining feature once.)
7. A sequence of details, with additional keyboard behaviours so users can move focus from summary to summary, bypassing interactive content in an open details. The WAI-ARIA Authoring Practices includes this as an optional behaviour, but doesn't say what situations it is suitable for.
8. A sequence of disclosure elements like details, but with an additional semantic that the clickable titles are headings (h1-h6) in the document. The WAI-ARIA Authoring Practices pattern does this.
9. EDIT: sometimes accordion refers to a sequence of details elements, where any number can be open/closed, but the total space available must be shared between them. The jQueryUI accordion demos include this scenario.

So what is the new render element being proposed? What does it mean, and how does it behave?

The issue summary says it would replace the node entity meta, which is currently a details element nested inside a vertical tabs container. The Seven theme alters both of these to be plain containers. Is this proposing to remove vertical tabs fron the node module, or is it just for Seven's form alter?

Rerolled patch to 9.1.x.

Fixing test cases!

I believe, for this patch to be tested, support for this render element needs to be added to the field group module. This is the issue for that: https://www.drupal.org/project/field_group/issues/3244774, it looks like some more work is needed there to make this happen.

Fixed failed commands on #17
Attached patch against Drupal 9.5.x

This issue is being reviewed by the kind folks in Slack, #need-reveiw-queue. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge require as a guide.

Tagging for IS updates as there are some todo's to fill in.

Also tagging for tests.

Could this be a duplicate of #3062136: Create a details/summary FieldFormatter plugin for text fields. though?