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

Require parent blocks #17205

Closed
coreyworrell opened this issue Aug 26, 2019 · 5 comments
Closed

Require parent blocks #17205

coreyworrell opened this issue Aug 26, 2019 · 5 comments
Labels
[Feature] Block API API that allows to express the block paradigm.

Comments

@coreyworrell
Copy link
Contributor

Is your feature request related to a problem? Please describe.
It is difficult to code for wide and full width blocks because blocks can be anything and have no shared "structure".

Describe the solution you'd like
Ability to require a block to be the root of other blocks. Example, every block must be added within a root "Section" block. Or even better, require that a "Section", "Row", and "Column" block be parents before you can choose to insert a "content" block. This is how basically all current page builder plugins work.

Describe alternatives you've considered
Normally, content is output inside a "container" element to restrict the maximum width and center within viewport.

<div class="container">
  <p>Content here</p>
</div>

Now if you add a "wide" block inside of the container, you have to use CSS to "break it out" of the container and keep it centered.

Or, alternatively, you do not wrap Gutenberg content in a container, and now have to apply some CSS like .gutenberg-content > * to apply the max-width and margin: auto code to, which may likely interfere with certain block's CSS (think Bootstrap rows with negative margins, etc).

Here is the basic HTML Gutenberg outputs now:

<div class="container">
  <!-- <?php the_content() ?> -->
  <p>Gutenberg content here</p>
  <div class="wp-blocks-columns-plugin alignfull">
    <div>...</div>
  </div>
  <h1>Heading</h1>
</div>

compared to what would be preferred:

<div class="wp-blocks-section" style="background-color: blah;">
  <div class="wp-blocks-section-container alignwide">
    <div class="wp-blocks-row">
      <div class="wp-blocks-column wp-blocks-column-6">
        <p>Gutenberg content here</p>
        <h1>Heading</h1>
      </div>
    </div>
  </div>
  <div class="wp-blocks-section-container alignfull">
    <div class="wp-blocks-row">
      ...
    </div>
  </div>
</div>
@talldan
Copy link
Contributor

talldan commented Aug 27, 2019

@coreyworrell Thanks for creating the issue. I was wondering from what point of view you're creating this issue, are you someone creating custom blocks, developing a theme, or is this functionality you think should be built in to the editor for every user?

@coreyworrell
Copy link
Contributor Author

@talldan I am mainly developing a theme, but it would apply to all three of the cases you mentioned. Having consistent html output (ie: a non-section block must always be nested inside of a section block, etc) helps immensely for styling.

@swissspidy swissspidy added the [Feature] Block API API that allows to express the block paradigm. label Aug 27, 2019
@talldan
Copy link
Contributor

talldan commented Aug 28, 2019

@coreyworrell - it would have the side effect of making the HTML produced by the editor a lot less clean.

It might be worth tracking this issue #16271 which discusses how to bring more grid like features into the editor.

@coreyworrell
Copy link
Contributor Author

coreyworrell commented Aug 28, 2019 via email

@jordesign
Copy link
Contributor

With no further discussion on this in almost 4 years - I'm going to close it and defer to #16271 which discusses layout options.

@jordesign jordesign closed this as not planned Won't fix, can't repro, duplicate, stale Aug 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm.
Projects
None yet
Development

No branches or pull requests

4 participants