😍

This is ⭐️ ⭐️ ⭐️ ⭐️ ⭐️ work. STELLAR mockups, I love it. This is exactly the sort of rich layout we're hoping a block-first UI can accomplish.

CC: @melchoyce you'll want to see this for the customization focus later in the year.

For the V1 editor, I'm afraid columns like this is out of scope. That's not a "no" — rather, we need some technical foundations to be solid first, before we commit to the really interesting stuff. But it might be a V1.1, or at the very least something for the customization folks later on in the year. Even before that, it would be good to keep this UI in mind, so that perhaps a plugin can add this even earlier.

Thank you for this!

My feedback would be this starts to turn the editor into a layout tool rather than a content editing tool. Things like responsive design make layout control very difficult in CMSs and IMHO are best left to the theme designer / developer. I could certainly see options like "2-col" but actually dragging dividers to basically allow users to lay content out seems outside the scope of a content editor tool to me.

Not sure if that philosophy is in agreement with how Project Gutenberg sees itself?..

I think these are also interesting ideas for galleries. We may not want to keep the current fixed column approach and allow rows to have different amounts of columns. Just like text columns, a good gallery block sounds like something that could become very complex.

Not sure if that philosophy is in agreement with how Project Gutenberg sees itself?..

Later in this year, the customizer will be a focus:

The customizer will help out the editor at first, then shift to bring those fundamental building blocks into something that could allow customization “outside of the box” of post_content, including sidebars and possibly even an entire theme.

Columns are very likely to be part of that.

Gutenberg is for writing and laying out a post first and foremost. That's what we have to get right. But the editor is likely to share some DNA with the customizer later on, specifically when it comes to some of the blocks, and controls probably too. As such, this mockup is still helpful for the customization focus.

Very elegant solution. Feels a lot better than dropping in a bunch of column blocks, IMO. I can also see the column widths snapping into specific percentages (so 50% / 50%, or 33% / 66%, or 25% / 75%, etc.). Columns will almost certainly be a feature in the updated Customizer :)

@jasmussen glad you like it — a 1.1 version would be great too :)
@simonrjones extending WordPress further from the default Blog Posts automatically implies the need of multi-column layouts for presentation pages. I would prefer to tackle this feature upfront, rather than letting every developer do it on his own (see the multitude of page builders plugins).
@melchoyce definitely the column widths should snap to specific steps (even if that would be a 6 or 12 columns stepper).

I wonder if we can figure out a way to make column snapping theme-dependent. Something we'll want to ponder in the next couple months as Gutenberg progresses.

There should be a default both in terms of column snapping and for the CSS grid (including responsive part). Then the theme should be able to override them.

We're already working on a plugin integrated into TinyMCE Editor who share some of those behaviors — only that it's not a drag&drop block based, rather a row/column approach. It's called Gridable and it might be worth giving it a try.

+100 from me. I really like the idea of column blocks.

Is this a candidate for CSS grids?

https://css-tricks.com/getting-started-css-grid/

Thanks for the clarifications on my comments.

CSS grids would be fantastic and are a very good fit for column layouts. However, I am guessing wide browser support is some time away which may be an issue for WP (works today in latest Firefox). Some very good resources on CSS grids over at Rachel Andrew's site and some nice stuff on Jen Simmons site.

One way or another adding columns means CSS as well as HTML, so ideally we need simple and standards-based patterns for this to make it easier for theme developers. This could be encapsulated in code so a default starting point can be defined which can then be overridden (e.g. if someone wants to use Foundation to build their site so needs columns set up in the Foundation way).

I good rule-of-thumb I've heard is:

• Grid for site structure/layout
• Flexbox for content within that layout

A good article on flexbox vs. grid by Rachel Andrew: https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-grid-or-flexbox/

Based on the current browser compatibility requirements of WordPress, I think a standard "row+columns" grid as the default system (e.g. Bootstrap or Foundation) would provide the best balance between simplicity and flexibility.

I agree that the standard row + columns structure is the way to go.

It would be nice if there was the option to choose the grid system in the WordPress settings:

• Default
• Bootstrap
• Foundation
• Custom

The Default grid system would include supporting CSS (as part of the TwentyEighteen theme?), while the other options would rely on the theme for CSS. Essentially, WordPress outputs the grid classes and the theme provides the styles.

The custom option would allow you to set the class names for the row and columns. A close UI comparison for what I'm describing is the current permalink settings screen.

Multi column layouts are a must-have! At the moment, Gutenberg isn't solving any issue. You still end up with one long column of content. The whole reason page builders are so popular, and why hundreds of thousands of people are using them, is because they provide the ability to easily make multi-column layouts. Without this functionality, you're not providing any reason to use Gutenberg over a page builder plugin.

@maddisondesigns Yes, doing multi-column layouts is planned for V2. The foundational work for them is being done now in V1. In fact, the underlying parser for blocks does support nesting, but it's just that the UI for displaying nested blocks hasn't been implemented yet. See also #428.

@westonruter Great to hear that it's being planned. Would love to see it get implemented in V1 though. I'd be confident in saying that this will be one of the first things people complain about, if it gets added to core without being able to create multi-column layouts. At the moment, Gutenberg doesn't do anything that can't be done in the existing TinyMCE. Sure, it certainly looks heaps prettier and has some cool functionality such as being able to move blocks of text up and down easier, but again, this is basically just the same as copying 'n pasting a block of text in TinyMCE. A little more cumbersome, sure, but the end result is the same. I thought the major goal behind Gutenberg was to provide a significant improvement in how you can lay out content, not just to provide a prettier editor. It seems counter-intuitive having a block based interface if you can only have one block per line/row. It obviously goes without saying, I understand the extra work involved,, but I think people would much rather see this kind of functionality when it first rolls out, even if it means not getting added to core for another couple of releases.

I appreciate the excitement and urgency to wanting columns. We feel the same urgency. It's not about not wanting columns, it's purely about managing resources at this point. We will get to it, that's absolutely a meta-goal. If only we could snap our fingers and make it happen ;)

Even without columns, Guttenberg is a huge step forward and I am very impressed, but I'd agree that including them is essential for V1 and it would be worth delaying V1 until that feature is ready.

If you add the active installs for the top three page builders and the first page of columns plugins from .org you get more than 1,5 million ... and if you add in premium that is not half of it. The point is that I don't think an editor without columns meets current needs. If Guttenberg is released without columns then I'd imagine a dozen plugins would show up to add them on the first day. Then when added subsequently the user has something to manage.

Guttenberg will be wonderfully disruptive, but I'd urge that the essential building blocks are all in place. +1 to the excitement and urgency.

I'd like to challenge the notion of "needing" support for complex layouts in Gutenberg.

The proposed combination of columns and nesting is a rabbit hole that won't end until the user experience is really bad for people actually writing content. Any "full-fledged" page builder is testament to this.

Not everyone builds layouts with page builders, and having that sort of page structure in the database is very problematic. It'd be much better to focus on having a good API for extending Gutenberg and be very cautious about adding complex features to the core of Gutenberg.

@khromov - It looks like you may be replying to my comment. I'm advocating columns, not complex layouts, nesting, or a full page builder. I sometimes need columns when writing content. I refuse to use shortcodes, so I have two choices: create nested divs by hand, which is a horrible user experience and a great distraction to actually writing content, or use a page builder, which is usually overkill. I think that using columns is very common, perhaps more common than embedding a video.

In any event, my understanding is that columns are on the roadmap. I'd like to see them in V1 instead of V2. Like you, I appreciate that care is being taken to lay a good foundation.

One of the aspects of "columns" to keep in mind is that it's not just a matter of desktop layouts. It's having a system that scales from mobile to desktop.

Is it column-count in CSS? If we used that it would be very easy to create someting responsive quickly, but then you wouldn't be able to lay out content in the column you wanted at specific breakpoints.

Is it CSS Grid or flexbox? Then we'd want to make sure that users had proper responsive options so results were predictable across devices, and not only that but we'd want to let WordPress themes know about these features so it could adapt accordingly.

We know we want columns. In fact 3rd party plugins can build column blocks today. But it's a complicated feature with a slew of aspects that need to be properly in place for it to work, and without more contributors on the project, it's unlikely to happen in V1.

@jasmussen - Yes. I appreciate that columns are on the roadmap and perhaps there will be some insights from the gallery block that will help.

This feature should be built with modern layout tools in mind. Creating unnecessary containers to create column layouts now will limit our ability to use modern technology in the future.

For simple one-dimensional layouts like columns, we can use either flex or grid. I lean toward grid for the simple reason that while we're just talking about columns today, down the road users will want more advanced grid control so we should lay the groundwork now.

As for browser support, both flex and grid have broad support across modern browsers and fall back cleanly in older browsers. It is also relatively straight-forward to provide fallbacks for older browsers.

I strongly discourage adopting a classic framework approach of nesting elements to make this work. It will result in legacy cost almost immediately and hinder future layout work.

Adopting grid here opens the door to unexplored territory where layouts are concerned. I'll try to find time next week to write up something more comprehensive about what's possible here. In the meantime, this is relevant: https://rachelandrew.co.uk/archives/2017/07/01/you-do-not-need-a-css-grid-based-grid-system/

My concern with this is that it locks users into one specific type of HTML structure. All themes will have to then adapt to support this structure. Is it nested divs? Nestedsections? Do we use floats for backwards compat (because lots of sites need that. Win7 still has a huge marketshare, which means IE11 still does as well, and IE11 doesn't play well with flexbox), or go with flexbox/grid for the future. Do we give users the option to change (and then get back into them having to know CSS)? This could get dangerous quickly.

The content would contain the nested blocks but the markup that is generated for rendering could potentially be determined by the theme.

I think Gutenberg should instead focus on providing the functionality and UI for adding nested blocks instead which would allow developers to create custom blocks for things like a column. Gutenberg should not be concerned with the grid as that is something a theme should have control over.

@westonruter +100000 on this. I think Gutenberg could provide a default way of marking up the grid and its styles, but it's essential imo that it should be overridable by themes, for example through add_theme_support().

Huge +1 from me, this would be a very popular feature.

This is a great example of why Gutenberg data simply shouldn't be stored as raw HTML... if it were stored in a standards-compliant method, like mobiledoc, then columns would simply be objects, and rendering them would be easily overridable by any theme. If themes wanted to use a legacy structure, like row/col, they could. If they wanted to use grid, they could. if they wanted to use flex, they could. If they wanted to use whatever tech comes next, they could. A true object storage method would make content future-proofed. HTML + Comments just cant.

+1 this feature is very important to everyone .

I'm getting ready to redesign a big B2B website. Right now it uses Divi and I would love to be able to use Gutenberg for the redesign or I'll be stuck with Divi again for a number of years.

If columns aren't addressed - we'll be forced to continue with the a "non-WordPress" approach to building our WP-site. I'm also curious if Gutenberg will include a few "page layout" presets to override incompatible themes and include base layouts.

Grid based on Flexbox, please. Not CSS Grid, because it requires container CSS update for any changes. Flexbox will work by just adding blocks. Thanks.

Absolutely would love this feature. Great discussion here, looking forward to seeing how it develops.

I love this. Especially the ability to resize the columns. I specifically like the fact that you can control layout. I don't think this is a weakness at all. It's exactly what I've been wanting in Gutenberg and frustrated that I can't do already, given that so many other similar tools offer this feature.

So I just updated the Gutenberg plugin, and tried to mess with columns in it. I created a new post and added a column layout block, and tried to increase it using the slider. Every time I try to do this, it displays the error: "This block has encountered an error and cannot be previewed."

Thanks for the bug report, @mhenrylucero — I've opened a separate ticket for it #3710.

3745 was merged earlier this week, which partially implements the proposal here.

From what I can tell, the remaining tasks are largely improved UX around rearrangement of blocks into columned layouts, am I correct? Am I correct in assuming this would be better suited for the Customization focus following an initial merge proposal?

Going to close this which will remain as a reference for further improvements in customization.