Block audit: Columns

[sarahmonster]

Block audit

Note: We'll be doing these audits in waves and editing this as we work through the blocks, so this text will be updated and fleshed out as we progress. See the full picture here.

Overview

Name: Columns (beta)
Description: Add a block that displays content in multiple columns, then add whatever content blocks you’d like.
Category: Layout elements
CSS class: wp-block-columns in editor and frontend
Can be converted to: nothing

Individual column block
Description: A single column within a columns block.
Advanced: Additional CSS class.

States

Empty:

Selected:

Unselected:

Placeholder:

Primary (toolbar) settings

None

Secondary (sidebar) settings

Columns (number)
Advanced: Additional CSS Class

Frontend appearance

Gutenberg starter theme:

Atomic Blocks

twentyseventeen:

twentyten:

Bugs/errors

Individual issues will be opened for these soon

• Selecting elements (especially the RIGHT element) is very confusing. (Selecting column elements is very difficult/confusing #15975)

• The sub-block toolbars spill out of frame, making some tools inaccessible.

• Responsiveness is sub-optimal. (Support for Responsive Columns #6048)

• Duplicating an individual column block leads to unexpected behaviour.

• Column block followed by another column block creates overlap.

• Base styles should probably include a gutter between columns. (Selecting column elements is very difficult/confusing #15975)

Suggestions

Individual issues will be opened for these soon

• Being able to select the individual columns maybe isn't strictly necessary. The only thing you can do with them is add a CSS class. Why not just add a CSS class to begin with?

• I wonder if this might make more sense as an option within a container/section block, rather than its own block.

• Full-width alignment here could be very nice.

• Empty and placeholder states could use some consideration—they feel a bit confusing as it currently stands.

• Overall, this block just feels confusing across the board, and I'm not sure that putting a "beta" flag in the title helps a great deal, particularly when the entire software is still in some form of beta or another.

[buzucan]

Another bug found. If I add some info in columns and after that I will save the info to a reusable block when I try to use the info from the block ...all is deleted.

[ZebulanStanphill]

The Columns block should almost definitely not be part of a Container block, in my opinion. I think a Container block should focus on non-column-based layout options, like what Oxygen does:
https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/
https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

I wonder if perhaps the Column (not Columns) blocks could be replaced by the future Container block, though. That sounds like something that would make sense, assuming there are no kinds of settings that you would want to modify for an individual Column block that would not make sense in a standalone Container block.

The Columns block definitely needs to get better responsiveness before the merge proposal, in my opinion. #8979 fixes some of the issue, but not all of it. For a temporary solution until Gutenberg switches to more of a page building focus, there was discussion in #6048 of adding a toggle to enable hardcoded responsive breakpoints for the Columns block.

There are various other issues with the Columns block which have tickets open. Here is a list of some of the major ones I could find:

• Columns adding block only available on left and right seems stuck #5772
• [Columns block] Unexpected behavior while decreasing number of columns #7149
• Columns Block (beta): columns do not transition properly from 3.1 to 3.2, until after re-save #7825
• Columns Block (beta): long content in doesn't wrap and pushes editor off page #7921
• Prevent deleting blocks entirely when removing columns #9009

It should also be noted that various other issues such as the following also have a significant effect on the Columns block:

• Display block tools underneath the block, instead of to the sides #6224
• Not able to insert a new block after paragraph block via mouse action #7006
• Confusing + button behavior #7271
• Try moving block margins to each block #8350
• Inserter: sibling insertion point at top of selected block covers up part of block content #8881
• Sibling inserters should never constantly overlap the content of the selected block #8883
• Move the blocks "More" button (ellipsis) to the toolbar #9074
• Allow toolbar segments to collapse (responsive toolbar) #9075

[dionysous]

It should be possible to change the columns block to the setting "1 column" - there are many use cases where you need one column like a wrapper with a class, when you want to have an area of different color or background in the fontend.

At the moment it is not possible to drag the selector to the value of 1, but it is possible to delete the value and type "1" in the settings sidebar.

Edit: Or it could be solved with a wrapper / container / section block: #4900

[grappler]

I struggled with two things related to columns.

I created a 2 columns and added content, then I decided that I did not want to use columns but I could not find an easy way to move the block inside the columns to out of it.

As I hack I changed the number of columns to 1 using @dionysous tip and I lost all of the content in column 2 which was a bit unexpected.

[apeatling]

There is a bug where if you select a single column and set an additional CSS class, it is not added to the markup. It does however appear in the markup on front end of the site.

[erikjoling]

I'd like to add investigating the markup of the columns-block in the editor to the audit #7770

[karmatosed]

I think with all the work going on in other issues this can maybe be closed now. With that in mind, I will do that but we can always reopen.