-
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
Fix fullwide regression. #21201
Fix fullwide regression. #21201
Conversation
// Full-wide needs negative margins to accommodate the root container padding. | ||
&[data-align="full"], | ||
&.alignfull { | ||
margin-left: -$block-padding; |
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 retire/rename both of the variables used here, as they are no longer descriptive of their original intent.
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 kept this style but I moved it to the place where we add the padding to the block wrapper.
Do we really need to add it here? Why?
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 don't know... Do you not see the margin issue in master? Is it just a cache ghost ok my machine? Note that I'm using a theme that doesn't provide an editor style.
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.
Yes, it seems to happen only for themes without editor styles, still trying to figure out why
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.
Actually, I figured it out, it depends on the block. Try Media&Text for instance, you'll notice that it works just fine.
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 need to run some errands, but I'll have a look after that in a bit. I think somehow we need alignfull/wide on the wrapper div.
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'm not sure I understand the problem... It seems fines even without editor styles
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.
Actually scratch what I said about editor styles. This is also in TwentyTwenty:
It's because of this:
That div wraps the Image block, which means it isn't targetted by this:
.block-editor-block-list__layout.is-root-container > .block-editor-block-list__block[data-align="full"]
I think we need to do two things:
- Figure out why the image block has an extra div in the editor — was a new fragment introduced?
- Relax or reconsider the idea of scoping the full-wide rule.
What do you think, @youknowriad?
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.
Yes, I haad the same thoughts here
I think we should relax the rule for now and if possible try to find a way to not apply it in inner blocks.
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 would agree, but your point about the group block was well made. And if we change the current code (https://github.com/WordPress/gutenberg/pull/21201/files#diff-ee2ed3adbe2578628039530c717a9a93R652) to just relax it overall, that regresses the column block with wide blocks inside.
This one would be good to get in along with #21097 ;) |
Size Change: +58 B (0%) Total Size: 857 kB
ℹ️ View Unchanged
|
I don't think this is world ending and in need of an urgent patch. If it only happens if you use a theme that doesn't style the editor but does support full width, it's already edge case. I think it's okay if this needs more time in the oven. |
0d11df6
to
9a47aaa
Compare
Alright, I have created a different fix based on the learning in #21201 (comment). The Image block has an alignment wrapper that outputs a div around the image block with a specific class, if necessary. It looks like this:
When the image block has no alignment, or it has full-wide, then that div is just an empty wrapper. In leiu of refactoring that div away, I created a fix that targets full-wide children of empty divs as well. It's not the prettiest solution in the world, but it's a very simple fix that would be good to ship as we look for better solutions. What do you think, @ellatrix? |
9a47aaa
to
1b421e4
Compare
@@ -649,6 +649,9 @@ | |||
|
|||
.block-editor-block-list__layout.is-root-container { | |||
// Full-wide. (to account for the padddings added above) | |||
// The first two rules account for the alignment wrapper div for the image block. | |||
> div > .block-editor-block-list__block[data-align="full"], | |||
> div > .block-editor-block-list__block.alignfull, |
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.
maybe we can add > div:not(.block-editor-block-list__block)
instead of > div
because that markup is definitely possible in nested contexts
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 suppose we're already in "very very specific selectors" territory — but the :not rule would make it even more specific. But I'm happy to add it.
Maybe I should have included this in the patch release 😅 |
Full-wide blocks were no longer full-width. This PR fixes that.
This possibly regressed in #21099.
Before:
After: