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

Block styles: only add auto margin to root blocks #19912

Closed
wants to merge 3 commits into from

Conversation

ellatrix
Copy link
Member

Description

Currently block margins on the left and right is set to auto for every block including nested blocks. This seems unintended to me. I think it should only be applied to blocks at the root level, so they are centred within the editor canvas. It shouldn't be added for nested blocks.

How has this been tested?

Test nested blocks.

Screenshots

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.
  • I've updated all React Native files affected by any refactorings/renamings in this PR. .

@ellatrix ellatrix added the [Type] Code Quality Issues or PRs that relate to code quality label Jan 27, 2020
@youknowriad
Copy link
Contributor

It might have something to do with the group block. let's make sure there's no regressions there vCard @kjellr @jasmussen

@@ -35,7 +35,7 @@
}

// The base width of blocks
.edit-post-visual-editor .block-editor-block-list__block {
.edit-post-visual-editor .block-editor-block-list__layout-root > .block-editor-block-list__block {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an interesting approach. I was about to suggest that the automatic left and right margin is the exception to the rule, i.e. something that is unique to post content, and even the whole structure of how wide and fullwide images are handled — in fact there's a max-width too.

And so this, in a way, does treat it as the exception, but it does raise the question: is this post-content only, or could we imagine other containers in an FSE future that would want this treatment?

@jasmussen
Copy link
Contributor

Your efforts to clean up the code have not gone unnoticed, thank you.

While this PR feels like a step in the right direction, it does come with some challenges, and it may suggest that it might be a bigger undertaking. I alluded to some of the questions in this comment: https://github.com/WordPress/gutenberg/pull/19912/files#r371627753 — but it goes a bit further.

Right now, wide and fullwide images work because the main column is unconstrained, and blocks inside have a max-width. Which means the odd behavior for top level blocks is just not the margins, it's also that max-width.

This raises the question: should other containers be able to opt into this treatment? Post content has it, should Footer have it too? Header? How about a fullwide group block? Right now that breaks. This branch:

Screenshot 2020-01-28 at 07 28 15

Master:

Screenshot 2020-01-28 at 07 29 19

It also raises the followup question: should this centering and max-width even be default? Should it be something that is applied if the theme opts into wide images?

@youknowriad
Copy link
Contributor

youknowriad commented Jan 28, 2020

should other containers be able to opt into this treatment?

I do remember us discussing this and yes, I believe the "group" block should have an option to say whether it has the centering which means several things:

  • If that option is triggered, its inner blocks will be centered by default and will have the option to be "wide"/"full" width aligned.
  • If that option is disabled, its inner blocks are full width (width of the parent) by default and don't have any "wide"/"full" width options.

That behavior is unrelated with theme options for me, it's more an API for InnerBlocks to defined the supported alignments.

@ellatrix
Copy link
Member Author

Yes, let make an option. Does the fact that it's already the default now make it more difficult to switch?

Let's make it an option on BlockList (and thus also InnerBlocks) which can then be used by the post content editor and the group block.

@jasmussen
Copy link
Contributor

Yes, let make an option. Does the fact that it's already the default now make it more difficult to switch?

Would it make sense to leverage the existing option for post content? add_theme_support( 'align-wide' );

@ellatrix
Copy link
Member Author

Only centre the post content if the theme supports wide alignment?

@jasmussen
Copy link
Contributor

Basically. It seems the appropriate thing to do long term because the purpose of the centering (and max-width, don't forget that one) is to enable wider-than-the-main-column images, but not sure if we're quite ready for it — it would potentially make the editing experience worse for themes that don't opt in, or don't instead provide alternate editor styles.

@youknowriad
Copy link
Contributor

I believe the centering is not the responsibility of InnerBlocks or BlockList, but it's the responsibility of their parent (canvas, or group block), but BlockList should have an API to define the available widths.

What @jasmussen is suggesting is that this API/prop should inherit from theme theme supports for the post_content case.

@ellatrix
Copy link
Member Author

I'm not quite following. My intention here is remove it right now for all inner blocks because it does more harm than good. I could add styles for the group block so content is centred. We can think about how to best handle it for the post content later?

@youknowriad
Copy link
Contributor

I could add styles for the group block so content is centered

That's probably the simplest way forward. My concern is whether third-party block containers relied on this behavior. We could check quickly some block plugins.

@github-actions
Copy link

github-actions bot commented Mar 2, 2020

Size Change: -72 B (0%)

Total Size: 865 kB

Filename Size Change
build/block-editor/index.js 105 kB +18 B (0%)
build/block-library/editor-rtl.css 7.34 kB -58 B (0%)
build/block-library/editor.css 7.34 kB -57 B (0%)
build/edit-post/style-rtl.css 8.54 kB +13 B (0%)
build/edit-post/style.css 8.54 kB +12 B (0%)
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.01 kB 0 B
build/annotations/index.js 3.43 kB 0 B
build/api-fetch/index.js 3.39 kB 0 B
build/autop/index.js 2.58 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 6.02 kB 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-editor/style-rtl.css 10.5 kB 0 B
build/block-editor/style.css 10.5 kB 0 B
build/block-library/index.js 116 kB 0 B
build/block-library/style-rtl.css 7.5 kB 0 B
build/block-library/style.css 7.5 kB 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-default-parser/index.js 1.65 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/blocks/index.js 57.6 kB 0 B
build/components/index.js 191 kB 0 B
build/components/style-rtl.css 15.5 kB 0 B
build/components/style.css 15.5 kB 0 B
build/compose/index.js 5.76 kB 0 B
build/core-data/index.js 10.5 kB 0 B
build/data-controls/index.js 1.03 kB 0 B
build/data/index.js 8.22 kB 0 B
build/date/index.js 5.37 kB 0 B
build/deprecated/index.js 772 B 0 B
build/dom-ready/index.js 568 B 0 B
build/dom/index.js 3.06 kB 0 B
build/edit-post/index.js 90.9 kB 0 B
build/edit-site/index.js 4.63 kB 0 B
build/edit-site/style-rtl.css 2.51 kB 0 B
build/edit-site/style.css 2.51 kB 0 B
build/edit-widgets/index.js 4.42 kB 0 B
build/edit-widgets/style-rtl.css 2.59 kB 0 B
build/edit-widgets/style.css 2.58 kB 0 B
build/editor/editor-styles-rtl.css 325 B 0 B
build/editor/editor-styles.css 327 B 0 B
build/editor/index.js 44.6 kB 0 B
build/editor/style-rtl.css 4.01 kB 0 B
build/editor/style.css 4 kB 0 B
build/element/index.js 4.45 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/index.js 7.6 kB 0 B
build/format-library/style-rtl.css 502 B 0 B
build/format-library/style.css 502 B 0 B
build/hooks/index.js 1.92 kB 0 B
build/html-entities/index.js 622 B 0 B
build/i18n/index.js 3.48 kB 0 B
build/is-shallow-equal/index.js 710 B 0 B
build/keyboard-shortcuts/index.js 2.3 kB 0 B
build/keycodes/index.js 1.68 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 226 B 0 B
build/list-reusable-blocks/style.css 226 B 0 B
build/media-utils/index.js 4.85 kB 0 B
build/notices/index.js 1.57 kB 0 B
build/nux/index.js 3.02 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.54 kB 0 B
build/primitives/index.js 1.49 kB 0 B
build/priority-queue/index.js 780 B 0 B
build/redux-routine/index.js 2.84 kB 0 B
build/rich-text/index.js 14.3 kB 0 B
build/server-side-render/index.js 2.54 kB 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/url/index.js 4 kB 0 B
build/viewport/index.js 1.61 kB 0 B
build/warning/index.js 1.14 kB 0 B
build/wordcount/index.js 1.18 kB 0 B

compressed-size-action

@ellatrix
Copy link
Member Author

ellatrix commented Mar 2, 2020

@jasmussen I retested the group block with master, and the content doesn't seem to align with the main content when using full alignment.

Screenshot 2020-03-02 at 16 01 31

@ellatrix
Copy link
Member Author

ellatrix commented Mar 2, 2020

Ooops, never mind. I checked out the wrong branch.

@ZebulanStanphill ZebulanStanphill mentioned this pull request Mar 11, 2020
9 tasks
@@ -37,7 +37,7 @@
}

// The base width of blocks
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly out-of-scope of this PR, but this comment doesn't really make sense. It probably did at some point before a refactor, but now it's just confusing. I think it would be a good idea to update this comment to be more helpful.

@ZebulanStanphill ZebulanStanphill added the CSS Styling Related to editor and front end styles, CSS-specific issues. label Nov 30, 2020
Base automatically changed from master to trunk March 1, 2021 15:43
@ellatrix ellatrix closed this Sep 14, 2021
@ellatrix ellatrix deleted the try/margin-auto-root branch September 14, 2021 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CSS Styling Related to editor and front end styles, CSS-specific issues. [Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants