-
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 Out: Use the zoom-level value to scale the iframe #66280
Conversation
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. |
Size Change: +37 B (0%) Total Size: 1.81 MB
ℹ️ View Unchanged
|
@@ -354,7 +354,7 @@ function Iframe( { | |||
// but calc( 100px / 2px ) is not. | |||
iframeDocument.documentElement.style.setProperty( | |||
'--wp-block-editor-iframe-zoom-out-scale', | |||
scale === 'default' | |||
scale === 'auto-scaled' |
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.
Is this just a case of not wanting to set a scale as a percentage, but instead a certain width?
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.
Because it seems this "auto scaling" is just a hardcoded 750px width.
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.
Yeah, I'm not entirely how the computation works, it's computed using the actual width of the window and a maxWidth of 750 for the zoom-out area.
I would be fine removing it and setting a percentage but I don't have too much context here.
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.
My point is: does it make sense to have a % API? Are we using that as third party somewhere? Would a width work there instead?
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 good point, Well, in my mind, the zoom level becomes kind of like a range picker (see the storybook), in which case the % API seems better no?
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 always saw the state as representing a percentage of zoom 👍
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.
Any way we can make this auto scaled private? Maybe a symbol?
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 PR breaks section selection - when zoomed out sections inner blocks are directly selectable.
@draganescu Good catch, it's fixed now. |
bb92c9a
to
f0c2542
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.
Would be nice if the string is a symbol instead, it's anyway all within the block editor package?
For now, all of that is still a private API. |
Co-authored-by: youknowriad <[email protected]> Co-authored-by: ellatrix <[email protected]> Co-authored-by: draganescu <[email protected]> Co-authored-by: getdave <[email protected]>
This is an |
setZoomLevel, resetZoomLevel are private APIs, what APIs are you talking about here? |
The |
Right, I missed that part. The Iframe component was introduced before we introduce private APIs, so it's not entirely stable, it's one of these APIs where we need to be careful of the changes we do, check usage... but we should still consider changes if there's no impact. The reason is these prefixed APIs were introduced without thoughtfully thought for public access, they were never meant to be stable. That said, I'm curious here, did you face an issue somewhere? I'm happy to take a look. |
Just had an old branch before the change that I rebased and wasn't working because of this. It was just a matter of changing the string, but I figured I should mention it because of possible 3rd party consumers of the component. And I wanted to make sure I wasn't imaging things about I don't expect many 3rd party consumers are using it, but maybe it's worth a dev note or something since it is technically a breaking change. |
Good call, I added the dev note flag. |
Related #50739
What?
We have a "zoom-level" state in the block editor but it's not really used, we just force an automatic scale in the frame.
This PR updates the block editor package to actually use the value.
I kept the automatic scaling in place so the zoom level value can be either "auto-scaled" or a number between 0 and 100.
Why?
This is a preparation to open a public API for the zoom level.
Testing Instructions
npm run storybook:dev
to check it.