Ckeditor5: Inline images - support multiple images in a single block

Created on 17 Sep 2019  ยท  12Comments  ยท  Source: ckeditor/ckeditor5

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: https://github.com/ckeditor/ckeditor5/issues/8666
Nice to have features: https://github.com/ckeditor/ckeditor5/issues/8712


If you'd like to see this feature implemented, add ๐Ÿ‘ to this post.

Epic image ux 2 feature

Most helpful comment

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']
});

All 12 comments

any work around/alternative for the time being?

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

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']
});

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

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

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

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:

Screen Shot 2020-09-17 at 8 59 54 PM

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

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 :(.

number_systems

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.

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>.

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.

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.

Screenshot_33.png

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Reinmar picture Reinmar  ยท  3Comments

PaulParker picture PaulParker  ยท  3Comments

wwalc picture wwalc  ยท  3Comments

jodator picture jodator  ยท  3Comments

benjismith picture benjismith  ยท  3Comments