Inline images - support multiple images in a single block

[ateeqsuhail]

Is this a bug report or feature request? (choose one)

🆕 Feature request

💻 Version of CKEditor

CKEditor version 5, decoupled document build

📋 Steps to reproduce

1. insert one small image
2. insert another small image

✅ Expected result

Two small images should be in same line with space e.g. Image1 Image2

❎ Actual result

Currently they are stacked up from top to bottom.

---

Future work

MVP step 2: #8666
Nice to have features: #8712

---

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

[ateeqsuhail]

any work around/alternative for the time being?

[PascalMarechal]

As ateeqsuhail said is there any workaround to make it work for now ?

[kleinph]

I developed my own plugin for this. I used the image plugin as example and tried to reuse as much code as possible. The schema of course is different:

schema.register('inline-image', {
	// Allow wherever text is allowed:
	allowWhere: '$text',

	// The image will act as an inline node:
	isInline: true,

	// The inline widget is self-contained so it cannot be split by the caret and can be selected:
	isObject: true,

	allowAttributes: ['alt', 'src', 'srcset']
});

[ateeqsuhail]

I have downgraded to version 4, since it has all the features.

[castroCrea]

Hello @kleinph,
Can you share your plugin ?
Thank's

[kleinph]

I am not entirely sure, because I built this for a former employer. Also its not 100% perfect.

[wwalc]

One very valid use case that requires supporting inline images reported by our customer: in an internal application for sending messages many times users start an email from copying/pasting content from other sources/emails.

In those quoted emails, people have in the footer links to socials that consist of separate small inline (linked) images:

when those images are pasted, they become block images that take the whole width of the page, which of course looks wrong.

[milossramek]

Another valid use case: Inline images should sometimes be used as 'letters', as for example in the attached screenshot of article about ancient number systems. It was written in CKE4 :(.

[Reinmar]

We discussed with @oleq some UX aspects of this feature.

• The inline images feature should be optional (opt-in) and, most likely, will not be part of any of the builds.
• An image must be either inline or block. It needs to be clear from the perspective of a model structure where that particular image is allowed and those checks must be done based on element names.
• Moreover, for a sane UX, it may also be good to differentiate both image modes and allow toggling between both states in an explicit manner. We should avoid similar pitfalls that we fell into in CKE4 where it's unclear why a certain image can be dragged as a block (between blocks) and another one as an inline object (within a text). In CKE4 the user can turn an inline image into a block image but it's impossible to turn a block image back to an inline image.
• Therefore, we consider adding a toggle button into the image toolbar for controlling whether it's inline or block. Toggling it may also disable other options such as whether the image can be aligned.
• When a block image is transformed into an inline image, it should simply be wrapped with <p> (other option: merged to a nearby block).
• When a captioned image is transformed into an inline image, its caption should be removed visually and from the data but it can stay present in the model so when the user toggles back the caption appears. This is to save users from losing the caption content. Note: caption will be lost during copy-paste as it's not present in the data unless we decide to keep it as some attribute.
• The most challenging aspect of this feature is the UX around inserting images. How can the user decide to insert an image in the middle of a block?
  • By default, the editor should be configured to insert block images as this seems to still be the most frequent scenario. We might do this configurable for developers, but it would still not make the workflow easy for users when they insert block/inline images 50/50.
  • We might implement some modifier (Alt/Shift) that'd:
    • change the behavior on paste,
    • change the face and behavior of the "insert image" icon to insert inline images,
  • Memorize the selection position and content before the insertion so, even though the image is inserted like a block, when the user clicks the "turn into inline" button that block-level insertion will be reverted and the image will be reinserted as an inline image, thus saving the user from having to manually merge split blocks or cut-paste an image from outside of the block to inside it.
  • But, most importantly, we can also do nothing here (in an MVP), if we ensure that an inline image, when copied, is pasted as an inline image. The workflow will still not be the greatest (you insert as a block and then fix manually by cut-paste), but the user will be able to achieve what they want in a reasonably quick way.

[Reinmar]

More notes:

• We need a new element in the schema due to the fact that this element will be allowed where $text is allowed and the <image> element isn't. Also, <image> can contain <caption> while inline image cannot.
• In the data, we should output just <img> without <figure>.

[Reinmar]

More notes: We need to design a heuristic for detecting whether an image that's being inserted is inline or not. Some examples:

• images in empty blocks,
• images with small width/height.

[pkwasnik]

About heuristic, I think that should be something simple and predictable, so users will always know what will happen. The best will be only one detection rule. Detecting using with/heigh leaves too much ambiguity: why this 50x50px inserted image is inline, and 55x55px image inserted next to it is a block? What should be the size limit? I propose detecting only by the place of insert: Inline between text or in a list, block in an empty paragraph. After analyzing feedback from the users I see that the most popular use case for this feature is to just insert an image between text.

There is also one thing to discuss: Inline/block switch Icon location and design. For the location, the balloon seems to be reasonable. But we need someone to design the infographic.

[oleq]

🛠 It's been a while since the last update, so here are the highlights from the past couple of months. 

P.S. You can check out the latest code in the live feature branch. 

What's new?

Inline image insertion and resize

The editor not only accepts inline images but provides feature parity between block and inline images. Both types of images can be uploaded, styled, resized, alt-texted, and support srcset (responsive images) out of the box.

Adding captions to inline images (inline->block conversion)

Inline images cannot be captioned but users can quickly turn them into blocks by adding the caption. The caption is preserved between various image styles (turning a captioned image into inline, then back to block will preserve the content of the caption).

New image styles

The ImageStyle plugin has been refined and offers more styles that reflect real-life scenarios. By default, images can "be in line" (like emoji), "wrap text" (both inline and block images) or "break text" (only block images).

TODOs

Although the core of the feature is ready, there are still a couple of major of tasks down the road:

• Unification of the widget insertion UX (it will affect more than just images),
• Clipboard support (for instance, paste integration with Word, Google Docs, etc.),
• Integration with the link feature,
• The new feature guide (to showcase new features and also to help developers migrate)

[oleq]

📢 I have some good news I would like to share with anyone interested in this feature 📢

After over half a year of development, the core of inline images has been merged to master and it will ship in the upcoming release of CKEditor 5 🎉.

TL;DR: See inline images in action.

Here are some highlights:

• Inline images work with all core editor features (also collaborative features such as Real-time collaboration or Track Changes). They are also enabled out-of-the-box in all official editor builds.
• Depending on the context, the editor will pick the right type of image to insert (upload). For instance, inserting an image into an empty block will create a block image but inserting an image in the middle of text will create an inline image to avoid splitting the paragraph. This behavior is configurable.
• We realized over the course of development that the current default image styles set doesn't work well with inline images. A new one was created from scratch to better reflect real use-cases. Also, to make the configuration easier, we categorized default image styles and grouped them in configurable drop-downs.
• We also realized that the current UX of adding image caption only when the image gets selected does not work well in the context of inline images (and new image styles). From now on image captions are toggled on demand using a toolbar button, which also prevents the editor content from jumping around when navigating image widgets and allows drag and dropping content into an empty caption.
• A number of breaking changes were introduced in the process. Check out the migration guide to CKEditor 5 v29.0.0 to learn more.
• There were ➕17,193/➖5,078 changes made in 476 files in the ckeditor5 repository alone. Nearly all image sub-features have been revamped and improved. The number of tests in the ckeditor5-image package doubled since the last editor release.

That's it for now but stay tuned. The release of CKEditor 5 v29.0.0 will be announced on the blog in July.

[AdamMiltonBarker]

We have the latest version from the cdn and none of these features exist?