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

Try uncollapsing margins on the columns block. #8283

Merged
merged 2 commits into from
Aug 1, 2018

Conversation

jasmussen
Copy link
Contributor

This is a first stab at fixing #7766.

It does not address it fully, I believe further work is necessary, including that of #7694. However this should at least improve the collapsing of the parent container.

In the following screenshots, I've selected all blocks, as this highlights using transparency and overlay effects, the boundaries and how they overlap. Here's what's in master:

before

Here's with this PR applied:

after

As you can see, there are zeroed out margins on the first and last container children inside the columns block. This is there to make the columns block flow more directly with the surrounding content, but this can be revisited, and as noted, #7694 might help here.

Noting that if we were to remove zeroed out margins on the first and last container children, here's what it would look like:

no collapsing margins

This is a first stab at fixing #7766.

It does not address it fully, I believe further work is necessary, including that of #7694. However this should at least improve the collapsing of the parent container.
@jasmussen jasmussen added the [Type] Enhancement A suggestion for improvement. label Jul 30, 2018
@jasmussen jasmussen self-assigned this Jul 30, 2018
@jasmussen jasmussen requested review from aduth and a team July 30, 2018 08:41
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

This seems like a small improvement over master, at least as far as overlapping goes. We should stop considering this as a "Columns" issue, and address it as generally affecting any block with inner blocks. In that sense, these changes do nothing for any other block with inner blocks.

.editor-block-list__layout .editor-block-list__block[data-type="core/columns"] > .editor-block-list__block-edit,
.editor-block-list__layout .editor-block-list__block[data-type="core/column"] > .editor-block-list__block-edit {
margin-top: 0;
margin-bottom: 0;

// This uncollapses margins on this parent container.
padding-top: 1px;
Copy link
Member

Choose a reason for hiding this comment

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

Would 0.1px be a better value here? While it's not valid in the sense of a fraction of a pixel, it achieves the same effect while not having a visual difference (since it will round to 0).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the review, forgot to mention that before.

A better solution might exist in the process outlined below: #8283 (comment)

I pushed a fix to use the 0.1px as you suggested. Because although it had visual side effects on the Classic Block toolbar on retina screens (the rounding math glitched out every once in a while causing flickering when scrolling), it doesn't appear to have any side effects here.

However a different approach is to simply accept that flex containers margins do not collapse and stop compensating for it. That is — we don't need to prevent the parent block margins from collapsing (can remove the padding hack), but we also remove these two lines:

https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/block-list/style.scss#L130

The net result is this:

screen shot 2018-07-31 at 10 19 20

GIF:

no compensation

As you can see the margins on paragraphs inside are now doubled before and after, because we don't compensate. We probably want to do this as part of #8283 (comment), depending on what you think of that.

@jasmussen
Copy link
Contributor Author

We should stop considering this as a "Columns" issue, and address it as generally affecting any block with inner blocks. In that sense, these changes do nothing for any other block with inner blocks.

Step one of making margins collapse was to ensure that the block "foot print" was accurate in the backend, compared to the front-end, specifically to ensure that the UI we paint around each block — borders, multi select squares, toolbars, side UI — did not affect the foot print at all.

Step two is actually adding margins to each and every block, on a per-block basis. Essentially, like a front-end styleseheet, a paragraph needs one margin, a list needs another. Perhaps a columns block doesn't need any margins at all.

Right now we are applying the same margins in a blanket statement, to all blocks. This happens here: https://github.com/WordPress/gutenberg/blob/master/packages/editor/src/components/block-list/style.scss#L140

Removing that rule removes any artificial margins added to all the blocks (with the added notes that we have some negative margins to compensate for this).

In other words, I would suggest that the next step in improving this, and addressing your comment, is to remove those artificial margins, and then rebuild them block by block. Do you agree this is the right approach?

@jasmussen jasmussen added this to the 3.5 milestone Jul 31, 2018
@jasmussen jasmussen merged commit abb14b1 into master Aug 1, 2018
@jasmussen jasmussen deleted the try/uncollapse-columns-block branch August 1, 2018 09:02
jasmussen added a commit that referenced this pull request Aug 1, 2018
This is a followup PR to discussion in #8283 (comment).

The chief purpose is to remove all margins on blocks, and let each and every block add these margins back themselves. The purpose of this is to more closely mimic how a WordPress theme is built — a paragraph might have one margin, a heading another, a list yet another. By not blanket applying a margin to every child, but letting each define their own, we're essentially building a vanilla editor stylesheet.

This is a try branch, and very much a work in progress. It is being pushed now to convey the purpose and to discuss whether/how this should be tackled. For example right now the beginnings of this vanila stylesheet lives in the main.scss file, but we might want to put these into the style.scss for every block individually.

Please marinate on this and lay your thoughts on me.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants