Implement the image resize handler

[oleq]

The functionality of the enhanced image plugin in v4 is missing in v5.

A follow-up of #1330.

---

If you'd like to see this feature implemented, add 👍 to this post.

[100cm]

i'm very excepted to see this feature can be implemented ! thank you again ! Ckeditor is the best editor !

[programad]

Thank you guys for the awesome editor. Any news on this item?

[oleq]

@programad It's in our backlog ATM, which means it's among our top priorities. But there are so many of features like this one I cannot tell you the exact ETA.

[oleq]

The feature has been requested in #1401.

[bizsimon]

Thanks for the awesome work on CKEditor 5. This feature is essential to any CMS that supports image uploads.

[mechanicals]

I am planning on integrating it in our company and getting the license.
But, the image resize is a very important feature for us to use this editor.
Any ideas, if this feature has a chance to make to production.

[mlewand]

As you might see we started working on this in this iteration. Though the date is not written in the stone just yet, we currently plan to release this iteration somewhere between 4-6th of June.

That being said, the feature will land in the code repository earlier than that. So if you can't wait to play with image resizing, be sure to subscribe this issue so that you're notified when the feature is available for the preview.

[mlewand]

I did some research on that matter. Below are the findings.

Image Resize

First off, not only image requires resizing, there are few candidates that might use it:

• image
• media embed
• table

Discussion

Handlers (must-have)

• multiple resize handlers
  • Google docs
  • Firefox/IE native contenteditable implementation
  • MS Word
  • TinyMCE
  • Froala
• single handler
  • CKE4:
  • Prose mirror 3rd party contrib:
  • Redactor

Based on the trends we should start with multiple resize handlers. There are a few pros for that:

• people are more familiar with it,
• we don't have to worry about bidi,
• aspect ratio issue (see "Aspect ratio" section) is solved

The main issue is that it clutters the UI once the resized entity gets hovered/focused.

Handlers position

Often times we're using captioned image. In that case it sounds only fair to bound handlers to the wrapper.

Aspect ratio

Should aspect ratio be locked? Should interface allow to lock unlock aspect ratio? Or maybe should it only be doable with keyboard modifier, e.g. holding a shift/alt or not.

Having multiple resize handlers, we can skip the feature and force corner handlers to keep the aspect ratio, while others will resize only along a single axis.

Limiters

One might desire an option to constrain min and max size of resized object.

Accessibility

Any feature of the editor should be accessible, this includes resizing too.

As an example for shapes (this does not include image) MS Word support shift+arrow. It supports alt+arrow for rotating images.

Accessibly doesn't necessairly needs be implemented as handling resizing using arrow. If we'd have some sort of accessible dialog that would allow for setting the size, that would be fine too.

Widget Features

Since this particular feature will be reused over other widgets it has to be implemented with a reusable API. We can think of it as a widget feature that should not be limited to images only.

There are several candidates like that:

• resize
• drag and drop
• upload
• overlay

So it would make sense to create a common API called widget features, that would serve as a framework for such drop-in self-contained feature implementations.

API

An example API might look something like that:

import { toWidget } from '@ckeditor/ckeditor5-widget/src/utils';
import { ResizeFeature } from '@ckeditor/ckeditor5-widget-feature-resize/src/resize';

// Simplest, hardcoded usage:

// (…)
return toWidget( viewElement, writer, {
		label: labelCreator
		features: [
			ResizeFeature(),
			DragAndDropFeature()
		]
	} );

// More realistic, configurable usage:
// (…)
let features = [];

if ( config.image.resize !== false ) {
	features.push( ResizeFeature( config.image.resize ) );
}

if ( config.image.dragAndDrop ) {
	features.push( DragAndDropFeature( config.image.dragAndDrop ) );
}

return toWidget( viewElement, writer, {
		label: labelCreator,
		features: features
	} );

Note this is just a concept, I haven't yet verified it with any PoC.

Summary

IMHO our implementation should feature multiple resizers. It gives more functionality, we also don't have to worry about aspect ratio and bidirectional lang handling at a cost of slightly cluttered UI.

As for API I need to prepare PoC first to figure out if it plays the way I expect it to do. There's one thing that I'm worried about, where I'd need static listeners that should be initialized despite a widget was created or not (e.g. upload widget feature, that would listens for drops over the editable containing a certain mime type).

[saravana34]

@mlewand
Hey. when will be this on live on master branch?
I was not able to find this module @ckeditor/ckeditor5-widget-feature-resize/src/resize

can you let me know how i can install/use this module in ckeditor-5

[mlewand]

@saravana34 we're still in the design phase. We aim to ship it within current iteration. Subscribe the issue and you'll get notified once the pre-release is ready 🙂

[kamalkemo]

I hope this can be done soon , it is a necessary feature

[Nothing-Works]

This is feature is a really good one, so please make add it in thank you, guys.

[sunkid1995]

this is feature is good, i need feature !!!

[100cm]

Almost a year in the past，any process on this?

[premsanth-rajamani]

@mlewand looking forward for the fix.. please keep us updated

[swebsas]

Any update or walk through?

[bizsimon]

@swebsas Iteration 26 roadmap includes it and its due on August 19th. it's coming, finally :)

[mlewand]

🎉 Preview available 🎉

Hey all! We've been silent for last couple of weeks as we've been working hard to prepare a preview of our image resize feature and I'm pleased to share it with you.

You can find it on https://ckeditor5.github.io/misc/image-resize/ - please give it a try!

Introduction

The image resize handlers will be shown once you focus the image (click it or navigate there using the keyboard).

There are couple of details, like inconsistent cursor or resizers not disappearing when editor is blurred - which we're aware and will be ironed out during next couple of days.

Feedback needed

There are couple of questions that we'd like to ask community:

• The image size is saved as inline width style applied to img element in pixels. We're wondering whether there are use cases when you'd like to use percents rather than pixels? If so please, let us know the use cases.
• By default CKEditor's 5 side images have max-width limited to 50%. It doesn't feel right to be limited to that when using the resize feature, so we decided to add a class ck_resized to the figure once image is resized - in which case it doesn't have this limitation. It also gives an easy option to customize it in case developer decides that such images should be in fact limited. We don't see any downsides here, but feel free to share your opinion.

Naturally if you'd like to share any thought beyond that, feel free to do so!

Timing

We also decided to push back the release by one week so we have more time to discuss it.

[Reinmar]

Great job, @mlewand! Resizing works great 👏

The image size is saved as inline width style applied to img element in pixels. We're wondering whether there are use cases when you'd like to use percents rather than pixels? If so please, let us know the use cases.

All the RTEs use pixels, but I think this is wrong. This makes the images completely unresponsive. How do you know how wide the content that you're displaying will be? The column with the text may have 900px on desktop, but 500px on mobile.

Therefore, I think we should use percentage values. This will ensure that images scale well with the content. E.g. we use percentage values in the default image styles (side image has max-width 50%).

However:

• Should the feature be using percentage values by default?
• Should we support both modes? Or can we support only percentage values?
• How will percentage values work in tables?

By default CKEditor's 5 side images have max-width limited to 50%. It doesn't feel right to be limited to that when using the resize feature, so we decided to add a class ck_resized to the figure once image is resized - in which case it doesn't have this limitation. It also gives an easy option to customize it in case developer decides that such images should be in fact limited. We don't see any downsides here, but feel free to share your opinion.

I generally like this idea. It makes the image styles and image resizing features cooperate well. You first make the image "aside" (or "left/right/center aligned", depending on your settings) and the image momentarily changes its width to the hardcoded 50%. But thanks to the image resize feature, you can override that value. Once you start resizing, the image's style should be overriden and for that we need the new class.

By using the class we give the developers full control over how they are going to handle that. E.g. one may decide to set min/max-widths for resized images too.

The only minor detail is that this class should rather look like ck-image__resized, AFAIK.

[scofalik]

I am missing a way to bring back the image to the original size. I could see that as a button in image toolbar or even like double-clicking on a resize handler.

[scofalik]

Also, it would be nice if the demo provided upload adapter -- I wanted to check how it works with biiig images.

[Reinmar]

I am missing a way to bring back the image to the original size. I could see that as a button in image toolbar or even like double-clicking on a resize handler.

Yup, this is a followup. Basically, we need a UI with an input for width so the feature is accessible and we can add more options, such as resetting the size.

[Reinmar]

BTW, to people who reacted with 👍 to this comment – does that mean that you agree that the feature should use percentages? And if yes, do you think you might also need pixels in some applications (so we should support both options)?

We'd be grateful for feedback on this because for us percentage values are the right direction because of content quality (its portability), but we know that there are many use cases in which CKEditor 5 is used, so we don't want to skip something unintentionally.

[chipcullen]

@Reinmar the use case I had in mind was a page builder widget that could be rather narrow, but also rather wide, and dependent on viewport size. For all of those reasons, a % based implementation made more sense, to me.

Being that the initial implementation was in px, though, I think reflects an instinct that people will want a fixed size.

My suggestion is to have a way to do both - be it a config option or some other mechanism.

[sashi-yadav]

@Reinmar supporting percentage will be good for device compatibility. And some might prefer pixels for precision having both will be good if possible.
And the reset button will also be a good feature.
And yes if the demo supports image uploading it will be helpful.

[mlewand]

Thanks for initial feedback @chipcullen @sashi-yadav, appreciate it. In case plugin supports both pixels and percentages sizes, how would you expect it to be set up?

Is it enough to allow developer to decide that on a per-editor basis (via config) or should it be something that can be changed during runtime?

[totorean]

Maybe, there could be an input near the alignment options for the image with a toggle to switch between px and %.

You can enter a value in the input and default would be %.

If you resize by handles, it would set the width in whatever you toggled it to be in the toolbar (px or %) and also the value of your by-hand resize would show in the input (it is bidirectional).

Maybe be able to change the default in the general config.

[scofalik]

☝️ and then removing everything from the input would reset the image.

[dkrahn]

Just to give some feedback and ideas:
For my case, it would be better in px.

About using percent scale, I think there should be a way to set min/max, as the image could be small and get really ugly in big screens. But don't know how this would be done.

An idea about using % or px, when resizing from the drag points, use absolute, and if you want %, use the input as @totorean posted in the image.

[totorean]

@scofalik @dkrahn @Reinmar I edited my comment ☝️to be more clear (sorry). What I suggested was to put the power of decision between px and % in the hands of the end user of the editor, not the developer that includes it in his site. The developer should just set a default in the config. Dunno if this is even possible :)

[totorean]

A use case:
I have a page with the editor and users create content in it and retrieve the HTML when they are done to include in their web page.

They know best if they want px or %.
Or a mixed scenario: use px for an image that is not present on mobile (hidden with media queries) and % for an image that is present on mobile.

Also, users understanding px better than % is a recurring argument, but if the input data is bidirectional, they can resize by handles, then go to the input in toolbar and see it is actually 23.7 % and set it to 24% or switch to px and see it's 203px...you get my point.

[bizsimon]

First of all, thank you for the amazing work.
In my use case, % would actually work better.
For my understanding, given the current state of the CKEditor 5, most of the styling of the content is relied on the front end, outside of the WYSIWYG itself. The wrapping container's size could be anything really. Making the image size by percentage, IMO, makes the sizing relative to its container regardless of the size of the container.

[dkrahn]

@totorean I understood your comment, I just used your picture as a reference the input.

To be clear this is my personal opinion
It seams to me as the user sizes the image dragging its corners, feels more like he want's to use the actual size(in px), while in the input, it could be either. And if the user want's to user percent, IMHO it seams as he would inform how much, like 50%, 40%... but not dragging around like 39.54%. But if possible to have both and use it in the toggle or in configuration, seams optimal. And since it has been pointed out as desired, who am I to say anything. It is just a feeling of mine, no hard background for anything of the kind.

I think that, IF POSSIBLE, @totorean idea is perfect.
IMHO the config could have a few properties:

• Available Units: today: [px, %] Future: (don't know IF POSSIBLE/useful) like em, mm, in...
• Default unit
• Max size
• Min size

This way if the developer decides that in his context, only px is valid, he can set available units to [px] and that's it.

[Reinmar]

The base image resize has just landed on master 🎉

There have been some last minute changes needed when we started working on support for percentage values. It turned out that we needed to move the width style to <figure>, otherwise it didn't work well with small images. But this actually makes sense because image styles (this is - the image style feature) sets width on the figure as well. We should've actually caught this earlier.

Still, the thing that the user is resizing is the image. That's where the handles are displayed. And this creates some nasty cases. There's even more if we consider centered images, display:table that we use to style <figure>s, max width (as limited by the container and the max-width style), etc.

In other words, this seemingly simple feature has a tone of complexity inside :)

Therefore, we're really happy that it made to the master and is on the straight road to the upcoming release. It will use percentage values by default but it supports px values too.

That said, this is for sure the first step. We need some sort of input for the size values. Perhaps also some buttons for predefined widths. We'll be still processing your feedback from this ticket, but you feel free to open new tickets for specific extensions that you'd like to see.

Thanks everyone for feedback and ideas. And @mlewand for a lot of hard work that he's put into this feature 👏

[adrianmihaila]

Hello, I and my colleague just released a plugin that allows you to edit the size of an image using width and height input, as well as providing an aspect ratio lock tool that makes it easy to scale without distorting the image.
The plugin is here: https://github.com/eMAGTechLabs/ckeditor5-classic-image-resize.
You can give it a try 🙏🙏. Also, any suggestions or feedback are welcome 👍👍.

[oleq]

@adrianmihaila Give a thumbs up in #5198 if you want this to be a core feature 😀

[vineetsingh065]

@mlewand @oleq Hi is the image resize handler plugin added into django ckeditor?

[mlewand]

@vineetsingh065 We're not maintaining any CKE5 Django integration, so you'd need to ask this the package maintainer.

That being said, even if such integration doesn't support it, CKE5 is a plain JavaScript integration so you can make your own build using our online builder and for sure there's a way to include a js library in Django.

[joelpittet]

Drupal is considering changing the default to px here BTW https://www.drupal.org/project/drupal/issues/3348603 See the examples for why % posses a problem for figcaption, image alignment, and cached serverside resize solutions.

[joelpittet]

Lots come down to a common practice for responsive images to follow: img { max-width: 100%; height: auto; } and the prevelence of bootstrap https://getbootstrap.com/docs/5.3/content/images/#responsive-images

[Witoso]

Hey @joelpittet, thanks for reaching out! I already answered on the Drupal issue, cross-posting some information here for the reference. We chose `%`, as a lot of people may not know the exact size of the container in which the content will be used. Often, content is used in multiple destinations at once. With pixels, one gets far less flexibility with how the content will be used in the future.

As for the responsive option for the image, let us discuss it internally, and I will get back to you as soon as possible.

[joelpittet]

@Witoso The % for in the editor kinda makes sense, the problem is completely in the end result. I could be way off, but I can't see a world at the moment where <img width="46.52%"> is beneficial from a designer view point and user view point. At smaller sizes that won't be tenable, that is one of the the reasons img { max-width: 100%; height: auto; } is so common in CSS frameworks. I concede I could be looking at this with an "old lens" and this is the future, but at the moment seems like an oversight.