Size Change: +4.93 kB (+0.26%)

Total Size: 1.92 MB

_{compressed-size-action}

I plan to follow up with some design and UX improvements, and will mark the PR ready for review after that.

@jffng Picking up convo from over here.

do you still think h4 or h5 is best for the default, or can we keep it h3?

I polled some other designers who regularly build sites, and the vote was to keep it an h3 (although both work IMO). I have a feeling h5 will most likely be too small in most themes.

Also something to consider is when this setting is enabled and multiple accordion items are open by default, clicking any open section actually closes all of them.

Yeah, although this is a bit weird, it makes functional sense, and should be included in the wording. What about this for the Accordion Group language:

Toggle: "Auto-close"
Helper text: "Automatically closes accordions when a new one is opened."

Flaky tests detected in 43dc276.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/16940178291
📝 Reported issues:

• [Flaky Test] correctly applies dynamic allowed blocks restrictions #51220 in /test/e2e/specs/editor/plugins/inner-blocks-allowed-blocks.spec.js

Just noting that it would be good to make the Heading level attribute extensible as we recently did with other Core blocks that use the HeadingLevelDropdown component.

Here's the original PR for reference: #63535

From my POV this one is ready! Just needs a good code gutcheck.

One piece of usability feedback: The only way I could discover to add another Accordion to the group was using the [+] appender. I wonder if its also worth surfacing an action for that in the Block Toolbar, but this is probably best as a follow up if others give similar feedback.

Can use similar vernacular, potentially, as what exists for the Gallery block:

"Add". Or "Add group".

Good idea, thanks both. I like the idea of adding an "Add" button to the toolbar. Maybe this could be done in a follow-up PR, as this one is already quite big.

The block works wonders! Amazing updates @mikachan! I only have a question on extensibility.

Have we considered using a Heading block inside the Accordion Header? By doing so, we won't have to worry about styling the heading anymore. It also paves the way for extenders to customize the header content.

There is one use case that comes from WooCommerce: previously, with the classic theme, we used a tab for product details and displayed the number of reviews in the tab title of the review tab. Recently, we introduced a new accordion layout (which is a clone of this block), but we can't show the number of reviews in the accordion header because it's a static string set in the editor. If the Accordion Header block supports inner blocks, we can solve that issue nicely with a custom block. I will have the same need if I wrap the Comments block inside an Accordion.

Have we considered using a Heading block inside the Accordion Header? By doing so, we won't have to worry about styling the heading anymore. It also paves the way for extenders to customize the header content.

The main challenge is that it might make it easy to create incorrect heading level hierarchies in the DOM. E.g. usually your post title is an H2, so we can default H3 in the accordion, which should make it match in most cases. However then you insert an accordion on your homepage, where perhaps the site title is an H1, then you'll have a missing level in-between.

This is usually the reason to not use heading blocks in compound blocks, because you have to choose a heading level and often times that can cause conflicts. Whereas using just a paragraph block will enable any styling, even to match headings or intentionally diverge, and it will never cause such hierarchy conflicts.

The block does use heading elements, so we already have that challenge. I believe the reason for not using the Heading block is that it doesn't allow inner blocks, and we want to toggle to open and close the accordion using the heading element. This is so we could use the same semantics as https://www.w3.org/WAI/ARIA/apg/patterns/accordion/examples/accordion/ and https://designsystem.digital.gov/components/accordion/

That's valid enough. Another thing on the radar is a "linting tool", a la VS Code, but for the block editor. It's not a new idea and likely exists in an issue in the archive somewhere.

This would provide an interface for flagging warnings, errors, and notice level bits. Incorrect headings should be flagged as errors, and could well show up in a pre-publish dialog, as well as the document outline. I.e. if an error is shown, we’d show an unread dot on top of the List view button (which serendipitously would be similar to the unread dot here), alerting you to the issue.

That's valid enough. Another thing on the radar is a "linting tool", a la VS Code, but for the block editor. It's not a new idea and likely exists in an issue in the archive somewhere.

This would provide an interface for flagging warnings, errors, and notice level bits. Incorrect headings should be flagged as errors, and could well show up in a pre-publish dialog, as well as the document outline. I.e. if an error is shown, we’d show an unread dot on top of the List view button (which serendipitously would be similar to the unread dot here), alerting you to the issue.

I was thinking about this too. It would need the context of the whole template, if editing on the post editor, but it would be really helpful!

Yes, this would be a global linting system for anything, not just pieces here or there. Choosing the right heading levels is not a challenge unique to just one block. The system could also flag in the three levels many other things that would be good to know about, whether failing contrasts, missing or even dead links, blocks in a setup state, hidden blocks, etc etc. The system should also be extensible, so potentially SEO plugins can use an official API to provide suggestions.

But to be clear, I would not think of this system as a blocker for the accordion to land. This idea has been around for years at this point, and although its potential value keeps going up, it hasn't yet been more important than many of the other shortcomings we mean to address, including this block itself!

Yes, this would be a global linting system for anything, not just pieces here or there. Choosing the right heading levels is not a challenge unique to just one block. The system could also flag in the three levels many other things that would be good to know about, whether failing contrasts, missing or even dead links, blocks in a setup state, hidden blocks, etc etc. The system should also be extensible, so potentially SEO plugins can use an official API to provide suggestions.

But to be clear, I would not think of this system as a blocker for the accordion to land. This idea has been around for years at this point, and although its potential value keeps going up, it hasn't yet been more important than many of the other shortcomings we mean to address, including this block itself!

yes yes, I didn't mean to derail this PR :) I would love to see this happening though, I hope we can prioritize it soon enough

There is one use case that comes from WooCommerce: previously, with the classic theme, we used a tab for product details and displayed the number of reviews in the tab title of the review tab. Recently, we introduced a new accordion layout (which is a clone of this block), but we can't show the number of reviews in the accordion header because it's a static string set in the editor. If the Accordion Header block supports inner blocks, we can solve that issue nicely with a custom block. I will have the same need if I wrap the Comments block inside an Accordion.

I think the biggest issue with allowing inner blocks inside the Accordion Header is that it could disrupt the semantic markup of this block. However, I'll have a think about how we could address this. Maybe we could allow appending string content to the existing header string.

Thanks for all the feedback! I'll get this merged, and then we can start addressing the follow-ups:

• Add an "Add" button to the toolbar to easily add another Accordion Item
• Think about how to append content to the Accordion Header content

Thank you everyone!

Think about how to append content to the Accordion Header content

@mikachan I think we should make it not only appendable but also adjustable. Additionally, what we do here should also be applied to the Tab block. This is an interesting problem to solve btw. I can think of one way to do it is using block variation, for example, a Review Accordion Header variation to be used with the Reviews block, then filter the block content server-side before sending to the client. It's far from perfect, though, even hacky, but at least something doable right now.

Hello,

Not sure where the appropriate place to bring this up, but would there be plan to integrate or make this block transformable from/to post-template block? There are FAQs post types that would be nice to make them accordion inside a query loop.

@sntran It's usually best to open a new issue for feature requests like this. This sounds like an interesting idea, especially for FAQ patterns.