Playground, `ImageResizer />`: image overflows - `width`/`maxWidth` issue?

• This issue comes from the playground example.
• The <img /> component styling has not been altered
• I am happy to create a PR if y’all think the below is an actual issue and not something I’m missing/not understanding fully.
  • If I’m missing something could someone please elaborate on usage of this?

Lexical version: v0.5.0

Steps To Reproduce / The current behavior

1. Add image with “Insert image”
2. resize the added image to some size
3. resize the screen to something small and see the original image overflow-x

Enough space for set width:

Small screen (not enough space) for set width:

The expected behavior

Image to be resized to the desired size IF the screen space allows for it, otherwise shrink to maxWidth: 100%, which would result in something like this:

[acywatson]

Yea, this sounds like it could be improved. PR is welcome here.

[ScottAgirs]

Hey Acy,

Wooho, sounds great, will do! I’m taking off for conference travels for next 2 weeks, can’t wait to be back and set up a Zoom coffee “)

Cheers, @SᴄᴏᴛᴛAɢɪʀs On Oct 26, 2022, 4:59 PM +0300, Acy Watson @.***>, wrote:

I’m not sure if this is a bug or the expected UX. I think this would be the expected behaviour if the editor was in readonly mode, in which case we could make the image responsive for smaller viewports, but if we want the user to explicitly set the pixel value of the underlying image, we shouldn’t probably then override that if the editor viewport becomes smaller (with I’m presuming an intersection observer?). I don’t think you need an intersection observer for this. It’s just about preserving the aspect ratio of the img AFAICT, which should be something we can do with CSS. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>