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

Open
mapk opened this issue Jun 24, 2019 · 2 comments

Comments

4 participants
@mapk
Copy link
Contributor

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 this to Backlog in Phase 2 via automation Jun 24, 2019

@mtias mtias added Overview and removed Needs Decision labels Jun 25, 2019

@swissspidy

This comment has been minimized.

Copy link
Member

commented Jun 25, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 28, 2019

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?

@karmatosed karmatosed moved this from Backlog to UI iterations in Phase 2 Jul 9, 2019

@karmatosed karmatosed removed this from UI iterations in Phase 2 Jul 16, 2019

@karmatosed karmatosed added this to To do in Tightening Up Jul 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.