-
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
ImageSizeControls: Replace ButtonGroup with ToggleGroupControl #65386
Conversation
…l and ToggleGroupControlOption
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. |
} | ||
value={ addSelectedScaleValue() } | ||
isBlock | ||
isDeselectable |
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.
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.
If we remove the isDeselectable
prop, keyboard users won't be able to set a custom value:
71dcd41756d30d74f869d014456c5284.mp4
As I commented here too, we might need to add an option called "Custom".
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.
keyboard users won't be able to set a custom value
This isn't inherently true — it's only because the logic of addSelectedScaleValue
doesn't account for it. In fact the current logic sets invalid values on the ToggleGroupControl, when it should be set back to undefined
instead. (cc @hbhalodia)
For the sake of this PR, I'm ok with just replicating the existing functionality. And as it turns out, the Reset button doesn't actually reset, it just sets it to 100%, which is different from an actual reset. So to actually reset, the user needs to clear the width/height input fields. I think that means we don't even need a Reset button nor a "Custom" option to replicate the existing functionality.
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.
Hi @mirka, If I had read it correct, need to update the logic on addSelectedScaleValue()
function should return undefined
, when we set custom values? is that something need to changed.
Thank You,
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.
it's only because the logic of addSelectedScaleValue doesn't account for it. In fact the current logic sets invalid values on the ToggleGroupControl, when it should be set back to undefined instead.
Hi @mirka, I tried to set directly undefined on that logic, seems like anyhow keyboard user would ultimately land on the first option of the ToggleGroupControl
, which ultimately sets the first option even we have undefined set on that logic.
Can you please let me know how to set it undefined for keyboard users on that logic, because ultimately when user lands on the toggleGroupControl
it would call handleUpdateDimension()
which ultimately sets the dimension based on the scale size, and it would remove the custom dimension set.
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.
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 may have lost the plot a little bit, but I noticed that unit tests are failing because they require a "reset" button. With the changes from this PR, would a user be able to reset the value at all? Is that something that we should retain?
Again, apologies in case I missed the part of the conversation where we reached an agreement on that aspect.
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 a user be able to reset the value at all? Is that something that we should retain?
The reset button in the original was the functional equivalent of re-selecting the "100%" option. The user can also still delete the values from the number inputs. So, I'd say no functionality is lost.
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.
With the changes from this PR, would a user be able to reset the value at all? Is that something that we should retain?
In the current specification, when we press the reset button, the width/height values are set and 100% is selected. These values are not saved in the database. In addition, when we reload the browser, the width/height values and the 100% selection are cleared.
This lack of consistency bothers me, but at least the reset action is considered to be the same as 100%, so I think a reset button is not necessary.
4ba662ea53e68b1a6cfa11351a23a5db.mp4
The presence or absence of a reset button has been discussed in other PRs, and there may not be a complete consensus yet, but my understanding is as follows:
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.
Thank you, Lena and Aki — much more clear now. We established that no functionality is lost.
The lack of consistency is also bothering me. I say we merge this PR with the current UX, and then we look at opportunities for improving consistency across other PRs
packages/block-editor/src/components/image-size-control/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/image-size-control/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/image-size-control/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/image-size-control/index.js
Outdated
Show resolved
Hide resolved
<ToggleGroupControlOption | ||
key={ scale } | ||
value={ scale } | ||
label={ `${ scale }%` } |
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.
It might make sense for the percentage string to be localized. In some languages, it might actually be displayed differently:
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.
Do we localize other percentages across Gutenberg? If not, it may be better to split it to a separate PR to localize all percentages at the same time
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 do not think, we are localizing other percentage implementations, here is the example for column block -
const widthWithUnit = Number.isFinite( width ) ? width + '%' : width; |
I agree with @ciampo, to add all at once, so it does not block the scope of this PR.
Thank You,
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 filed issue #66298 regarding localizing percentage values.
…t scaledWidth and scaledHeight
Looks like unit tests need updating — the
|
Hi @ciampo, I would update the tests, Also to confirm, since we are not adding the reset button, should we remove the related test suite for the same? Thank You, |
I think so. We should make sure that we test the new logic highlighted by Aki in this comment |
You may want to update this branch with the latest |
As we've already entered the RC phase of 6.7, should we backport this PR to the 6.7 branch? Is this a fix of a regression introduced in the 6.7 cycle? |
This PR is part of #65339 and looks like an enhancement to me, not a bug. The following similar PR has already been backported, but this one is a bit more complicated than those two, so it might be safer not to backport it. |
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.
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.
Approving since all feedback is addressed. I suggest waiting for @t-hamano 's review as well, to test the new overall behavior as he highlighted in a previous conversation.
And thank you for the great work and patience, @hbhalodia 🙏
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.
Thanks for the update! I left one final small feedback, but I think it's ready to ship.
* | ||
* @return {Object} The scaled width and height. | ||
*/ | ||
function getScaledWidthAndHeight( scale, imageWidth, imageHeight ) { |
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.
Nit: While there are no hard and fast rules, it is generally a good idea to put any sub-components, hooks, or functions used internally by a component before the default exported components.
So, it might be a good idea to move this function 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.
Hi @t-hamano, Updated the PR to move the function before default export
.
Thank You,
I guess we're good to merge? |
…ress#65386) Co-authored-by: hbhalodia <[email protected]> Co-authored-by: ciampo <[email protected]> Co-authored-by: t-hamano <[email protected]> Co-authored-by: mirka <[email protected]> Co-authored-by: tyxla <[email protected]> Co-authored-by: kevin940726 <[email protected]>
What?
PR replaces the
ButtonGroup
component withToggleGroupControl
in the ImageSizeControls.Why?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast