Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grid System for Gutenberg #16271

Closed
mapk opened this issue Jun 24, 2019 · 23 comments
Closed

Grid System for Gutenberg #16271

mapk opened this issue Jun 24, 2019 · 23 comments
Labels
[Feature] Layout Layout block support, its UI controls, and style output. Needs Decision Needs a decision to be actionable or relevant [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues

Comments

@mapk
Copy link
Contributor

mapk commented Jun 24, 2019

The Problem

Currently, Gutenberg does not include a visual grid for those site/page builders who wish to align their layouts perfectly. Our system for resizing items is arbitrary and imperfect.

A grid system can help resolve this.

Grid System

With the excitement around snapping images to a grid which was demoed at WCEU 2019 in Matt's keynote, let's get this conversation started.

grids

Questions
I'm trying to get all the questions up front. If there are others, please comment with them.

  1. Should the grid system be responsive?
  2. Should there be a default Gutenberg grid system, but allow themes to register their own?
  3. Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?
  4. Should the grid include gutters?
  5. Should the grid include, or allow, any vertical alignment snaps?
  6. What should the grid be based on? (ie. 12 columns, pixel grid, etc.)
  7. Should the grid allow toggling on/off? And also include a setting to show, or not, when resizing objects in the editor?

While many of these questions can be worked out in individual PRs as we begin working a grid into the editor, I'd like to begin discussions here for now. Maybe we can work on an MVP, or version 1 for now to get into the plugin for testing.

@mapk mapk added Needs Design Needs design efforts. Needs Decision Needs a decision to be actionable or relevant labels Jun 24, 2019
@mtias mtias added [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues and removed Needs Decision Needs a decision to be actionable or relevant labels Jun 25, 2019
@swissspidy
Copy link
Member

Two things I think need to be considered are grids within a block that applies to its inner blocks only, plus horizontal grid lines. So this needs a flexible enough API for plugins and themes to customize the grids for snapping. Example use case for me would be the AMP plugin's AMP Stories editor, which could make use of this.

@karmatosed
Copy link
Member

Some thoughts:

Should the grid system be responsive?

Yes, absolutely. Although, this brings up having multiple grids and maybe that's also an option to allow declaring of multiples.

Should there be a default Gutenberg grid system, but allow themes to register their own?

Yes, and it should be documented to encourage people to easily be able to adapt.

Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?

I think restructuring is a massive step. Perhaps starting with what there is right now and seeing potential restructure as an iteration is a better-stepped process here.

Should the grid include gutters?

By default probably, but having gutters as an option could be a case. Most grids would have gutters.

Should the grid include, or allow, any vertical alignment snaps?

I think snapping to grid feels like an option or a step after having a grid. I see a great need for it and want, but like with most image software grid snapping is on option, I think it should be for Gutenberg. We may decide it's an option on by default though, I can see a strong case for that.

What should the grid be based on? (ie. 12 columns, pixel grid, etc.)

I think this is the 'fun' bit. Starting with what we have as a base, I think then exploring what other grids feel or are like is a great exercise in experimentation.

Should the grid allow toggling on/off? And also include a setting to show, or not, when resizing objects in the editor?

I think allowing it to show/hide is essential. As mentioned earlier I also think there could be a case for other options to be added in. I go back to think about how Sketch and other applications do this.

It would be great to maybe step away for a moment and do some thinking about what applications offer this. What features do they have and what can we learn?

@mapk
Copy link
Contributor Author

mapk commented Jul 31, 2019

I think restructuring is a massive step. Perhaps starting with what there is right now and seeing potential restructure as an iteration is a better-stepped process here.

Thinking through this, I worked on a grid largely influenced by Material.io. I haven't thought through the breakpoints or provided other screensize examples yet, but maybe this can help the conversation?

grid

This grid contains columns and gutters.

Columns vary depending on breakpoint. At the default Gutenberg 580px width, the grid would include 8 columns and 7 gutters. The column widths are fluid up to the breakpoint in which case the column count changes up to 12 (wider content area) or down to 4 (smaller content areas). The gutters are fixed width and change their widths only at breakpoints.

I know this is an opinionated approach to grids, but I think it's necessary to implement. Themes should be allowed to register their own grids, but as a default Gutenberg grid, this should be sufficient.

If anyone has other ideas or feedback on grids, I'd love to hear more! There's an experimental PR going on #16748, so I'd like to move on the grid discussion.

@kjellr
Copy link
Contributor

kjellr commented Aug 1, 2019

@mapk Because of wide + full alignments, I think the grid will need to extend beyond just the text column right?

@mapk
Copy link
Contributor Author

mapk commented Aug 1, 2019

Great question, @kjellr. I wasn't sure how to treat those. The idea of wide and full alignments, in my mind, pushed beyond the grid. Although, I can see wide needing to align with a grid pattern still, so in that case, it's probably a good idea to extend the grid further.

The grid breakpoints would still be defined by the post content, but the grid pattern would extend beyond. Here's a few examples.

Option 1 - Lines

Screen Shot 2019-08-01 at 8 29 00 AM

Option 2 - Fills

Screen Shot 2019-08-01 at 8 31 11 AM

@karmatosed
Copy link
Member

The idea of wide and full alignments, in my mind, pushed beyond the grid. Although, I can see wide needing to align with a grid pattern still, so in that case, it's probably a good idea to extend the grid further.

I agree with @kjellr and it should extend. I don't think you need to show it until they have been added though as easier visually without.

@mapk mapk added Needs Design Feedback Needs general design feedback. and removed Needs Design Needs design efforts. labels Aug 1, 2019
@paaljoachim
Copy link
Contributor

What about a grid switch and a block border switch in one? Kinda like turning on the grid feature in Photoshop to see all the elements and how they relate to each other.

@senadir
Copy link
Contributor

senadir commented Aug 2, 2019

Should the grid system be responsive?

This is a must, but how can get this is the actual problem, responsive grids are relative to the medium you're seeing them, so how can we translate those values from say, the editor, to the frontend.

Should there be a default Gutenberg grid system, but allow themes to register their own?

yes, this is definitely a must, mostly for easier adoption.

Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?

I think we can start with a simple structure, the PR i made #16748 inject the grid at the root of the editor & communicate it with other blocks, blocks can choose to integrate it, this can help in a gradual adoption.

Should the grid include gutters?

a default grid behavior have gutters, but i twill be hard to resize & snap with gutters in place since it will be a lost space.

Should the grid include, or allow, any vertical alignment snaps?

for the moment no.

What should the grid be based on? (ie. 12 columns, pixel grid, etc.)

this is the problem I'm thinking about right now, grids have the fluidity of adopting any screen size.
pixel grid is more straightforward, easier to adapt with the editor, and much to understand to a normal user (3 columns are 300px for example) but they prove to be very hard to translate & interpolate at different screen sizes, snapping to columns might prove hard when you want to do out of the grid alignment.
the technical implementation of pixel grid & percentage grid will be different so we might choose a way & go with it for now and add the second one in the future, it will however, prove hard to migrate from a theme that uses % to a theme that uses px.

Should the grid allow toggling on/off? And also include a setting to show, or not, when resizing objects in the editor?

this is currently how it works in the PR, i guess it makes sense, we can add an option to toggle it off & on in the editor, and for it to toggle on & off in the snapping & resizing moments.

a live demo for some UX testing, it uses px columns without a fixed container size.

some other questions to think about

  • how should we handle breakpoint transitions?
  • how should we implement the snapping behavior? snap after release or snap before release?
  • how will different themes defining different grids play with each other? if I change a theme, I mostly expect my content to still work the same
  • are subgrids a thing? how can handle them? or should support them to begin with?

@senadir
Copy link
Contributor

senadir commented Aug 2, 2019

for extending beyond the grid limit, I think we should have 1 or 2 stops at max, full length & half length.

think of it this way, if a grid is 1200px and a user screen is 1920px for example, a full length grid stop should make the element 1920px or max width, a half length grid stop should make it 1560px or max width.

if we define more columns outside the container we risk putting ourselves at grid stops that would not translate to the frontend, a 12 column for a base grid is ideal, anything outside should be treated as 100% page width or something.

@senadir senadir pinned this issue Aug 3, 2019
@senadir senadir unpinned this issue Aug 3, 2019
@mapk
Copy link
Contributor Author

mapk commented Aug 15, 2019

Should the grid system conform to the current structure of Gutenberg blocks, or should it be its own thing that we need to restructure the blocks to in the editor?

I think we can start with a simple structure,

I agree. The grid I mocked up above conforms to the layout of the starter theme's editor styles. I felt this was a good beginning.

a default grid behavior have gutters, but i twill be hard to resize & snap with gutters in place since it will be a lost space.

Yeah, let's make sure to include gutters on this grid b/c it's a natural grid attribute. I don't think we need to consider this as "lost space" though and rather just allow the user to align to any gridline they'd like to.

the technical implementation of pixel grid & percentage grid will be different so we might choose a way & go with it for now and add the second one in the future, it will however, prove hard to migrate from a theme that uses % to a theme that uses px.

Agreed. I like a percentage grid first with static pixel gutters depending on breakpoints. Similar to Material's grid system. This makes sense. The grid is determined based on the content width within the Editor and Frontend. Once that is determined (ie. mine above shows 8 columns) then that grid pattern is just repeated through the entire screen, not just within the content column. This allows for wide and full-width alignments to work along the grid too.

for extending beyond the grid limit, I think we should have 1 or 2 stops at max, full length & half length.
think of it this way, if a grid is 1200px and a user screen is 1920px for example, a full length grid stop should make the element 1920px or max width, a half length grid stop should make it 1560px or max width.
if we define more columns outside the container we risk putting ourselves at grid stops that would not translate to the frontend, a 12 column for a base grid is ideal, anything outside should be treated as 100% page width or something.

I think we need to allow this grid pattern to repeat, but using color or fill indicators to designate the "content area" should help with layout. But ultimately, as we look to pull in other Block Areas into this editor (however that happens) we'll need to allow this grid to extend to those areas too. This beginning sets us up for that. And this ways themes can begin to build with this in mind. Any theme that doesn't allow breaking out of the content area, maybe we either hide the repeating pattern, or not allow items to be extended past it in the editor. Thoughts?

@strarsis
Copy link
Contributor

There is a great WordPress plugin for a Gutenberg grids block:
https://wordpress.org/plugins/grids/
The only one I was able to find that allows customizable grids.

@strarsis
Copy link
Contributor

IMHO the grid in Gutenberg shouldn't necessarily reflect CSS or HTML grids or its concrete implementation. Even sub-grids, if not supported could be emulated using JavaScript.
So the user interacts with a high-level grid, regardless of implementation or CSS support.

@karmatosed karmatosed added Needs Decision Needs a decision to be actionable or relevant and removed Needs Design Feedback Needs general design feedback. labels Dec 2, 2019
@karmatosed
Copy link
Member

As this now has a lot of feedback, I think changing the label to 'needs decision' makes sense.

@aquaihoi
Copy link

It just needs to be like a page editor for print . . . With either grid or column toggle on or off to show a grid used for alignment, also it would be good to have a decent menu system similar to any word processing with grouped embellishments, font selection etc. etc. I quite like the way the GRIDS plugin allows you to draw grids / sections etc. but without a design / layout grid system the Gutenberg editor is over simplified, its like you’re working blind

@strarsis
Copy link
Contributor

@aquaihoi: There is also full page editing that is still alpha in Gutenberg.
However, grids in content are still necessary.

@paaljoachim
Copy link
Contributor

paaljoachim commented Jun 6, 2020

The Grid Layout Block has been built for wordpress.com.
https://wordpress.org/plugins/layout-grid/
I do think we can improve on it and get it into Gutenberg Core.

Actually we could get drag handles into the Columns Block.

@aquaihoi
Copy link

aquaihoi commented Jun 8, 2020

Coming from desktop publishing background, it would be really awesome to see DTP implementation of more tools, features, conventions which are translated over to the page editing interface of core wordpress, not just for me but a lot of people, who have a phobia of designing for the web, earlier on we would be juggling dreamweaver, css, html, php over and in-between to design web pages, lets face it, designers are not developers and what is really cool about how Wordpress came to be and the ease of use it allowed the average user to set up pages is really awesome, however the tools and the way you design tends to rely on so many plugin which often leaves the site bloated with plugins, some of which the authors abandon or amalgamate with other companies and the prices go high, native font management and integration would also be cool. Id love to see the editing tool bar landfill screen workspace in the page editor which is similar to any standard word processor or a light version of Illustrator or Indesign - the Gutenberg interfaces soooo close to being an awesome tool that anyone from publishing can pickup and run with, some minor things are very unintuitive, the basic structure is there, but it needs just a little work - for instance - clearly defined space - eg. page size with boarders, eg. my site is 1200 x 1200px in dimension, in which there are grid layouts, and the user can draw text and image boxes, with snapping etc to compose their page, while the core maintains resize and repositioning of blocks for mobile viewpoint, it needs to be a bit more visual, Id love to design up a mock interface show what I mean, I'll try the next instance of spare time I have, will try the plugin on out on a new website project !

@strarsis
Copy link
Contributor

strarsis commented Jun 8, 2020

I have to refer again to the Mesh plugin which would be equivalent to Gutenberg Full Page Editing.
It is important for themes to have as much control as possible, the grids defined by user should be modifiable by the theme, in terms of breakpoints, columns, rows and even position (CSS Grid).

@LukaszJaro
Copy link

This would be great, my previous project I used blocks inside the content and outside the content I was styling with Bootstrap 4, it became a little disjointed, lacked consistency and I wondered why I was using two CSS frameworks.

I do like the bootstrap approach of adding classes to html which I was also able to use and add inside the content through the custom classes. It was also helpful to have responsive margin and padding classes.

A grid system that you can also use practically outside the content would be great.

@kelleymuro
Copy link

I'm super interested in this even if it is simply in the context of patterns. Being able to create certain pattern types (Grid Enabled) that empowers users to start with a template but easily customize them. Ultimately I would like to see entire sites being created with a snapped grid layout. Like Editor X or Squarespace is doing.

I have seen a few examples, what is the decision for vertain blocks vs having many rows and columns to span blocks across. Squarespace a few months back released their Fluid Engine which seems like a pretty efficent way to do things.
image

Does this introduce a whole new block type where where there is draggable blocks and droppable sections/containers?

Would be fun to experiement with breakpoints

Either way, I would love to sponsor someone that may be interested in working on this with me.

@strarsis
Copy link
Contributor

strarsis commented Oct 8, 2022

@kelleymuro: Overlapping cells for the Grids plugin should achieve the same, but this feature isn't implemented yet.
Even better when this grid system could be directly integrated into WordPress Gutenberg core.

@kelleymuro
Copy link

@strarsis Did you work on this plugin? It doesn't seem to be as intuitive as I'd like it to be when it comes to freely moving components around a grid.

What I am purposing is to not set your content areas but just automatically set an entire section as a content area and then be able to freely move components around that area.

image

@skorasaurus skorasaurus added the [Feature] Layout Layout block support, its UI controls, and style output. label Feb 7, 2023
@annezazu
Copy link
Contributor

Closing this out as the design and experience has evolved substantially since this was first explored. For future work, follow along here where improvements to layout are being explored, including a Grid variation of the Group block first explored in 17.8: #57571

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Layout Layout block support, its UI controls, and style output. Needs Decision Needs a decision to be actionable or relevant [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Projects
None yet
Development

No branches or pull requests