-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Conversation
e312a64
to
96f11d4
Compare
3f4e4b2
to
455cdae
Compare
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: Note how the block toolbar does not correctly position itself according to the adjusted margins. Here's from the branch that allows collapsing margins: 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. |
a9f293e
to
7a6bf54
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -210,7 +209,8 @@ | |||
/** | |||
* Block outline layout | |||
*/ | |||
.editor-block-list__block-edit { | |||
|
|||
.editor-block-list__block-edit { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice catch, thank you.
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: Noting also for others as well as myself, that |
316a152
to
ec4e9bc
Compare
Rebased, and squashed to keep future rebases simpler. In a |
Unsure why Travis fails here. The tests pass. |
That has been intermittently failing a lot. I've restarted it. 😢 |
ec4e9bc
to
ff7b820
Compare
|
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. |
Shoot, sorry, I misread. You're right: I see that too... |
As mentioned in Slack, this seems unrelated but a legit breakage: https://wordpress.slack.com/archives/C02QB2JS7/p1530703711000116 |
There was a problem hiding this 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. |
There was a problem hiding this comment.
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 😄
I need more coffee. Ignore me. |
Thanks a bunch for the review. I'll wait for master to behave and then merge, possibly rebase first. |
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.
0d0576b
to
ffb3f5d
Compare
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? |
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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' ); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :(
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 similarp
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 usestranslate
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:
It's okay that there are a few regressions with existing editor styles, the benefits outweigh any fixes that need to be made.