Size Change: +11 B (0%)

Total Size: 2.54 MB

_{compressed-size-action}

I think there's only one thing left to do here, or two, depending on how we want to go ahead:

The image's aspect ratio on trunk behaves a little erratically onRotate. It flips onRotate, but doesn't honour the users' chosen aspect ratio thereafter. Even if you select square (1:1) it loses the aspect ration onRotate.

This branch honours the users' chosen aspect ratio and maintains it onRotate, but the aspect ratio doesn't flip.

Here's how I think it should work:

Unless the user has selected an aspect ratio other than the default (width/height) aspect ratio, then flip the aspect ratio.

The second I was speaking out is that we split this PR seeing as we know it's working now:

1. Create the package
2. Implement the package

I think that's the go!

Unless the user has selected an aspect ratio other than the default (width/height) aspect ratio, then flip the aspect ratio.

Yep, that's how I'd expect it to work, too.

The second I was speaking out is that we split this PR seeing as we know it's working now:

1. Create the package
2. Implement the package

Sounds good! We could also look at trying to add a Storybook story to the package as part of step 1 to provide example usage / put it through its paces?

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: tellthemachines <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Just gave this a quick test. I think we might need to scale the image down a bit on rotation if the container has a fixed size, otherwise it gets cut off:

Any reason we're not adding aspect ratio controls to the story?

Thanks for testing!

Just gave this a quick test. I think we might need to scale the image down a bit on rotation if the container has a fixed size, otherwise it gets cut off:

I'm thinking this should be the responsibility of the implementation. For example, it could be done by calculating the max scaled size of the container when the image renders.

The current block editor has its own funky workaround, which something like that might break. See #73277

Edit: Did you just mean in the story? Sorry, I jumped ahead. If so, then... can do!

Any reason we're not adding aspect ratio controls to the story?

No reason. It's up to the implementation, but no harm in adding them. Thanks!

I think we might need to scale the image down a bit on rotation if the container has a fixed size, otherwise it gets cut off:
Any reason we're not adding aspect ratio controls to the story?

Thanks again, folks!

I fixed the types. I'll update the story with the above tomorrow.

Edit: Did you just mean in the story? Sorry, I jumped ahead. If so, then... can do!

I didn't mean specifically one or the other 😄

It would be nice if this just worked out of the box when adding the package. But if that's not doable, then adding the necessary code in the story for it to work properly is the next best thing. Both because the story represents the component, so it's not great if it appears broken, and also because the story is a good reference for when you need to understand how to use the component, so if there are necessary additions to make it work properly they should be included there.

But if that's not doable, then adding the necessary code in the story for it to work properly is the next best thing. Both because the story represents the component, so it's not great if it appears broken, and also because the story is a good reference for when you need to understand how to use the component, so if there are necessary additions to make it work properly they should be included there.

Makes sense, thanks for the explainer.

The reason I hesitate to add custom code that changes the behaviour of the container in the package is because it assumes an environment that might not be there. I think, for now, it's good to be flexible until we see this working in several "containers", e.g., the existing block editor, and in the future, a media library or something.

I'll update the story and we can always come back to it.

Thank you @andrewserong!

I'll follow up on:

• Implements the image-cropper package in the editor. #73277