This adds a new block for creating columns of text (serving as the basis for eventual generic columns).

@afercia wonder how you think we should announce navigating between columns.

Do we really want this block? Will it be "deprecated" by the introduction of nested blocks in V2?

Do we really want this block? Will it be "deprecated" by the introduction of nested blocks in V2?

It may or may not be deprecated, and your question is a good one!

We've been over how difficult it is to get columns right, and also how already today third parties can build this. We may very well want an entirely different implementation than this one. But perhaps it's good to get this in now and test it. Perhaps this can help inform how a better column implementation can work down the road. In fact we might want to merge this block in now, only to take it back out later again, same as the Cover Text block.

For that reason, I think it'd be good to test this.

Yes, this adds value right now with the ability to do columns of text—which is a very frequent request—while allowing us to see what works or doesn't in column editing.

wonder how you think we should announce navigating between columns.

@mtias ideally: First column, Second Column, Third column... 🙂
Programmatically maybe a bit easier: Column 1, Column 2, Column 3...
(maybe better also considering space constraints?)

I realize I made a mistake in not CC'ing @melchoyce and @westonruter on this, as it clearly touches customization. Sorry about that! Will do better next time.

Codecov Report

Merging #2117 into master will increase coverage by 0.09%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #2117      +/-   ##
==========================================
+ Coverage   23.82%   23.91%   +0.09%     
==========================================
  Files         147      149       +2     
  Lines        4563     4608      +45     
  Branches      774      782       +8     
==========================================
+ Hits         1087     1102      +15     
- Misses       2934     2960      +26     
- Partials      542      546       +4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73858e5...5eac883. Read the comment docs.

Just tested this in a theme and it's awesome to see:

If this does make it into 1.0, do we have any plan for migrating it to a more robust set of columns in the future? This isn't necessarily how I imagined columns working once we start to work on creating layout tools.

What did you have in mind for the more robust set? In terms of markup, I don't think we'll have any issue as it sort of already accommodates nesting. In any case, we'll have many ways to migrate to something else.

For example, being able to add a heading and maybe an image to each column via the same block interface. This is especially important on smaller screens, so the columns tile correctly.

This might be considered more of a "generic" column/layout controls feedback. But overall it misses things like @melchoyce mentioned, additionally I would think users should have the ability to define column widths, have the ability to reorder columns etc. This is one area we're always iterating on with Mesh

Image Link if it doesn't load above

Obviously Gutenberg tackles this differently than our little plugin but once you have columns the users expectations change slightly. We set the expectation of a grid system so we lock width to a default 12/col grid that can be filtered. So the snap you see in the .gif is related to the 12 column layout

For example, being able to add a heading and maybe an image to each column via the same block interface.

Sure, this depends mostly on how we want to handle the UI for nesting in general. In terms of the columns, it wouldn't change anything structurally, s there should be no problem transitioning. The current markup is a section with wp-block-column divs—within those we support "Editable" alone, but in the future we can support whatever.

@westonruter let's keep this in mind ^