I wrote a few words about how this can be achieved with minimal changes to existing editor creators: https://stackoverflow.com/questions/48896019/ckeditor5-inline-build-puts-a-p-tag-inside-of-an-h1-tag-how-do-i-disable-this/49130552#49130552

I'm curious if it'd work.

Here's a fiddle based on that suggestion. It does prevent new paragraphs from being created, but without the appropriate root there's still a child paragraph in the content.

https://jsfiddle.net/v81yndc7/2/

This is a hugely important feature for any app doing serious inline editing. It's not uncommon for headings, paragraphs, and even spans to be made editable.

We'll need to update https://github.com/ckeditor/ckeditor5/pull/1494/files#r255422201 after p-level editors are a thing.

The state of things

There's been some work in this area and it looks really promising.

Discussions:

• https://github.com/ckeditor/ckeditor5-editor-inline/issues/5#issuecomment-495128530
• Add manual test for inline editor created over non-standard elements ckeditor5-editor-inline#54

Branches:

• https://github.com/ckeditor/ckeditor5-editor-inline/compare/t/5
• https://github.com/ckeditor/ckeditor5-engine/compare/t/ckeditor5-editor-inline/5

Results:

Related tickets:

• https://github.com/ckeditor/ckeditor5-editor-inline/issues/3
• https://github.com/ckeditor/ckeditor5-editor-inline/issues/5

Plans

Those tests make us believe that there's not that much to do to enable such type of editors. I'm moving this up the waiting list.

The todo list:

• Final decision regarding whether $inlineRoot is the right direction.
• Minimal tests in every feature for their integration with $inlineRoot.
• Updating the inline, balloon and decoupled editors with the element name check. Tests.
• Documentation.

Are there any movements in this direction?

I would be interested in this as well

@Reinmar Is there any progress on this, or an ETA? Multiple similar issues have been closed pointing to this, but looks like this has been dormant for 3~4 years?

We're currently migrating from Redactor to CKEditor 5. Inline mode is really important – in many cases, you only want to have a single line of rich content consisting only of inline tags (<a>, <strong>, <em>) without allowing editors to add multiple paragraphs, or having the output wrapped in block-level elements.

Based on the number of issue related to this feature, many people are looking for something like this, so it deserves some attention.

Hey @MoritzLost! Thanks for bringing this to our attention. We will discuss it internally but as you can imagine we have even more requested features :) 

That said, I'm still curious @Reinmar about your thoughts. Looks like the topic caught your attention quite significantly. TBH I haven't heard about that many cases of single-line editors inside specific elements, etc.

I think there's never been enough traction to continue this work. The PoC that we built ~3y ago was actually pretty good already, but at the same time we're aware that making it production-ready and maintaining support for such editors will be yet another dimension in the features vs editor types vs configuration vs integration scenarios matrix 🙀

Fun fact: This issue was envisioned by us 10y+ ago and the engine is actually designed with this use case in mind. But over the years this ticket didn't get back to the top of the priority list (based on a relatively low number of questions/feedback/reactions). But since we tackled many of the higher priority things over the years, there's a growing chance it will finally get there.

But the honest tl;dr: no concrete plans for now.

@Witoso @Reinmar Thanks for the replies! I can only speak for our projects, but at least for those an inline editor is almost always necessary. Some examples in a CMS context:

• A field for the site headline (h1) where you want to allow editors to insert some styles, links, or emphasis in the headline, but not add additional paragraphs or other block-level elements that would break the layout. Ideally, in this case I would want the CKEditor output without the wrapping <h1> tags, because those are already part of the template.
• A field for a credits line in the footer, you want the editor to be able to edit this, and it needs to contain some links, but you only want a single paragraph in that position.

So at least for us, this is an important feature, and I imagine for others as well (based on the number of closed issues pointing here).

I think it would be fine if such a mode came with some restrictions as to what plugins or features are supported, usually those fields only need some rudimentary rich-text functionality (link, bold, italic), nothing special.

I will chime in to note that this is also important for us. We have been moving a lot more toward block-based tooling (notably Layout Builder in Drupal) and we almost continually run into cases where we'd like authors to be able to apply inline styling (<em>,<strong>, <abbr>, <a>, etc.) but where the context is a small chunk of a highly templated block or layout, and where block level elements would break the design or produce nonconforming HTML.

Some real world examples include headings; Drupal Layout Builder block headings are a distinct field on the block from the block content. There are all kinds of inline HTML elements that are perfectly valid and often desired (or necessary for accessibility) within headings.

As it stands we have three options, none of which are particularly pleasant: we need to either

1. Tell authors to use raw HTML in plain text fields (if that was an acceptable author experience, why are we using CKEditor at all),
2. Strip out block level elements in the content on render (which breaks the WYSIWYG ethos/contract — you most definitely don't get what you see), or
3. Accept that authors can break the design and/or conformance of the page, often accidentally (as you might imagine, that's a hard sell)

Hey @mryand, thanks for sharing this perspective, we are discussing this internally, and this is definitely valuable for us.

I want to share one additional method that might be useful in the nearest future, and it's usage of the multiroot editor. This kind of the editor would be the best to build some kind of layout builders. The only thing it misses is the dynamic configuration of allowed content/plugins/toolbar items.

+1

I'd love to see this feature as well for the same reasons @mryand stated.

Not to be that guy, but since it doesn't look like this will be getting official support with CKE, does anyone know of any other editors that allow inline editing that makes sense in a CMS context - i.e. single line or non-block element inline editing?

CKEditor is a non-starter for us due to this issue. We have pre-built HTML template snippets and we need users to be able to customize the content a bit (change text, add images, etc) with as little as possible modification of the underlying structure. The insertion of additional wrapper tags causes issue with parts of the CSS as it alters the parent/child relationships of tags in our HTML snippets.

I looked at this SO issue, but I don't understand the inner workings of CKE to know how to apply the suggestion to test it out.

Just FYI, I'm working on an internal frontend editor for our own CMS and hesitated between tiptap and ckeditor. I was about to choose CKeditor cause tiptap require a lot of work as it's completely headless, and, finally, I decided to go with tiptap due to that issue.

Inline editing inside a controled html tag is a must have feature and I'm choked to see that CKEditor released an inline editor without thinging to that use case from the begining.

Thanks for the feedback @PubliAlex. This is something that we are discussing internally as a potential future improvement.

I'm a little confused, why don't i see the issue happening with the example demo page here: https://ckeditor.com/docs/ckeditor5/latest/examples/builds/inline-editor.html. There are no unwanted "p" tags popping up, and additionally I can edit non-paragraph text like headings without any issue?

However, in our actual use of CKEditor 5, we do notice that unwanted "p" tags get added to elements that shouldn't have them and the above-mentioned issues other developers are having with CKEditor 5 to the point where we may have to abandon our usage of it in favor of some other editor. So I am wondering what the example demo is doing that the rest of us are missing?

The demo you've linked to, and the section you're pointing to, has a very limited number of plugins (check the config). That's why p are not that visible. The editor is attached to the header element but it's still not the same as attaching to h1 or paragraph-like roots.

Thanks @Witoso - so then my question becomes, what is the downside of removing the plugins when dealing with header elements? Is there a specific plugin known to be the problematic one that is adding the <p> tags everywhere?

Sorry for the late reply! Downsides, none, but keep in mind that I can still add a paragraph to this header area. So it won't solve the main problem of this issue: "just enable editor on this specific block element, and prevent other elements accordingly".

Is there a specific plugin known to be the problematic one that is adding the

tags everywhere?

We don't see this as a problem, the main engine of the editor was built in such a way to provide the best typing experience. Limiting the number of plugins, just limits the number of features.

Would be helpful if you could tell us how you use it and what the markup is, so we can understand it better :)

Thanks for the reply @Witoso , I appreciate the response. If you look at this https://jsfiddle.net/gratiafide/zvaLebx5/ you will see the following problem:

I see, yes, this is what needs to be fixed on our side. I don't see any workarounds that could be applied.

@Witoso are there any event hooks that we can use to remove the "p" tags before the HTML gets inserted?

None that I know of. @niegowski?

It looks like the restricted editing feature could be used for some of these use cases.

Make a template that has <h1>[Title]</h1> and one could in theory count on CKEditor5 producing only that heading with no paragraphs. Some server-side validation would still have to confirm this though, whereas the approach outlined in this issue would be more amenable to simpler validation and sticking the result into an H1.

One annoyance is possibly being forced to have placeholder text, though maybe with only one editing option it can be blank and people's cursor would go there automatically. Another likely annoyance is trying to hide the "editing toolbar button" as it is irrelevant with only one editable portion.

Also, regarding this issue not getting a lot of upvotes— it is really hard to find. This use case comes up anytime one has structured data (so, at least, it comes up a lot in Drupal and some other more powerful/complex content management systems).

@mlncn it seems like a pretty common issue to me as a basic install like this will cause it - https://jsfiddle.net/gratiafide/zvaLebx5/ this should be fixed as it's a major problem for some of us - #762 (comment)

Oh i absolutely agree.

My current workaround in Drupal is to make a text format that only allows paragraph tags (no other block elements like titles) and then strip those paragraph tags out with a module we made just to deal with CKEditor5's recalcitrance here: Strip paragraph tags filter.

I am integrating a audio / video extension within Drupal CMS and CKeditor5. After defining the schema and using the proposed definitions, everytime there is a

wrapper tag around those elements:

schema.register('cke5MediaAudioWrapper', {
allowWhere: "$block",
isLimit: true,
isObject: true,
isBlock: true,
isSelectable: false,
allowChildren: ['cke5MediaAudio', 'cke5MediaAudioPreview'],
allowAttributes: [
'class',
'data-settings'
],
});

schema.register('cke5MediaAudio', {
  isObject: true,
  isContent: true,
  isBlock: true,
  allowIn: ['cke5MediaAudioWrapper'],
  allowChildren: '$text',
  allowAttributes: [
   'data-media-name',
   'data-type',
   'loop',
   'preload',
   'name',
   'src',
  ]
});

conversion.for("upcast").elementToElement({
  view: {
    name: "div",
    classes: ['c-audioplayer']
  },
  model: "cke5MediaAudioPreview",
});
conversion.for('downcast').elementToElement( {
  model: 'cke5MediaAudioPreview',
  view:  {
    name: 'div',
    classes: ['c-audioplayer']
  }
});

// or:

conversion.for("upcast").elementToElement({
view: {
name: 'audio',
attributes: [
'data-media-name',
'autoplay',
'loop',
'name',
'preload',
'src'
]
},
//converterPriority: "high",
model: ( viewElement, { writer } ) => {
const entityAttributes = {
'data-media-name': viewElement.getAttribute('data-media-name'),
'autoplay': viewElement.getAttribute('autoplay'),
'data-type': viewElement.getAttribute('data-type'),
'loop': viewElement.getAttribute('loop'),
'name': viewElement.getAttribute('name'),
'preload': viewElement.getAttribute('preload'),
'src': viewElement.getAttribute('src'),
};
return writer.createElement( 'cke5MediaAudio', entityAttributes);
}
});

@Witoso : any idea how to avoid adding "p" tags into "non wrapping" elements like "audio/video" or generally how to avoid such behaviour?
As far I understand, there is no preprocess function/hook to change this. Also the "autoParagraph" setting is not available (see: #762).