Zoom out: fix scaling issues #65998
Merged
Zoom out: fix scaling issues #65998
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Size Change: -22 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 47b31ed. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11276671576
|
MaggieCabrera
added
[Type] Bug
MaggieCabrera
commented
Oct 10, 2024
|
Some related conversations here #65188 (comment) |
jeryj
force-pushed
the
fix-zoom-out-scaling
branch
from
12eee91
to
b530665
Compare
Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size.
This reverts commit 38de9fc.
jeryj
force-pushed
the
fix-zoom-out-scaling
branch
from
b530665
to
7af85bd
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Okay, that’s no fault of this PR, that’s consequence of #66018 |
jeryj
added
the
Backport to WP 6.7 Beta/RC
|
There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch. PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk. |
2 tasks
getdave
pushed a commit
that referenced
this pull request
Oct 11, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]> # Conflicts: # packages/block-editor/src/components/iframe/style.scss
|
Trying a manual backport in #66047. Reviews appreciated. |
kevin940726
pushed a commit
that referenced
this pull request
Oct 14, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]> # Conflicts: # packages/block-editor/src/components/iframe/style.scss
kevin940726
pushed a commit
that referenced
this pull request
Oct 14, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]> # Conflicts: # packages/block-editor/src/components/iframe/style.scss
kevin940726
added
Backported to WP Core
ciampo
pushed a commit
that referenced
this pull request
Oct 14, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]>
ajlende
added a commit
that referenced
this pull request
Oct 16, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]>
ajlende
added a commit
that referenced
this pull request
Oct 16, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]>
ajlende
added a commit
that referenced
this pull request
Oct 16, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]>
jeryj
added a commit
that referenced
this pull request
Oct 17, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]>
draganescu
pushed a commit
that referenced
this pull request
Oct 17, 2024
This reverts commit 12a7294.
draganescu
pushed a commit
that referenced
this pull request
Oct 17, 2024
* changed from using borders to use pseudo elements * added comments * Include frame size in the scaling calculation Instead of adding the frame size as a border (which causes reflow issues), include the frame size in the scaling calculation so there's always a left/right gutter of the frame size. * Account for scaling in the frame height * Calculation in CSS * Revert "Calculation in CSS" This reverts commit 38de9fc. * Add comment about why the calculation for scaling needs to happen in the JS * Force px value for frameSize * Restore previous frameSize var setting * Add back line break * Use padding top/bottom instead of before/after for top/bottom frame * Remove more before/after css since we are using padding --------- Co-authored-by: Jerry Jones <[email protected]> Co-authored-by: Alex Lende <[email protected]> Co-authored-by: MaggieCabrera <[email protected]> Co-authored-by: jeryj <[email protected]> Co-authored-by: ajlende <[email protected]> Co-authored-by: richtabor <[email protected]> Co-authored-by: ndiego <[email protected]> Co-authored-by: getdave <[email protected]> Co-authored-by: talldan <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Closes #65757.
As @stokesman discovered in #65814, we need to account for the frame size in the scaling in order to prevent reflows of the content. This PR takes that idea in a slightly different direction.
Why?
The trunk implementation uses a
borderapplied to the iframe to offset it from the edges of the frame. Applying the border causes a reflow of content because the border is included in the width of the html element.Margin and padding both cause the same problem as they are on the inside of the iframe. And the
box-sizingproperty also doesn't work because we're working within the iframe.We need the iframe to be full width of the canvas to be able to scroll anywhere in the zoomed out canvas area and avoid double scrollbars. Because of this, any offsetting needs to be done within the iframe.
The fix then, is to apply the frame size into the scaling calculation for the width. When we scale the canvas, we need to make sure it scales far enough that it also includes the frame size offset. This means we can remove the border (no reflowing) and preserve a frame offset.
How?
paddingas it seems to work across browsers (unlikemargin) and makes more sense contextually (unlikeborderor pseudo-elements).frameSizein the calculation forscaleso that none of thepadding/margin/borderare included in the width calculation.Testing Instructions
Follow @stokesman's testing procedure from #65814.
Visually, this means that content will not reflow when zoom out is engaged.
Testing Instructions for Keyboard
Screenshots or screencast