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

Allow margins to collapse & refactor block toolbar #7365

Merged
merged 9 commits into from
Jul 5, 2018

Conversation

jasmussen
Copy link
Contributor

The primary purpose of this PR is to allow margins to collapse.

When two margins meet, and no borders or paddings are present, they collapse. I.e. a p with a 20px margin next to a similar p will have only 20px margin between them, not 40px, because the two siblings collapse to whichever margin is the largest.

By allowing margins on blocks to collapse, we can make it easier to theme the editor to look like the frontend, by making margins behave the same.

This PR also refactors how the block toolbar is positioned. Because we use position: sticky;, the toolbar is part of the flow of the block itself. In this PR it uses translate to pull it out of the flow, meaning the block metrics do not have to account for the presence of the block toolbar or not. This is a nice refactor on its own, but it also makes the positioning more resilient and predictable.

Testing

Because this is a rather large change to a visible part of the editor, it needs a good amount of testing. The gold standard is that the editor in this branch should look no different than the editor in master.

So please test on all breakpoints, test the frontend and backend, test with fixed toolbar and contextual toolbar:

  • Test that the block toolbar that looks right on all blocks, including blocks like the spacer that do not have a block toolbar.
  • Test all blocks they look right, margin-wise.
  • Test in nested contexts blocks, test child blocks.
  • Test with editor styles.

It's okay that there are a few regressions with existing editor styles, the benefits outweigh any fixes that need to be made.

@jasmussen jasmussen added [Type] Enhancement A suggestion for improvement. General Interface Parts of the UI which don't fall neatly under other labels. Needs Testing Needs further testing to be confirmed. labels Jun 19, 2018
@jasmussen jasmussen self-assigned this Jun 19, 2018
@jasmussen jasmussen requested review from karmatosed, youknowriad, aduth, a team and mtias June 19, 2018 10:49
@jasmussen jasmussen force-pushed the try/allow-collapsing-margins-v3 branch 2 times, most recently from e312a64 to 96f11d4 Compare June 20, 2018 08:43
@jasmussen jasmussen force-pushed the try/allow-collapsing-margins-v3 branch 2 times, most recently from 3f4e4b2 to 455cdae Compare June 21, 2018 10:03
@jasmussen jasmussen added this to the 3.2 milestone Jun 21, 2018
@jasmussen
Copy link
Contributor Author

This has been rebased, and I feel like it's in solid shape for wider testing, and I think we should get it in 3.2. Aside from the code cleanliness and benefits this has for editor-themers, the way the block outlines and toolbar are painted now are more resilient. Because it's hard to explain, here are two GIFs.

Here, I am adjusting the margins on the block content itself, in master, where margins do not collapse:

without

Note how the block toolbar does not correctly position itself according to the adjusted margins.

Here's from the branch that allows collapsing margins:

with

Note how changing just one margin on the block content doesn't do anything — because they collapse so the remaining margin is still there. Also notice how when the other margin is changed, the outlines and block toolbar correctly position themselves.

@jasmussen jasmussen force-pushed the try/allow-collapsing-margins-v3 branch 2 times, most recently from a9f293e to 7a6bf54 Compare June 25, 2018 07:23
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.

Block toolbar is very misplaced in IE11

image

@@ -210,7 +209,8 @@
/**
* Block outline layout
*/
.editor-block-list__block-edit {

.editor-block-list__block-edit {
Copy link
Member

Choose a reason for hiding this comment

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

Mixed whitespace. Preceding space should be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice catch, thank you.

@jasmussen
Copy link
Contributor Author

Addressed feedback. Fixed the whitespace (nice catch, it shows up as a dot in VS code, I should've seen it but somehow missed it), and made it work in IE again. I hadn't properly rebased for Brandon's fix earlier, but now it works:

edge

ie

Noting also for others as well as myself, that @supports( position: sticky ) { ... } seems like a great way to target IE11 but not Edge, even for issues outside of position sticky. For example I might want to refactor the gallery hack that I made, to make things work in IE11, to use the above instead.

@jasmussen jasmussen requested a review from a team June 27, 2018 06:47
@jasmussen jasmussen force-pushed the try/allow-collapsing-margins-v3 branch 2 times, most recently from 316a152 to ec4e9bc Compare June 28, 2018 09:52
@jasmussen
Copy link
Contributor Author

Rebased, and squashed to keep future rebases simpler. In a fixup'ed commit, https://github.com/WordPress/gutenberg/pull/7365/files#diff-00ebf096f7c483426f2a78d70d9cbd22R1003, I included a fix for a horizontal scrollbar regression introduced in #7225.

@jasmussen
Copy link
Contributor Author

Unsure why Travis fails here. The tests pass.

@tofumatt
Copy link
Member

That has been intermittently failing a lot. I've restarted it. 😢

@jasmussen jasmussen removed the Needs Testing Needs further testing to be confirmed. label Jun 29, 2018
@jasmussen jasmussen force-pushed the try/allow-collapsing-margins-v3 branch from ec4e9bc to ff7b820 Compare July 2, 2018 08:37
@tofumatt
Copy link
Member

tofumatt commented Jul 4, 2018

npm install works for me so I'm guessing it's local to your install, and that failing travis test is… frequent and happening a lot. We'll need to look into it. 😢

@jasmussen
Copy link
Contributor Author

To clarify, npm install is working fine for me. What isn't, is any image or embed. Try loading the demo content, I'm pretty sure you should see the same issue.

@tofumatt
Copy link
Member

tofumatt commented Jul 4, 2018

Shoot, sorry, I misread. You're right: I see that too...

@tofumatt
Copy link
Member

tofumatt commented Jul 4, 2018

As mentioned in Slack, this seems unrelated but a legit breakage: https://wordpress.slack.com/archives/C02QB2JS7/p1530703711000116

Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

I like this a lot more, it feels more like a real, empty canvas (and more like the old editor) with the tighter margins. I have no idea what I'm on about and I think that's an unrelated change. I see what this is doing now. All good. More coffee needed.

I think we need to sort out that image bug but as mentioned it's not related to this PR and seems to be happening in master.

🚢 … but maybe after we fix master just so we don't merge breaking builds 😉

.editor-default-block-appender__content,
.editor-block-list__block .editor-block-list__block-edit,
.editor-block-list__layout .editor-block-list__block .editor-block-list__block-edit,
.editor-block-list__layout .editor-default-block-appender .editor-default-block-appender__content { // Explicitly target nested blocks, as those need to override the preceeding rule.
Copy link
Member

Choose a reason for hiding this comment

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

Typo: "preceding". English is weird. I've pushed a fix 😄

@tofumatt
Copy link
Member

tofumatt commented Jul 4, 2018

As mentioned in Slack though: this is a great example of a PR that should include before/after screenshots. The differences are easy to spot visually but I found the lack of issue to make it unclear what I was testing for.

I need more coffee. Ignore me.

@jasmussen
Copy link
Contributor Author

Thanks a bunch for the review. I'll wait for master to behave and then merge, possibly rebase first.

Joen Asmussen and others added 7 commits July 4, 2018 18:57
This PR refactors how the block toolbar is positioned. Because we use sticky, the toolbar is part of the flow of the block itself. In this PR it uses translate to pull it out of the flow, making the positioning more resilient.

The primary purpose of this PR is to allow margins to collapse. When two margins meet, and no borders or paddings are present, they collapse. I.e. a `p` with a 20px margin next to a similar `p` will have only 20px margin between them, not 40px, because the two siblings collapse to whichever margin is the largest. By allowing margins on blocks to collapse, we can make it easier to theme the editor to look like the frontend.
- Fixed toolbar position on mobile.
- Fixed toolbar position on desktop breakpoints
- Fixed appender regression
- Fixed issue with warning blocks having no hover or selected outlines.
- Fixed positioning of ellipsis on wide blocks.
- Fixed issue with full-wide gallery.
- Fixed a few typos and an issue with warnings. This will be revisited in a future patch also being worked on separately.
- Fixed position of toolbar on wide and fullwide.
- Fixed positioning of mover on wide and fullwide.
- Fixed issue with additional margins in columns block.
- Fixed issue with the invisible toolbar on the Column (singular) block breaking the layout. This also fixed an issue with the hover label and sibling inserter positioning on the column.
- Fixed a regression in IE.
- Fixed the position of editor warning after the refactor.
@jasmussen jasmussen force-pushed the try/allow-collapsing-margins-v3 branch from 0d0576b to ffb3f5d Compare July 4, 2018 16:59
@jasmussen
Copy link
Contributor Author

Rebased. Images work now, and the rest does too.

How do we figure out if the travis failure is real? And otherwise, can we merge?

@gziolo
Copy link
Member

gziolo commented Jul 5, 2018

How do we figure out if the travis failure is real? And otherwise, can we merge?

It would be very surprising if CSS changes would make any test fail. I retriggered another build.

position: sticky;
z-index: z-index( '.editor-block-contextual-toolbar' );
white-space: nowrap;
text-align: left;
pointer-events: none;
height: $block-toolbar-height;
//height: $block-toolbar-height;
Copy link
Member

Choose a reason for hiding this comment

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

We should remove this line before merging.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed, thanks. I suppose this triggered another test? :)

it( 'Should insert content using the placeholder and the regular inserter', async () => {
// Click below editor to focus last field (block appender)
await clickBelow( await page.$( '.editor-default-block-appender' ) );
await page.click( '.editor-writing-flow__click-redirect' );
Copy link
Member

Choose a reason for hiding this comment

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

This refactor may have made the test less effective at covering the expected behavior: #11168 (review)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What's the best way to enhance this test again? CC: @gziolo who graciously helped me with this.

Copy link
Member

Choose a reason for hiding this comment

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

Ooops, I wasn't aware of that :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants