-
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
Zoom layout shift: second alternate fix. #66041
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -1,5 +1,6 @@ | ||||||
.block-editor-iframe__body { | ||||||
position: relative; | ||||||
border: 0.01px solid transparent; | ||||||
} | ||||||
|
||||||
.block-editor-iframe__html { | ||||||
|
@@ -32,8 +33,6 @@ | |||||
|
||||||
body { | ||||||
min-height: calc((#{$inner-height} - #{$total-frame-height}) / #{$scale}); | ||||||
display: flex; | ||||||
flex-direction: column; | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why was this removed? I believe this will break filling the page to fit the canvas height, cc @richtabor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The context is in #65915. Either these rules persist on body, both zoomed in and zoomed out, or they are removed. Having them just in one case, causes the layout shift shown in 65915. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can reproduce it from the commit right before this, but I think this didn't happen with zoom-out mode with TT4 just a few months ago. Maybe something changed that caused this glitchy behaviour. The problem is that now the footer will no longer be pushed to the bottom, so we'll have to revert these lines in particular.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's fine in the site editor, it's the post editor that's the problem due to how the Title block has margins that collapse. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think it was an understood tradeoff. The flex display on the body was also the cause of #63519 so bringing it back brings that back as well. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes if the problem is only in the post editor, we should only remove it in the post editor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I didn’t mean to disparage anything by calling it a tradeoff, but fixing a couple things while knowingly breaking another seems to fit the definition to me. Though, yes, perhaps it doesn’t have to break. Though I find it odd that for that feature we justify layout shift, since that’s what pushing the footer is. It would seem better if there were a way to orchestrate it after the zoom out transition and include some helpful indicator like expanding one of the insertion points. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Clarifying further, theoretically it could also be the site editor. It's any editor where the first block uses a top margin. Any such margin will collapse when switching between flex and not block. That also means in the post editor, if you turn "Show template" on or off, you can switch between maybe having top margins or not: I'd be happy to restore the rule so it exists both zoomed and unzoomed. But the layout shift has to be fixed somehow. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Maybe I am missing something but to add a such a rule on the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I’ve opened up #66388 to restore the feature in a different way that should be less liable to have other impacts. I already requested a review from some of the folks here but I'm mentioning it in case anyone else cares to have a look. |
||||||
|
||||||
> .is-root-container:not(.wp-block-post-content) { | ||||||
flex: 1; | ||||||
|
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.
A comment here would help the readability here I believe 👍
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.
Wondering if this should be
outline
rather than border, unless the inset style is preferred?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, ignore me please - refreshing and updating trunk helps 😄
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'd still use outline - the border is causing some minor layout discrepancies:
Kapture.2024-10-23.at.10.55.47.mp4
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 think outline can work. The border is to cause margins of children to be contained something outline won’t do. That is this issue will return:
outline-v-margin.mp4
But it may be we need an alternative to using the border as well. Good spotting this Ramon.
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.
Ah gotcha, thanks for the explainer.
I was testing in the site editor where the effect wasn't so pronounced.
I wonder if there's another property to prevent margin collapsing, e.g,
display: flow-root;
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.
display: flow-root
is looking good from my testing.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.
box-shadow
is also an alternative to display a visual border without causing layout shiftsThere 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 think the goal was to prevent margin collapsing rather than displaying a border. The border in this PR is transparent.
See related: