"View Source" functionality / plugin

[mborejdo]

Edit (by @Reinmar on 19 July 2021)

We've just released General HTML Support that resolves most of the issues mentioned in this thread.

Read more:

• https://github.com/ckeditor/ckeditor5/issues/592#issuecomment-882328198
• https://ckeditor.com/blog/CKEditor-5-v29.0.0-with-boosted-images-find-and-replace-and-the-source-editing-feature/

Edit (by @Reinmar on 7 March 2019)

This ticket covers the following three aspects:

• The "edit source" mode known from CKEditor 4 (which is actually the trivial part).
• Support for "free HTML" editing.
• Ability to migrate content from CKEditor 4 to CKEditor 5.

This discussion is very long and will be confusing if you choose to read just a few random comments. However, you can jump directly to this comment to read about the current plans.

We want to keep this discussion clean, therefore we will be moderating and deleting low-quality comments. Please avoid "me too", "CKE5 is useless without it", etc. comments.

Type of comments that will be welcome:

• Which HTML features are important for you. Snippets of HTML that you want CKE5 to support will tell us the most. Please be precise.
• What's blocking you (precisely) to migrate from CKEditor 4 to CKEditor 5.
• What could you sacrifice when migrating from CKEditor 4 to CKEditor 5. For instance, CKEditor 4 stores some information using inline styles (e.g. the alignment of an image). Would it be ok if those were automatically converted to classes (because CKEditor 5 strongly prefers classes)?

Thank you!

---

Original ticket

Hey there!

we are evaluating an ckeditor4 -> 5 upgrade. Unfortunately I cannot find anything related to the "view source" button/functionality. Is this a feature which will be implemented as a plugin? Or is this something the new dataprocessing/view engine is handling? Is there an ETA? (I cannot seem to find it on the roadmap docs and searching for "source" and/or "view" across the repos leads to many unrelated issues.

Thanks

[fredck]

Hey Michael! Thanks for the suggestion. It, in fact, bring us to a topic where a lot of feedback is needed.

First of all, thinking about end users, the "View Source" feature is something to avoid. It is a mistake to have it, especially in the light of CKEditor 5, where we want to bring the editor out of the "HTML Editor" thing, making it the perfect soluting for "quality content writing".

So, the more input we have, the better. You may tell us about your use case. Some things you could let us know:

• Why do you think "View Source" is important?
• What are the use cases for such feature? Can you list the top user actions within it?
• What's your feeling about me saying that this feature is "dangerous" and should not exist?

Note that I'm not asking this with the intent of saying that we're not willing to do it. It's a sincere talk, eager for feedback. In fact, we're most likely not making a move towards the development of any feature, if there is not enough talk and data to help us understand them and their benefit.

In any case, for now, I believe this would be a community contributed plugin.

Thanks!

[mborejdo]

Hey fredck. Thanks for your feedback. I understand your points and also see only limited usage for a "view source" plugin for the average user (Editor). (we disable it for the average user, but allow "admin" usage)

I do see the need for "advanced" users (eg. CMS Admins) where "pixelperfectness" is needed. Eg. The "Editor"/User/Customer created a document, but messed up styling, spacing, DOM-nesting or the like.

Responding directly to your questions:

• Its important do see the internal document structure and be able to edit more than "wysywig" (empty elements, unneeded breaks, etc)
• "Fixing" Editor/User generated content on a "lower level" (within ckeditor views)
• I completely understand that this feature is not needed for the average user and in constrained cms environments

i will ask my colleagues some more usecases, where we use this CK4 feature

[mborejdo]

Some more "usacases" from my colleagues:

• Adding "third party markup" (tracking etc) within content (without specific plugins)
• fast content duplicating/editing (copy/pasting in src-view mode)

[cavac]

Another usecase:

I'm using CKEditor 4 to edit my blog and software documentation (but display the public pages WITHOUT editor, just the HTML). When developing plugins or writing posts, i regularly use the "View Source" feature.

Without a "View Source" option, CKEditor 5 is a no-go for me.

As for the 'where we want to bring the editor out of the "HTML Editor" thing' comment: Why? CKEditor is a WYSIWYG HTML editor. Nothing more, nothing less.

[Reinmar]

As for the 'where we want to bring the editor out of the "HTML Editor" thing' comment: Why? CKEditor is a WYSIWYG HTML editor. Nothing more, nothing less.

This is how many developers perceive it and we are aware of that. But that's not true.

Let's state this clearly – CKEditor is not an HTML editor. It is a content editor and HTML is just one of the possible outputs.

Most of the use cases that you mentioned were related to manually adjusting the output and adding custom markup. Yes, this is possible in CKEditor 4. But CKEditor 4 is not meant to be used this way. When hacking the output you risk that the next time this content will be loaded into CKEditor 4 something will break.

Why? One of the reasons is that CKEditor 4 needs to understand the content. When content is being edited in the WYSIWY* mode the editor needs to apply many complex transformations to it. Those algorithm needs to make decisions based on the content that you're editing. So if you put into the editor content which it wouldn't generate itself, you risk that this content will not be understood and will be somehow broken.

This is, IMO, one of the most frequent reasons why developers dislike WYSIWY* editors – it's because they are abusing them.

CKEditor 5

So far I've been talking about CKEditor 4. How's CKEditor 5 different?

CKEditor 4 uses the DOM as a model. When loading data, the HTML is processed (read – filtered, normalized and escaped) but it ends up in the DOM anyway.

CKEditor 5 has a custom data model. When you load HTML into the editor, it's parsed and then features (initialized previously in the editor) try to pick up from this HTML the pieces they understand. This is called "conversion". As a result of a conversion, the content is being loaded into the custom data structure. The reverse process is executed when content needs to be rendered back to the DOM (either for editing or for data retrieval).

This means that if you don't have a feature which handles a certain HTML tag/attribute/style/whatever then the editor will automatically drop it.

This is how all modern rich-text editors work. Nothing special here (well, except the fact that we support OT ;P)

Source mode

So, I think that the discussion above missed the point. Why doesn't source mode make sense for CKEditor 5? It's because you will lose all changes done in the source mode unless they are compatible with what the initialized features understand. But in this case, you'd be able to just apply these changes in the WYSIWYM mode.

Solutions?

Don't use CKEditor as a page builder (aka HTML editor). Use it exclusively for content editing. Write features for custom stuff that you want it to handle. Build a proper app for page building (if you need it) and use CKEditor as a part of it.

That's the direction which we were empowering in CKEditor 4 by the introduction of features such as Allowed Content Filter and widgets. And CKEditor 5 just made a couple of steps further.

PS

It should be possible to implement a "wildcard" feature in CKEditor 5 (I guess we'd call it "AllowedContentTrue" ;P), but just... don't. Don't do it cause loading data is one thing, but then all the features still need to understand that content for editing.

[fredck]

tl;dr on @Reinmar's comment:

If you need the Source features, stay on CKEditor 4. It'll not be feasible to have this feature working in the same way in CKEditor 5 and, even if you'll have it, it'll just allow the user to use markup that the editor understands, which is pointless because it can be achieved in the wysiwyg mode anyway.

The real solution is not calling for to the Source feature but instead develop features into the editor, which will allow end users to make things right.

[cavac]

Ok, understood. CKEditor doesn't seem to be the right choice for my use-cases, i'll find another alternative.

Thanks for the information.

[Reinmar]

Ok, understood. CKEditor doesn't seem to be the right choice for my use-cases, i'll find another alternative.

Just to make it clear – things that we wrote about CKEditor 4 will be true for all rich-text editors that I'm aware of and things that we wrote about CKEditor 5 will be true for all rich-text editors which implement a custom data model. It's simply a limitation of anything which starts with "WYSIWY*" – customize it by implementing missing features or hope it won't break if you push it beyond the limits.

[mborejdo]

thanks for answering the question and giving insight on those design decisions. Makes sense.

One use case we described is "fixing" user-generated content. I see ckeditor5 generating empty elements or unnecessary breaks and nesting during my evaluation (adding images, removing, etc). I see this behavior on many content-editable related editors. What would be the preferred way to "clean up" these problems in ck5, as I will not SEE these problems in the editor? (Sure this is a limitation in the WY-S-IWYG in general)

[Reinmar]

One use case we described is "fixing" user-generated content. I see ckeditor5 generating empty elements or unnecessary breaks and nesting during my evaluation (adding images, removing, etc).

I'd love to hear more about that. Could you report a new ticket with some examples of such content? What you get from users and what how you'd expect the content to look?

[scofalik]

I have a feeling that many users feel the need for the "view source mode" out of fear or uncertainty, with the assumption that the editor will output "wrong" code. We pay a lot of attention to make sure that CKEditor 5 is outputting a least bloated, semantically correct data.

We started the Editor Recommendation project where we discuss what editors (in general - not only CKE5) should output. We also introduced two "processing pipelines" - one of them generates data for the editor (editing mode) and one of them is generating data for output (this is the data you want to save in the database). The editing pipeline contains quirks and additional tags that are necessary for proper editing, but the data pipeline should be as clean as possible. With core features, we strive to create them in a way that no unneeded tags are created by editor.

If you think that you encountered a bug and the data is not generated the way it should be, please report a ticket as @Reinmar suggested.

[ProductiveRage]

I would like to reiterate one of the reasons from @mborejdo -

• "Fixing" Editor/User generated content on a "lower level" (within ckeditor views)

Our Service Desk has to help end users tidy up their content from time to time, most often if they have pasted some formatted content in from other software (eg. Microsoft Word) and it's gone a bit skewiff. It's possible that this will not be necessary if the paste-from-other-software support works better (I'm afraid that I don't have any examples to hand, I've just been thinking about why - in the past - we've use View Source).

I'd also like to repeat this point as well -

• Adding "third party markup" (tracking etc) within content (without specific plugins)

What is the plan for dropping in embed content from other sites using CKEditor 5? YouTube, for example, allow you to right-click on a video and "copy embed code" and other sites and services offer similar embed snippets.

Finally, @fredck said that "If you need the Source features, stay on CKEditor 4" - I presumed that CKEditor 5 would replace CKEditor 4 at some point in the short(ish) term future. Might this not be the case and they both may be maintained for years to come (where CKEditor 4 is more of an "HTML Editor" while CKEditor 5 is the re-imagined "Content Editor") - a bit like .NET Framework and .NET Core (two products with certain commonalities but with different goals)?

[fredck]

The point is that the View Source feature is not the solution anyway.

If you need to fix the formatting for end users, you must be able to do so using the editor features. That's because if you try to "fix" by using HTML not supported by the editor, that fix will be lost anyway. Hopefully, this will become an edge case, with time.

When it comes to embedding, we have plans to bring a solution to do so in the right way. Much probably an oEmbed service that allows people to paste URL or embed code from third-party websites (like YouTube) and the embed is inserted in the contents.

The same kind of approach should be taken if you need to insert arbitrary HTML into the content. The right solution is creating a plugin where you can paste anything you want. This could be shown to the user as a widget and the plugin would output that raw HTML as a result.

[fredck]

And yes, I believe CKEditor 5 will replace CKEditor 4 in the future. For that, there are still features to be developed. But we also expect developers to make better decisions when it comes to their expectations and to spend more time on designing an RTE for their applications. (not pointing fingers to anyone here... just generalizing)

[ProductiveRage]

Understood, thanks for the quick response!

It may make it awkward for software that has used CKEditor 4 and relied (whether intentionally or inadvertently) upon Users being able to tweak the html from time to time to perform particular tasks.. however, I can see that it will offer a much cleaner and more reliable approach for any system that doesn't have such strange legacy requirements and where the User can be guided through particular tasks with appropriate plugins.

[pjasiun]

To make it clear, this topic is about 2 separate plugins.

First is "Source" plugins, which replace the visual editor content with the data (HTML by default, but it might be any format, for instance, markdown) and let you edit the content as data. There are couple problems with such plugin, for instance, it will not work well with the collaboration.

The second plugin is mentioned "AllowedContentTrue". Plugin which lets you set any content (any HTML tag). For sure CKEditor 5 would not understand such content, and could only handle it in the dummy way, with all problems mentioned about.

However, note, that these plugins are independent. For instance for "fast content duplicating/editing (copy/pasting in src-view mode)" you need only the first plugin. It would allow you to edit content as HTML but would not allow any tags which edit does not understand. Or you may want to be able to put any HTML in the setData and get it back when you are using getData. Then you need the second plugin, which has nothing to do with the source mode.

If you want to have an HTML editor, you need both plugins, but I agree that this is not what CKEditor 5 suppose to be.

[harmenbos]

As a software developer i like to migrate my solution platform to Ckeditor5 because of the innnovations which are there. But sourceview is needed for that. My developers wants to be in control als also want to test the output of new feature we gonna make. And because the generated output is created anyway wit a getData call, it should't be a big effort to add this feature. So let the users decide about implementing it or not. Makes this sense?

[Reinmar]

But sourceview is needed for that. My developers wants to be in control als also want to test the output of new feature we gonna make.

Do you mean testing what a CKEditor 5 plugin which you've just written produces? But that's a developer's tool you need, not an end-user "source view" feature. And since CKEditor exposes editor.getData() your developers can open the console and type it there or you can, in a development mode, have a textarea or something next to the editor automatically updated with a content of the editor. But again – that's for developers, not end-users. And it doesn't require us to write a feature for it.

[Reinmar]

I also thought about one more thing – viewing the model and the virtual DOM (the view). This is something that developers need to do when developing CKEditor 5 plugins. We actually have utils for that already (see https://github.com/ckeditor/ckeditor5-engine/tree/master/src/dev-utils). We use them extensively in tests.

We may also develop a live viewer of the CKEditor state. Something like the DOM viewer in Chrome's dev tools. Would those help?

[harmenbos]

Yes, that would be great!

I use the editor also for developing templates and dynamic documents for my own solution framework.

See http://webos.nl/en/watisen for info.

Harmen

Op 19-11-17 om 14:44 schreef Piotrek Koszuliński:

I also thought about one more thing – viewing the model and the virtual DOM (the view). This is something that developers need to do when developing CKEditor 5 plugins. We actually have utils for that already (see https://github.com/ckeditor/ckeditor5-engine/tree/master/src/dev-utils). We use them extensively in tests.

We may also develop a live viewer of the CKEditor state. Something like the DOM viewer in Chrome's dev tools. Would those help?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ckeditor/ckeditor5/issues/592#issuecomment-345517957, or mute the thread https://github.com/notifications/unsubscribe-auth/AgPAIf6nvGzOWtM0Iu7MUjdw6yd0DEOpks5s4DC4gaJpZM4PwSwQ.

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient Virusvrij. www.avg.com http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

-- Dutchbrite B.V. Rijtuigenhof 105 1054 NC Amsterdam tel. 020-4892363 www.dutchbrite.nl

[pferreir]

I understand you guys want to keep the data model and the serialization format separate, but then you have to be sure that users don't get stuck very often. My experience as a CKEditor4 user is that that editing certain kinds of content (e.g. bullet lists) can be tricky. I will sometimes switch to source view as non-destructive way of solving problems.

(BTW, the new CKEditor 5 looks really cool, keep up the good work! 👍 )

[scofalik]

If a user experiences a bug in given feature, they should report what happens and we will do our best to quickly solve the issue. I am realist and I know that there will be bugs, especially connected with more complicated features, like lists, widgets or table, but we are trying our best to cover all the cases. The hope is that we will be able to deliver quality features so that there will be no need to look at source.

As far as "simple changes in source" go, view-source plugin would not be that difficult to create and we expect that sooner or later community will create it :). As long as you are changing/providing HTML that is understandable to the editor it should be fine. Just keep in mind that "submitting" the changed HTML will have to use editor.setData() (unless you come up with some smart diffing, etc. but this is much more complicated). That means that it will reload the whole data. It might mess with undo steps and for sure would have a negative impact during collaborative editing.

[Reinmar]

I understand you guys want to keep the data model and the serialization format separate, but then you have to be sure that users don't get stuck very often. My experience as a CKEditor4 user is that that editing certain kinds of content (e.g. bullet lists) can be tricky. I will sometimes switch to source view as non-destructive way of solving problems.

A very good point. This is, I think, the only reason why I used source mode in CKEditor 4 myself.

A typical use case may look like this:

1. You paste some content with lists to the editor.
2. It turns out that there are multiple paragraphs and headings in some list items intermixed with some more lists, etc. Basically, a mess for the editor to control.
3. CKEditor 4 has no mechanisms to clean that up. Neither does ACF help, nor you can edit that in the visual mode later on.
4. So you switch to the source mode and figure out how to convert that to a proper, editable HTML.

Another scenario is applying a format (e.g. a heading) to a list item. It converts <li>foo</li> to <li><h1>foo</h1></li> and you can't go back to <li>foo</li>... ;/ You can only get <li><p>foo</p></li> now.

This is bad. And CKEditor 5 fixes all these issues :) How? With the new data model and redesigned features.

Of course, a big part of the "fix" comes from the fact that CKEditor 5's features allow far less than CKEditor 4. E.g. you can't have any blocks in list items. But that's exactly the point. Features need to be defined more precisely and target well-defined use cases. The current lists are supposed to support simple article use cases and we expect to have, as we call them, "document lists" in the future as a separate feature. It will handle only these more complicated lists and will need to figure out ways to edit them. It will do one thing, but it will do it well.

So, as @scofalik wrote – if such situations occur that you can't achieve some result in CKEditor 5, then they are bugs and we'll be grateful for reporting them to us.

[harmenbos]

Hello Developers,

here is by usecase: i use templates with special tags in my solution framework. So templates are used with a type of low level coding.

As developer i always have to be able to debug these templates. Below a example of markup mixed in the tags. using the sourcedialog plugin (which works with inline CKEditor).

Harmen

[Reinmar]

As developer i always have to be able to debug these templates.

Templates are a special use case and require implementing an editor feature for it. Using the source mode to manually fix issues which arose from a poor integration is not the way to go. You shouldn't need to be able to debug the templates in the first place because bugs in templates or their usage in the content are evidence of a deeper issue.

Analogy – if your CMS allows entering some products into the database in a way that they are incorrectly saved there (data is corrupted in some way) what do you do? I bet you don't open mysqladmin and try to fix the records manually. Instead, you need to fix your CMS so it saves the products correctly.

The same should be true for the editor integration. It should be done in a way that users can't create incorrect content or that the content can be fixed in the visual mode.

Below a example of markup mixed in the tags.

I think you forgot to paste the markup.

[stonyau]

Please allow me to join this conversion.

I have to insist that "View Source" function is essentially important. The fact is that there are some programmatic functionalities which cannot be provided by CKEDITOR, such as adding a "itemprop" attribute to a particular section of the paragraph for SEO purpose.

eg. https://moz.com/learn/seo/schema-structured-data

All in all, adding a "View Source" function can provide the largest flexibility to programmers. Thus CKEDITOR 5 could be the perfect tool to everybody.

[Reinmar]

Please allow me to join this conversion.

You are more than welcome :). This is one of the most important topics about rich-text editing one can imagine. There's been a lot of confusion about how a rich-text editor can be integrated into applications. A concept of source mode and users manually tweaking the content should've never existed and, since the source mode can't coexist with a custom data model, it's a high time we straight this up (actually, we started in the past, but it's a long process :)).

---

The fact is that there are some programmatic functionalities which cannot be provided by CKEDITOR, such as adding a "itemprop" attribute to a particular section of the paragraph for SEO purpose.

I hoped to show you that such a plugin exists for CKEditor 4, but unfortunately no one implemented it yet :D Bad luck. But I don't see any technical problem to implement it. You just need to allow the user to set SEO-related attributes for pieces of the content. UI may be tricky, but it's doable. And once it's implemented as a plugin it may introduce additional helpers which you wouldn't normally get in the source mode – some autocompletion for instance. Not to mention the fact that you may do typos when editing HTML manually and the editor won't do that.

It's a bit different story, but the Accessibility checker proves how amazing UX you can get if you do stuff in the visual mode.

BTW, I don't know much about Schema.org structured data, but looking at the example on MDN it seems that this isn't really a use case for a single editor instance. Of course, it will depend on a particular scenario, but very often people try to create in the editor content which should be created using a dedicated UI. E.g. I saw people trying to maintain lists of products inside a single editor instance. This is crazy. Adding and removing, sorting and editing products should be a feature of a CMS, while the editor should be used only for rich-text editing (e.g. writing a product description). That's what structured content is.

Actually, the first quote I got for "structured content":

Structured content means content is separated into independent parts, making its behavior more predictable.

Source: https://ez.no/Blog/5-Benefits-of-Structured-Content

---

"View Source" function can provide the largest flexibility to programmers.

It can't itself solve 90% of problems that were mentioned in this thread. I'm sorry. But in CKEditor 5, because of the custom data model, there will always need to be a plugin which will handle the manually created content, otherwise, the content will be filtered out.

[Reinmar]

Once again, I really enjoy this thread. This will sound a bit awkward, I know, but this is the kind of discussion which we should've had for a long time :D

And don't get me wrong – I know that we won't convince everyone and that this approach means more work to be done on initial integration. After all, pretty much every requirement like those you mentioned, need to be turned into an editor feature. But it's a cost that can't be avoided now. And the advantages of a custom data model not only mean that now we can implement features which weren't possible in the past (e.g. real-time collaborative editing, stable change tracking, selective undo, etc.) but also that implementing features is now much easier. We see that many developers start using CKEditor 5 and implement first features despite the fact that we haven't managed to document the framework properly yet. Some of these features (like e.g. soft linebreak) would be a nightmare to code in the past and now they are just simple features.

[mwadams]

Initially I was wondering how the kind of thing that people commonly add in code would be done.

The two cases I can think of that we see most often are

1. Adding an anchor or class to an element
2. Adding a common (templatized) snippet of HTML - e.g. YouTube, Gist, etc.

The first case should be (comparatively) easy to implement.

Looking at the current plugin architecture, the complexity of implementing 2 is quite high. However, it could easily be templatized if there was an abstraction of the "where is this allowed to be inserted" mechanism. The basic mapping to/from model/view could be automated and a lot of boilerplate code removed if that abstraction was in place.

Making this simple could persuade a lot of developers that a custom editor isn't really needed.

And if you need HTML editing, then there are already solutions for that, of course!

As soon as I can get the build working again I'm going to have a look at a POC for 2 for my own purposes. I'll share my pain with the group.

[scofalik]

I think that 2. would be easier than you might think. Converters for such "closed" widgets are pretty easy. For Schema, those would be $block type elements (mind you, Schema will go through major refactoring pretty soon). The rest of work is to just break all the $block elements in which insertion-position is so that the snippet is placed in $root (or in a place where $block is allowed). We do this for sure on pasting and maybe somewhere else too but I don't remember.

Adding custom properties for parts of a text is like Link feature. (It's not like a bold because there may be different values available). UI for this could be just some kind of highlighting/underscoring, etc. This is also pretty easy to imagine.

[jsfgreen]

Sounds like here that no matter what explanation fredck or whoever gives, most people will never be happy about losing the Source view. I think everyone gets why you excluded it, but so many people have provided way too many use cases where it is indeed needed. I just think that "use our old version" is not the best answer. And "our editors can't handle the conversion" isn't great either. (paraphrased)

In my opinion, it seems ludicrous to exclude the one feature that every developer wants...

[Reinmar]

I think everyone gets why you excluded it, but so many people have provided way too many use cases where it is indeed needed.

I've seen many cases mentioned in this discussion and all of them do not require the source mode. They all require a proper UX and features able to handle them.

What's more – it's not that we don't want this feature that much. We don't like it. But it's not the point. The point is – you can't have free-HTML support in CKEditor 5. The custom data model doesn't allow that (in a reliable and reasonable way). That's because you don't edit HTML in the editor – you edit rich-text. HTML is just one of the possible output formats.

In my opinion, it seems ludicrous to exclude the one feature that every developer wants...

Do they? What about Medium, Google Docs, Gmail, Twitter, Facebook? How many users of these tools thought about the source mode?

[cavac]

Do they? What about Medium, Google Docs, Gmail, Twitter, Facebook? How many users of these tools thought about the source mode?

Not to be rude or anything, but that is a stupid question. Many people choose to use Open Source rather than Google Docs because they want to have access to all the moving parts.

As for my part, i use CKEditor (4) to generate HTML documents that are then displayed without the Editor component in a separate view.

I also would never, in this day and age, choose to use a web based editor that does NOT use HTML as it's file format for saving and loading. Simply because i would then suffer a terrible vendor lock in where i can't even display the documents without that tool.

[zoechi]

I think source view is important

• because the editor is often way too limited and it needs manual tweaking in the source to get the proper result.
• we want to be able to copy paste from other editors or other HTML sources

Without that the editor would be entirely useless to us.

[mwadams]

I think it is important to remember that "some/lots/a few developers" want this feature, not "every developer".

It is far more important to my use cases, for example, that the editor is unsurprising to the user, than it is to be able to tweak the HTML. As I mentioned in an earlier comment, almost all "tweaking" needs are catered for by adding features to the editor; but this is still relatively early days and features are being added steadily in line with the work being done to refactor the API and make it simpler (as far as I can tell - I am an engaged observer, not part of the team).

I think the "vendor lock-in" is a red herring. You generate plain-old HTML, which you are free to import into whatever editor you want to use in future!

I respect that HTML tweaking is important to your use case, but it doesn't reflect everyone's and I would be as disappointed as you are now if the project sacrificed editing stability to support an "arbitrary HTML" model.

And at some time in the future, when there are enough features for your particular use-cases to be catered for, you will also be happy :)

[Reinmar]

I also would never, in this day and age, choose to use a web based editor that does NOT use HTML as it's file format for saving and loading. Simply because i would then suffer a terrible vendor lock in where i can't even display the documents without that tool.

And we completely agree with you. HTML is a very good data format for the rich-text. But, as @fredck wrote in https://medium.com/content-uneditable/a-standard-for-rich-text-data-4b3a507af552, it must be a structured HTML. Not any random HTML.

Therefore, CKEditor 5 produces HTML by default. You can force it to produce a different data format, but we don't recommend that.

However, the data format is one thing. The second is being able to edit it. While manually you can do whatever you want, the editor is not able to do that. Pieces of HTML that you want to pass through it must be handled by specific editor features implemented to handle these HTML fragments.

And don't get me wrong – I understand that you want to be able to paste any HTML into the editor and manually tweak the output. That's the easy way for you – developers. The reality is that neither CKEditor 5's (or any other modern editor's) architecture support that, nor is that good for end users.

because the editor is often way too limited and it needs manual tweaking in the source to get the proper result.

we want to be able to copy paste from other editors or other HTML sources

All these things were discussed here already. If the editor is too limited, then it means that it misses features – the solution: implement them. If you want to embed HTML think what HTML are you embedding. If that's about YT/Vimeo/etc videos – implement a feature to embed them (we'll certainly work on one too). If you want to embed some weird widget, create a feature which will allow you to embed free-HTML snippets. It's all possible – it just requires a proper mindset.

[hparadiz]

I'm currently building a blog for myself and I decided to try to use CKEditor 5. It's really really nice for displaying the content using the native CSS already loaded in the page. The look and feel of the editor is very ideal.

The content of my blog is very technical in nature. From copy/pastes of terminal output to code snippets from various languages.

My problem from the get go is that code preview is not even part of your default class editor build. I'm still trying to figure out if I can even dynamically load it in without setting up a build environment. I'm not going to make a build environment to build ckeditor. That's way too much work. I should be able to load a build of your editor with all the plugins in there from the get go so I can embed it on my website without a hassle.

Which leads me to my next problem. Code embeds in raw HTML generally use the <pre> tag however modern code syntax highlighters use all sorts of different methods of honing in on what is "code" and moving on from there.

For example PrismJS uses CSS classes like so: <pre><code class="language-css">p { color: red }</code></pre>

The JavaScript like most libraries simply scans the DOM with CSS selectors and converts each of the code snippets it finds to the HTML elements it needs to display the code with some pretty syntax colors.

CKEditor 5 gets in my way. Without the ability to edit the HTML I am left puzzled as to the point of the editor at all. You guys did all this work but the most basic features are locked away behind a whole tech stack of build tools. On top of this problem let's say I made some custom header that used my classes for defining the code snippet..... well inside CKEditor none of that code would display how it would on the actually website when viewing the post. And since it's a custom header and not the official "Code" plugin the code wouldn't even be displayed correctly and be super annoying to edit in CKEditor.

I think you'd all agree that in our business it is very important to be able to show your code.

So that's my experience from just a moment ago.

The other experience I will share with you is from a couple years ago when I was working for a company that did print publishing of medical texts and subsequently on the website.

While 95% of what our editors needed to do was a simply/copy paste with fixes of the text we would occasionally need to add some miscellaneous HTML to an "article" because it was sponsored or something and the third party had their own tracker for it. This tracker is one off. In no world would I actually sit down and write a plugin for it. So.... this scenario leaves me with a situation in which your architecture choices would be an immediate upgrade deal killer..... because to do otherwise would force me to make those HTML edits in SQL directly.... at which point.... what's the point?

Finally to the point others are making about how the editor is supposed to be intuitive for those that don't know HTML. This is grasping for straws. No one is suggesting that the "Edit Source" button be prominent with the default editor. It must simply be an option.

CKEditor 5 looks nice but without this vital feature I won't be using it.

Edit On second thought after setting up CKEditor 4 and looking at the View Source panel I feel like I'd rather create a toggle that hides CKEditor 5 and shows Ace Editor or similar in the spot. Just need to figure out how I'm going to embed code snippets while in CKEditor 5. I'd really like a popup with a proper code editor but I bet I'd have to write it myself. 😭

Edit #2 Welp... so much for that. CKEditor 5 is editing my HTML waaaay too much. Existing <pre> tags are being converted to <p>. No. Just no.

[Reinmar]

Welp... so much for that. CKEditor 5 is editing my HTML waaaay too much. Existing <pre> tags are being converted to <p>. No. Just no.

The reason for that is what you noticed yourself:

My problem from the get go is that code preview is not even part of your default class editor build.

The lack of certain features at this stage is painful. We know that. That's why we work on bringing as many features as possible as soon as possible. Also, we work on enabling you guys to work on your plugins, so you can implement your specific custom features too.

This tracker is one off. In no world would I actually sit down and write a plugin for it.

I completely agree. And there are at least two solutions:

• Don't keep these trackers in the same field as the HTML post. Create another field in your form where content authors will be able to paste whatever they need.
• Implement (you/us/community) a CKEditor 5 plugin which will allow embedding any free HTML into the content in a structured and controlled way. Yep, that's possible. You can write a feature which will tell the editor that "this <div class=mess> should be kept as it is".

BTW, this is a very good post treating about HTML blobs: https://alistapart.com/article/battle-for-the-body-field

[Reinmar]

Also worth checking:

• Jeff Eaton's slides: https://www.slideshare.net/eaton/the-battle-for-the-body-field
• and his another blog post: https://www.lullabot.com/articles/deblobbing-your-chunks-building-a-flexible-content-model

[diplopito]

I use the "view source" option to clean and format HTML: open source, paste any html and view it in a clean manner. No need to use any extra library, plus the possibility of making extra changes to the remaining source, very handy.

[zoechi]

It wouldn't be possible to display the created content without a library that understands the saved format. To me this discussion appears like an April fool hoax.

[OpenESignForms]

How do I change a link's styling, or add "noindex" or specify that the link opens in a new tab, etc.? I can only see a way to set the URL, but that's insufficient. Sadly, we also use SOURCE mode because users may add their own JavaScript, Styles and even JSP tags in the resulting HTML it produced. Often, content can be quite complex, and doing it with just a few controls in the menu, etc. won't allow for the rich experience SOURCE mode allowed advanced layout specialists. I think the problem for us is we want an HTML builder, but you want a content builder that cares not about advanced content. For example, our documents can be used to generate a list of content stored in a database, so we use iteration and such in the HTML document that's unrelated to HTML "content".

[bythewiseman]

I am actually saddened that view source isn't going to be part of CKEditor5. My use case for needing to see the Html is "what the heck has the user done!". I can read Html faster than I can scroll though content, unformat, reformat, etc. Often there are Html legal span tags dotted around and wrapping elements, but my Css styles then in such a way that breaks the layout of my pages. Tracking span tags down in a small editor window isn't the most fun of jobs at the best of time.

I often use View Source, take the copy out, use Notepad++ to tidy up code with find and replace, heck it wouldn't be rare to use regular expressions to find and replace in Notepad++. And once I am happy I can paste the code back in.

I know the Html will be legal for both CKEditor and for my styled up content...I've been doing this job long enough now.

We are talking edge cases, but edge cases are what it will take for advanced developers like me move to a different WYSIWYG editor. And I have been using you guys for over 10 years now so I am horribly afraid to do so.

And why have you moved to such a convoluted way to get additional plugins into CKEditor5? Have I picked it up wrong but npm, node.js and packages etc etc. Sheesh! What happened to dropping a plugin in a folder and walking away!

[paul-crashley]

This is a massive let down for what is otherwise a great editor.

I'm not so bothered about having a "view source" options, but I'm working on a system that needs to insert custom widgets into the content, not neccessarily via the editor, that can be parsed in to more complex HTML in the front end.

E.g.

<widget id="1" data-src="http://example.com" data-headline="My widget headline" data-img="image.jpg" />

This can then potentially be styled as an icon in the editor so subsequent editors know there is a widget there.

Ckeditor5 however removes this code every time there is a new edit breaking everything.

[Reinmar]

but I'm working on a system that needs to insert custom widgets into the content, not neccessarily via the editor, that can be parsed in to more complex HTML in the front end.

This is completely possible. You can implement features which allow inserting custom widgets and which use custom tags.

CKEditor 5 however removes this code every time there is a new edit breaking everything.

Because you haven't implemented a feature which would handle those tags. And I feel that you inserted these elements straight into the DOM instead inserting them into the model.

What I see many of you guys, who commented in this thread, want to take CKEditor 5 and use it exactly like in the old days. You need to change your old habits and your way of thinking. You need to understand the architecture and basic concepts. Then you'll be able to do magic.

All the use cases mentioned in this thread by all of you guys can be handled in CKEditor 5. But usually differently than you'd do that in CKEditor 4.

[OpenESignForms]

We'll have to see, but we use CKEditor 4 now for generating the base layout for a Java ServePage (JSP). That is, we take the content of the editor (which may have JSP snippets added today via SOURCE mode, with much JSP/java code not a visual element like conditionals and loops) and generate JSP files. We're not just building visual content, but active/conditional forms and processing beyond layout.

[Xoduz]

How do I add rel="noopener" to a link without view source? How do I add a class to a link without view source? How do I specify target of a link without view source? How do I mark multiple lines of code as "Code" without the editor generating one set of pre-tags for each line, without view source?

If the answer to questions like these are "Write a custom plugin for it", then CKEditor 5 is not ready for public consumption. I also don't understand why this editor is presented as a potential upgrade path for CKEditor 4 when they are two completely different beasts. I wanted to upgrade, primarily for issues related to Content-Security-Policy, but with basic functionality missing and the lack of view source to do even the simplest of things, it's not even remotely possible to upgrade to version 5.

[joachimdoerr]

@Xoduz i think cke5 or cke4 are not beasts. But your right the code view and edit functionality is important and basically for productions usage. Any discussion about that is incomprehensible.

[Reinmar]

How do I add rel="noopener" to a link without view source? How do I specify target of a link without view source?

Advanced CMSes do that for you automatically based on a policy which links should be marked with it. In the database they store a clean markup and add those attributes when rendering the content to the users. This way, the behaviour stays configurable for the admin which is important when you want your content to be portable and future-proof.

How do I add a class to a link without view source?

"Adding a class" is a purely developer-oriented feature. It's a job for an HTML editor. I don't see how you could ask a normal user to add a class (a completely virtual thing) to an <a> element (another virtual thing). That would be an awful UX.

Funny thing – perhaps one day someone will write a plugin which lets you add any class to a link. It's doable. Source editing is doable as well. Even the "free HTML editing" is doable – it "only" requires writing plugins for all HTML features. I guess someone will try this one day. But the user experience will be terrible.

How do I mark multiple lines of code as "Code" without the editor generating one set of pre-tags for each line, without view source?

I'm not even sure I understand. But I know that I wouldn't like to create <pre> and <code> elements manually myself. I'd rather click the "insert code snippet" button and choose a language from a select box. That's a missing feature. And yes – it requires writing a plugin.

I also don't understand why this editor is presented as a potential upgrade path for CKEditor 4 when they are two completely different beasts

Because it's a potential upgrade path. There are people who already migrated. And with time, when more plugins will be available, many others will do.

But not everyone will be able to migrate. Certain CKEditor 4 features such as "free HTML editing", "shift enter mode", "allow all content", etc. will never be ported. At least – not in the same way. Those features abused the concept of "rich text editing" to the extent which made further development of CKEditor 4 a nightmare. Each feature like this (and it's even worse when they are combined together) adds tones of essential complexity and, as it normally happens, lots of accidental complexity too. The worst part is that they are viral, every other feature needs to know about them or you need to add tones of architecture to handle them in a "generic" way.

[Reinmar]

<tl;dr>

CKEditor 5 is not a reasonable option for you if all you want is a quick solution to visual free HTML editing and you're fine with a developer-oriented experience.

It's possible to force "free HTML" through CKEditor 5's throat, but the user experience of editing such a content will be poor. And this removes one of the biggest advantages of CKEditor 5 – its UX.

</tl;dr>