-
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
Blocks: Un-collapse Classic block margins #8308
Conversation
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 works for me. Sorry about the issues — I knew the margin collapsing was a big refactor which is why it was underway for more than a month. I hope this is the last of the issues it caused, and I still deeply believe the refactor is worth it.
Noting, as also mentioned in Slack, https://wordpress.slack.com/archives/C02QB2JS7/p1532978287000072, that .1px margin collapsings can cause visual issues. Notably on retina screens. You might see a flickering as you scroll, because the rounding math doesn't always work the way we want it to. The alternative would be to use 1px and then compensate for this 1px with a negative 1px elsewhere.
Not sure how kosher this is, but if you change the .1px padding to 1px, then you can compensate for it like this:
|
More generally, we should figure out what it is about the collapsed margins that is incompatible with various blocks, rather than addressing them in ad hoc fashions like I'm doing here. |
This seems to have undesirable consequences, offsetting the activated block's toolbar. Maybe something with the toolbar's existing |
The reason why we need collapsing margins in the first place is that the most basic blocks, paragraph, list, image and so on, should ideally behave the same as they do on the frontend so the editor style doesn't have to account for an arbitrary margin we apply to the editor. It's one small step on the wysiwyg path. I agree it would be nice if things felt more resilient. Since two things in a row broke because of this effect, columns and classic block, it can feel brittle. But perhaps this is a side effect of having to refactor to support collapsing margins midstream. |
Digging into it further, it seems that conflicts can occur when elements within a block try to offset themselves by negative margins, as we were doing in the freeform block with the toolbar and the TinyMCE element. I've removed these and all appears to work well; the main uncertainty I have now is that I'd needed to remove |
Hmm, we need the toolbars to be sticky though, classic and modern alike. If that's broken now perhaps the padding fix was better |
This is an alternative to #8308, which doesn't rely on uncollapsing margins. What it does is position the classic toolbar using translate, which is the same way every other toolbar is positioned. This fixes the issue and cleans up the CSS.
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.
Although I approved this as a hotfix, I think #8314 might be a better fix. Can you take a look?
This is an alternative to #8308, which doesn't rely on uncollapsing margins. What it does is position the classic toolbar using translate, which is the same way every other toolbar is positioned. This fixes the issue and cleans up the CSS.
I merged in a better fix, inspired by this branch. Thanks for fixing my regression. I think this PR can be closed. |
Thanks @jasmussen ! Will close this one. |
Fixes #7918
Related (regression of): #7365
This pull request seeks to resolve an issue where the Classic block TinyMCE panel is not flush with its block container. It does so by reverting the margin collapsing for the Classic block only, similar to as proposed for the Columns block in #8283.
Testing instructions:
Repeat steps to reproduce from #7918, verifying that there is no excess gap between the Classic block panel and its block container.