mrwweb / mrw-accordion Goto Github PK

It would be great to support both transforming from and to other blocks. I'd love to hear what people expect for this.

Transform From

My initial thought for this is that a Heading and Paragraph could both be transformed to become the accordion title.

A more advanced transform would involve a multi-block selection that starts with a heading being transformed into the accordion title and contents.

Transform To

I'm less certain on the best approach here. In some ways, an accordion best maps to a Group block containing both the Accordion title as a heading followed by all the contents. Alternately, I could just see the accordion "releasing" all its contents to a Heading (from the title) and all the contents into the editor body or accordion's parent container. However, I don't think WordPress really has a paradigm for this except for "Ungroup". I don't know if it's possible to match that behavior or not.

1. Close accordion
2. Change alignment (there are probably other things that trigger this too?)

Result: Accordion reopens

Expected Result: Accordion remembers current state

Options under consideration:

• Block Pattern(s)
• Block Variation(s)

https://www.nngroup.com/articles/accordions-complex-content/

Because of various progressive enhancement things I'm doing, the default plugin styles have moderately high specificity. I think the best path forward is to use some custom properties so it's easier to change the styles, especially the colors and the heading/button padding.

Especially in the block list view, the current accordion icon (downward caret) doesn't look distinctive enough and blends in with the surrounding buttons (probably because it's a default WP icon):

I'm not totally sure what to change it to (suggestions welcome), but I lean toward some kind of representation of the open accordion (a simplified version of this?)

Right now, once a font-size for the heading is selected there's no way to remove that size and re-inherit the default size of the heading. This should be possible!

• Relevant: WordPress/gutenberg#23377

It would be nice to support basic expanding and collapsing in the editor both so it matches the front end experience more closely and increases confidence that the tool works. However, it can't perfectly match the front end behavior since the heading must remain editable and doesn't contain a button.

Once #20 is dealt with, the block won't be using Block Styles, which I think may be for the best. However, I could imagine some interesting block styles might be fun in the future. If you have any specific ideas, leave a comment!

As of 13 Dec 2021, there is a single "Plain" block style that removes the background and border.

To reproduce:

1. Create a new accordion block
2. Give the accordion heading text containing a "&"
3. Observe that the front-end now shows the duplicate heading

• Upgrade edit() function to use useInnerBlockProps()
• Update minimum WP version in readme to 5.9

Implementation details

When JavaScript is off, hasn't executed yet, or fails to execute, the accordion icon is still visible. I should do my best to hide that icon without an excessive FOUC when it gets added in.

I think it's PanelColorSettings

Use this tutorial.

It would be great to use withColors as it describes.

Sites are quite likely to want to standardize a few things:

• Heading level / font-size
• Color
• Alignment?

Ideally, these defaults could be set site-wide as options. However, using a block variation with isDefault would allow developers to immediately do this.

After attempts with both a full save function and dynamic blocks, I'm thinking the best approach is a hybrid one where the basic fallback markup is added to the editor but not the full on version with classes, icons etc. That way, if the block fails, transforming to blocks will save all content and the heading.

Component source.

Off the top of my head, it'll be something like this.

import { HeadingLevelDropdown } from '@wordpress/components';

<HeadingLevelDropdown
    // options = [ 2, 3, 4 ] Do I need this or does it inherit my defaults? Maybe I should hardcode this for everyone given H1 is impossible
    value={ val }
    onChange={value => setAttribute('headingLevel', val)}
/>

Testing currently on a client site, it appears that the border color inline style is set but the background color class is missing. I don't know if this is specific to this theme or a general bug. Further investigation is warranted.

The accordion itself already supports alignwide and alignfull. That means that expected width of the InnerBlocks content is ambiguous and probably varies from person to person. I will probably default it to filling the full-width, but we'll see...

Related:

• WordPress/gutenberg#36057
• WordPress/gutenberg#33374

I often want to hard-code one or more of the settings this block provides. In those cases, it would be nice to allow removing the various settings from the editor interface. I think I've seen examples of this done through theme.json in settings.blocks.mrw\accordion so, for instance, I could either set a default icon that's different from the plugin default OR remove the icon setting altogether.

See also: #5 for thinking about custom expand/collapse icons

While this won't replace all the JS on the site since I still need to make the progressive enhancement-related element changes, I want to try out using the Interactivity API and this feels like almost the absolute most basic way to get started.

Currently the only icon options are controlled by a block style and the icons are base64-encoded SVGs. I'd like to switch to using real SVGs and styling them with CSS controlled by block options rather than block styles.

Ideally I'd like to provide the three most common icons (really just two) along with the option for a circle or not:

• Arrow (right when closed, down when open)
• Caret (up when closed, down when open)
• Plus/minus

This would potentially only require two SVGs (probably inlined) and then CSS to control the circle.

The SVGs should use currentColor so they match the text by default and then an icon color option would be significantly less valuable.

2nd option: Show icon on left or right

People will definitely want to be able to set custom icons for the accordion. The question is how to provide that.

Options:

• Filter
• Documented CSS pattern
• Block option
• Site-wide option

Really nice accordion! I've tested a load of Gutenberg accordion blocks and this is by far the best.

It would be great if the open/close state was saved as an attribute, and the attribute used on the front-end and edit screen on initial page load. So as an example, if an editor sets the accordion as closed on the edit screen, the accordion would be closed both on the edit screen and on the front-end by default.

Looks like the icon setting is broken.

On a page with elements with IDs that are not accordions, the following console error is thrown for [accordion-script.js:1:1488:

Uncaught TypeError: n is null

In the page I was testing, that seemed to break smooth scrolling.

That seems to correspond to this line:

'false' === n.getAttribute('aria-expanded') && (e.classList.toggle('is-open'), n.setAttribute('aria-expanded', 'true'), o.setAttribute('aria-hidden', 'false'))

Potential things that might be particularly useful:

• Set default global heading level: #7
• Set other global defaults (color, font size) - these could be handled with a block variation!
• Change block icon #5

Just for the record, I don't plan on adding "one-at-a-time" open functionality or some kind of site-wide setting for this feature. I assume that closed-by-default easily falls within the 80/20 rule as the preferred default.

Errors:

Notice: Trying to access array offset on value of type bool in \wp-content\plugins\mrw-accordion\utils.php on line 18

Notice: Trying to access array offset on value of type bool in \wp-content\plugins\mrw-accordion\utils.php on line 9

This may only happen when switching from a theme that had them?

For reference, see this blog post from the developer blog.

Here's the withColors documentation.

Once I do that, I should be able to significantly simplify get_accordion_heading_classes() in utils.php to avoid having to look up the colors again.