Ckeditor5: "View Source" functionality / plugin

[mborejdo]

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. [phone]
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]

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.

[bythewiseman]

"Adding a class" is a purely developer-oriented feature.

• I am a developer, a writer, an editor, a coder, a dishwasher, a tea maker... I am the contractor they call upon when the others can't do it. I use FCKEditor as it allows me to write stuff in the front end of the site, to setup basic styles and features for users, but if something comes along that is needed done quickly then popping into Source View is invaluable. Otherwise I would have to open my code, add configurations, save, commit, set to staging, test, put live... Or I could just hit View Source and be done with it.

So yeah. Until someone writes all the plugins to bring CKEditor 5 back to the modern world where many many people do the jobs of many many people, then it is a no go for me.

[kudeiro]

Without "view source" is useless

[joachimdoerr]

@Reinmar why lose the editor his UX? The code view/edit functionality should be an optional addable feature.

[luzfcb]

I have been following the development of ckeditor 5 in the last 3 years, because I find the proposal interesting, and I intend to use it at some appropriate time in the future. If I get it right, ckeditor5 is not an HTML editor. It is a content editor. unlike ckeditor4, internally, the data is not saved in HTML format. so a view source does not make the slightest sense. HTML is one of the output format types. If someone implements, the output type could be XML, JSON, OpenDocument or anything else.

If I said something wrong, please correct me.

[megacromulent]

Ckeditor5 strips out classes that version 4 left in and this wrecks almost all content formatting. "Upgrading" from 4 to 5 is currently not a valid option, and based on your comments here, it's not intended to _ever_ be.

This feels like a bait-and-switch. You need to clarify this on your site that 4 & 5 are two are completely incompatible editors and that upgrading can and will destroy content (unfortunately by design).

5 should be branded an entirely separate product.

"Adding a class" is a purely developer-oriented feature. It's a job for an HTML editor.... perhaps one day someone will write a plugin which lets you add any class to a link. It's doable.

I am just baffled by this statement. Why wouldn't 5 leave all attributes on elements alone? Why arbitrarily strip them out? With 4, the content was styled appropriately inline, now any content edited with 5 instantly gets converted to non-styled blob of generic html.

The most simplistic editors available online do this, why use Ckeditor anymore if it can't do anything more than a project editor created in college programming class? This limits the use of Ckeditor to the most generic possible uses, and makes it unusable for professional website content.

Even the "free HTML editing" is doable – it "only" requires writing plugins for all HTML features.

"Only"? It feels like you are trolling us. Why isn't this a core feature or plugin? It has been for all the WYSIWYG editors in existence, and all versions of CKeditor until now. I get it, this is a free tool, it's yours, do with it as you please.

But too many of us need a real HTML editor with our WYSIWYG editor. The way 5 seems to work is a "just trust us" mentality, which is not possible. Me and all my clients need to be able to trust that if we make the html a certain way that the editor won't make it's own "guesses" as far as how the content is to be edited.

I think the solution to this problem is for you to make a default plugin called "insert html blob" and end all the arguments, instead of making all of us feel stupid for not getting your ideology.

Edit: I know this is a free editor, and I am not "demanding" any changes, just adding to the discussion that v5 is _not_ an upgrade to v4, it's a different editor. And many people will be wasting time trying it out, testing and pulling their hair out thinking they did something wrong, only to find out the errors and corrupted data are a "feature" to make a better UX.

[baoanhng]

Glad that I've come to this through search so that I will not take my time to test.

HTML sources are needed for many purposes, you are making it harder for a lot of developers, but they are the ones who install this editor into their application, not ordinary users. You are forcing developer to the nonsense UX excuses of yours but why is it your concern? This is just an editor after all, UX related choice should be optional.

If this request ever get considered, I will come back.

[OpenESignForms]

Let's presume that CKEditor 4 will stay alive or be forked, with CK5 for a given group. It's unclear how many people wanted CKEditor for "content creation" only versus those who wanted HTML, that being the highly portable and long-lasting, readable, code that created the entire WWW.

[ThiefMaster]

that being the highly portable and long-lasting, readable, code that created the entire WWW

HTML is great when written by developers/designers. It's awful when written by end-users. Did you ever see the abominations people create? Especially when being able to paste e.g. HTML from MS Word and similar tools. Or when they find ancient resources and poop <font> tags all over their code? Trust me, that's not fun if you ever want to convert such user-provided content to something else - be it valid HTML5 or something more restricted like markdown.

[clarumedia]

Hello,

First to acknowledge the fabulous piece of work that is CKEDITOR4.
I am looking with great interest to migrate to CKEDITOR5 but I cannot do so at this time.

Please show me how to do the following in CKEDITOR5 without a "view source" button:

1) Custom HTML tags
2) Template tags like square brackets
3) Inline CGI scripting tags.
4) Fixing non visible messed up markup. (eg GUI was used to create a div inside a bullet list and it's impossible to get rid of it without deleting the whole bullet list.)
5) Accurately copying and pasting pieces of markup (like copying 5 rows in a table)
6) Paste in raw HTML from external sources.

BTW I tried to paste some of my config file into this editor to find it is then mangled in the rendered output. Also UL and OL only appears to allow 1 entry in the list in this editor. (Firefox 60 on Linux)

//Modified by Chris Barnes 2013 to allow native spell checker
config.disableNativeSpellChecker = false;

//Disabled this for version 4.4.7
//config.extraPlugins = 'colorbutton,stylesheetparser';

//Modified by Chris Barnes 2013 to use BR instead of div tags for new lines. WTF.
config.enterMode = CKEDITOR.ENTER_BR;

//Modified by Chris Barnes 2013 to allow PHP source code (Code security handled elsewhere)
config.protectedSource.push(/<\?[\s\S]*?\?>/g); // PHP Code
config.protectedSource.push(/<code>[\s\S]*?<\/code>/gi); // Code tags   

//This will hide merge tags in the editor, but has the advantage of allowing you to put them ANYWHERE in the content.
config.protectedSource.push(/\[\[[\s\S]*?\]\]/gi); // [[MERGE_TAGS]]

//Allows protected source tags to be visible and editable
config.extraPlugins = 'showprotected';

//Modified by Chris Barnes 2014 to prevent ckeditor being a busy body and stripping HTML and inline styles :-(
config.allowedContent = true;   

//Modified by Chris Barnes 2016 to ensure the editor is working properly in UTF mode
config.entities_latin = false;
config.entities = false;
config.basicEntities = false;

Those are just the items I use every day.
I'm sure you could give me wonderful reasons why I shouldn't be doing all of those things but the fact is, I do them.....

For the moment I will have to stick with CKEDITOR4

Many thanks for all your excellent hard work

Chris

[baoanhng]

@ThiefMaster Content writers and blog writers nowaday know a lot about HTML, don't underestimate them because they may know it better than you.

The web works with HTML and you cannot change that behavior with an editor alone, I find it really amusing. Allowing edit HTML source should be webmasters' concern to suitable their sites.

What happens if the editor generates wrong HTML. Should I submit a bug and wait for about a month or longer for it getting fixed? If you try to say "our editor is perfect", I would doubt it.

[scofalik]

Hi @clarumedia,

1. Create a plugin that supports them, with UI to insert them. The easiest features should take like 30 lines of code.

2. This looks like good old placeholder feature. It is not ready for CKE5 yet, though. But it is not something that cannot be done.

3. Introduce "script feature" that could handle it. It is possible to define a feature that introduces <script> tag. The UI could be some kind of popup or toolbar with textarea field which could take the script code. On plus side, with proper model->editing view conversion such element could be represented in the editor as some kind of icon or placeholder (in contrary to being invisible if it was just <script> inserted into editor content). BTW. Is this really a part of content that you want to put it in the editor? Why not add a field in your form where you would be able to put such scripts?

4. To fix messed up markdown, first, you need a messed up markdown. If you will find that CKE5 produces messed up markdown, please report an issue and we will fix it. @baona95 I understand that you might doubt that an editor will produce a correct markup given the experience you might have with other editors or even CKE4. Please understand though, that editors like CKE4 or TinyMCE base on DOM as their source of data which is the reason why the markup becomes ugly. In CKE5 we have an abstract data model which is very tidy and that data model is converted to a tidy HTML when the change in an editor occurs. This guarantees quite a big safety when it comes to HTML code quality. Still, as you said, if you are not happy with the produced HTML, fill in a bug report.

5. This indeed might be difficult if you copy from a table of a different size than target table. Still, we will do our best to properly recognize, interpret and paste table contents. OTOH, trying to fit the HTML might be even more time consuming than copying cell by cell. And if the tables have same amount of columns, I wouldn't worry cause we will figure out those simple cases :).

6. If you want to paste arbitrary HTML content from one site to other you probably want HTML editor, not a content editor. Why would you really want to do that?

Please, once again, understand that not having "HTML source editing" feature is not just our whim. This is a result of a decision we made when it comes to CKE5 architecture. To provide stable (in a long run) product that is easily maintainable and extendable, with a reliable and powerful framework, we needed a solid and defined architecture with a custom data model. And this does not work with supporting arbitrary HTML cause you end up with hard to maintain code like in CKE4. Providing features for CKE4 is more difficult than it will be for CKE5 cause there are much more things (edge cases, DOM behaviors, other features changing DOM etc.) you have to think about.

Believe us that this is the matter of changing the way of thinking. We deeply understand that people get used to some features and are comfortable with "source view mode". We understand that developers will not want to spend several days to create a plugin when, before, they could just paste some HTML and be done with it. But still, without a change there is no progress. And we want to make a progress with CKE5 enabling you with a powerful framework and cool features like collaborative editing.

If you don't believe us, look around and compare to other modern editors. Successful projects use custom data model and don't let for arbitrary HTML changes. It is like that because it is too difficult to tame the spaghetti that ends up in DOM after a while of editing.

[bythewiseman]

We deeply understand that people get used to some feature

It's not just a "feature", it's actually part of why we love CKE4.

If you don't believe us, look around and compare to other modern editors.

I look squarely at the likes of WordPress and CodeMirror. They have editor mode and text mode that allows you to add whatever Html you want. You edit your css directly in CodeMirror too!

I look directly at Umbraco and TinyMCE with it's ViewSource button. (And TinyMCE tout it's View Source button on the features page https://www.tinymce.com/features/)

So I looked around and find it maybe time to move on if you have (and yes it is on a whim) moved away from ViewSource because you personally feel dealing with broken/incorrect Html is not worth the hassle.

[clarumedia]

Hi @scofalik

Thank you for your response. As a developer, I completely understand your way of thinking.
Your thought process is completely well intended.

Then the users appear and use your lovely GUI to break things in horrible ways we haven't even begun to imagine. They don't take the "happy path" which they so obviously should but do horrible stupid things which lead to the question "How did you EVER manage to do that ?"
Currently, I come along, flip on "View Source", whip out the offending mess and off we go again.

Whenever you answer a query with "Why would you want to do that ?" surely you are assuming that you know the FULL background to my situation ?

We recently used an HTML purifier to bring some legacy word documents into HTML. I strung together an HTML purifier for the purpose and then we cut and pasted the resultant HTML into the editor so that it could "correct" it again and bam ! Great stuff.
You wouldn't believe how useful it is for me to be able to paste selected table rows into the middle of the same or another table.

The script tags are not your HTML script tags, they're nasty, nasty PHP tags and template tags like double square brackets which we need for other nasty, nasty purposes where we handle the security horrors by other means.

How about you give us the "View Source" button as a feature that we can add if we want ? We promise not to blame you if we make a mess of the dom ? Does the architecture not permit a nasty developer back door ?

Thank you so much for all your work !

Chris

[Reinmar]

How about you give us the "View Source" button as a feature that we can add if we want ? We promise not to blame you if we make a mess of the dom ? Does the architecture not permit a nasty developer back door ?

It's not about the "View source button". It's easy to implement. The editor does produce HTML output (editor.getData()) and allows loading HTML back (editor.getData()). So it's just a matter of creating a UI for that – every one of you could do that.

It's a matter of loading arbitrary HTML to CKEditor 5. CKEditor 5, as every modern rich-text editor, is based on a custom data model. This data model does not look like the DOM. It's a structure optimised for rich-text. It allowed implementing real-time collaboration and allows implementing complex editing features like a suggestion mode, selective undo, changes tracking, etc.

However, now, with a custom data model, every single HTML feature must be transformed from HTML to that data model and back. One by one. With a focus on providing the right semantics to what gets loaded into the model.

It is, theoretically, possible to write such converters which will load all known HTML features. However, it's a completely different story to then allow editing them. My expectation is – it's going to blow up. The visual mode will be useless with all that loaded into the custom data model. Hence, IMO there's no point in all this.

OTOH, with time, people will implement features for things like embedding <script> tags, videos, custom PHP/ASP/whatever markup, handling <div>s, etc. Every crazy piece of content can be edited in CKEditor 5. So, with time, it may turn out that you will be able to load all the things you need. It's just not for free and we won't be able to do that for you. If you want to give that a try, though, we always do our best to help.

---

Anyway, you can ask now – why a custom data model if it'll never replace CKEditor 4 completely? It's because it is the only way to implement (in a clean, stable and maintainable way) features which weren't possible to be made in CKEditor 4, TinyMCE, Wordpress (which uses TinyMCE, BTW) and all similar WYSIWYG editors. It's also the only way to significantly improve the code base.

I want to make it clear – there will never be a feature parity between CKEditor 4 and CKEditor 5. It may happen that you may not be able to use CKEditor 5. We were aware of that, but there was no other way around.

Besides, what I see is that some of you don't need a WYSIWYG editor at all. Some of you need a code editor (and someone even mentioned CodeMirror, which is a code editor), perhaps with some preview. These aren't cases for WYSIWYG editors.

[bythewiseman]

Such a shame. :-( this chain plus knowing I have to use webpack/npm and all
the nonsense around that, sadly I won't ever be able to move on to CKEditor

1. I'll stay CKEditor 4 for a while but will be checking other other modern
   editors that match my needs.

Thanks though for the last 10+ years. You're editor has been awesome and
exactly what I've needed.

Colin

[baoanhng]

@Reinmar I understand the model, it is nice to see you guys have seriously pulled it out. But this is the web, where HTML is an essential concept, so there is no point of remove the ability to edit HTML just to make a better rich text, it is just nonsense to me.

You always talk about UX, but ordinary users won't even understand the difference between a normal content editable editor and this. And most of them won't care.

So what is use cases for this editor? It is not prettier than other editors. You wrote all those explainations for us developers to read right? But why you never think of supporting it.

Like I said, rich text is for ordinary user, HTML is for advanced user. But the point is without advanced users who made all the work, there is no room for ordinary users. It is clear.

But it seems too late to turn the road, so I have to leave this editor. Thanks for ckeditor 4 and good luck. Maybe in future it would be better.

[megacromulent]

1. Ckeditor v5 is NOT an upgrade to Ckeditor v4

If you want to paste arbitrary HTML content from one site to other you probably want HTML editor, not a content editor. Why would you really want to do that?

This is why you need to rename CKeditor 5 to Ckeditor Content editor version 1.

Ckeditor 4 was obviously an HTML editor, you _cannot upgrade to v5_. You have to completely rework your entire data and content system to use CKeditor 5. Please respond to this issue.

2. CKeditor v5 is NOT an HTML editor, and needs this label

Providing features for CKE4 is more difficult than it will be for CKE5 cause there are much more things (edge cases, DOM behaviors, other features changing DOM etc.) you have to think about.

And as a developer for the past 20 years I completely and utterly understand and support your decision to move on to building a new editor, but it's not an HTML editor, as you said, it's a "content" editor, and should be named that way.

3. Defining "Arbitrary HTML" and issue of trust

It's a matter of loading arbitrary HTML to CKEditor 5.

Who defines what "arbitrary html" is? How can we trust v5 if you decide what is "arbitrary" and can change this definition at any time? Do you see how by design your undercutting the incredible good will you have built over the years by not _clearly_ labelling v5 as NOT an html editor?

4. Losing backwards compatibility is OK, but that is not what is happening here

there will never be a feature parity between CKEditor 4 and CKEditor 5

That's fine, no one expects perfect paraity between major upgrades, in fact that is part of a commonly understood difference between minor and major upgrades is breaking backwards compatibility on major upgrades.

I support breaking backwards compatibility, as I suspect most devs do, but that is not what you are doing, you are moving from an HTML/browser DOM editor to Word, and automagically and arbitrarily discarding real world data and content without telling the developers. (are you trying to "trick" us into your new system?)

5. Choosing users over developers

Developers are what made CKeditor used all over, not end users. I hope you take this into account, as I have already setup TinyMCE in the places where I needed to create new editor instances and had a previous version of CKeditor 5 that all of a sudden started wrecking the html output.

6. Misleading labeling, marketing and documentation

Why I initially commented here: I setup Ckeditor 5 when in alpha, and it worked great. Then later I upgraded 5, and so many things broke, and no documentation to explain why, hours of testing and hair pulling and I finally (accidentally) found this page, and only because I was curious about the source button.

Your home page ( https://ckeditor.com/ ) says CKeditor 5 is a "rich text editor", but so is Ckeditor 4! You say CKeditor 4 is a "WYSIWYG editor" , but so is CKeditor 5!

Ckeditor 5 is a complete and utter failure and disaster not because of custom data model, but because of deceptive documentation and marketing issues to your dedicated developers.

[Reinmar]

@megacromulent, I understand you may be frustrated by the state of things and I'm sorry to hear that. But I'll not tolerate accusations and this level of discussion in general. I'm hiding your comment and I'll delete new ones unless you'll keep them cool.

And for the record:

• Nothing changed between CKE5 alpha and the current version – in fact, we listened and implemented non-semantic, visual features such as text alignment and font size/family. So, if anything, the current version accepts a wider spectrum of HTML features.
• We're very open about what CKE5 is and what's not. This issue is an example of that.

[bythewiseman]

That's such a shame that you feel that someone's personal opinion that
contains no accusations; no bad language;nothing inflammatory at all; has
to be hidden because you don't like their opinion on the current state of
CKEditor 5 and your move from CKEditor 4. Personally I felt it balanced and
reasonable and agreed with much of it.

Maybe look at this from our perspective. We are your customers, many for
over a decade. We are the ones that promoted your software to everyone
around us and we've only been putting forward our experiences and opinion
about why we need a view source option to manually manipulate html as and
how our requirements demand. Yet we're being cast aside as you've taken a
new direction with the code - which is, as we've all said, you're absolute
right as it is your code. We just feel we've been forgotten about which is
why we're all a bit upset.

But as we've all probably come to the same conclusion, it's time move on.
As someone said, change is needed for progression...

[Reinmar]

I personally really enjoyed this thread so far. And I think it's clear that we're open to a discussion. We may not be able to help you and change our decision, but we can talk about this.

So criticism is not a problem for us. What we don't accept is FUD and other forms of abuse/trolling. The comment I hid didn't get the facts right and accused us of taking deliberate action "to trick us into your new system". This is not constructive and hence I hid that comment.

I'll also hide your comment and mine because we're off topic.

[bythewiseman]

It wasn't abuse or trolling.

But yes we're off topic. I'll also unsubscribe from this thread as it won't
lead to any change.

[baoanhng]

Forgot to unsubscribe the topic.

At least one straight notice should be place at top of homepage to warn developers about this. Because I'm sure many developers think this has the same features as ckeditor 4.
"We don't provide ability to edit HTML source directly, feel free to use other ones"

I was fortunate to find out this issue from Google, otherwise it would take me a lot of time to dig in.

[megacromulent]

1. Addressing the actual problem with Ckeditor v5

I understand you may be frustrated by the state of things and I'm sorry to hear that.

I have one simple "frustration", there is no obvious place on your site that says "Ckeditor v5 is NOT an html editor", and a follow up would have been helpful like "Any content created in Ckeditor v4 will be reformatted and data loss is certain, so don't use v5 as an in place upgrade for v4."

This is an incredibly easy fix that requires no programming at all. And I feel is a very reasonable expectation to have for any software project that they explain plainly and openly, about major changes in backwards compatibility.

The download page is where I recommend a very large alert message for developers to avoid data loss and wasted time debugging.

2. Dismissing valid points

But I'll not tolerate accusations and this level of discussion in general.

Fair enough. Feel free to enlighten me on what I said that was an "accusation", as I feel I stated a number of things that are worthy of discussion, and to have all of it dismissed because of one statement seems counter productive.

3. Real world data loss

Nothing changed between CKE5 alpha and the current version – in fact, we listened and implemented non-semantic, visual features such as text alignment and font size/family. So, if anything, the current version accepts a wider spectrum of HTML features.

This is the crux of the problem. I had used the Alpha v5 for _months_ before noticing it was causing data loss because it wasn't an actual upgrade from v4, but instead an entirely different editor. Going back, I didn't even _know_ about the changes that had been made until the data loss was found.

4. Documentation on the issues of data loss between v4 and v5

We're very open about what CKE5 is and what's not. This issue is an example of that.

I think you should demonstrate this on your site, not in the middle of technical discussions. If you had been straightforward about the fact that there would be _real world data loss_ by using Ckeditor v5 with content created with Ckeditor v4, then we would not have implemented it as we did.

The least you could do, considering the time we spent, is to show me on your site where I can read about the dramatic shifts from v4 to v5 in how it will treat the HTML being inserted and retrieved from the editor.

5. Address real time, money and data lost

@ baona95: I was fortunate to find out this issue from Google, otherwise it would take me a lot of time to dig in.

I hope they update their site to make it clear that devs can lose real data by attempting to upgrade v4 to v5.

6. Free help

I will gladly offer my writing services for free to help you update your download page so that other developers don't waste time and money and lose data like we have.

I hope Ckeditor v5 development goes well and it succeeds. I like the idea of perfectly controlled content without any mistakes or errors caused by users.

[Reinmar]

From the Migration from CKEditor 4 guide:

An extremely important aspect to be remembered is that — because of the difference in features — the data produced with CKEditor 4 may not be compatible with CKEditor 5.

Extensive analysis, data verification and tests should be performed on existing data. If necessary, you will need to develop conversion procedures to avoid data loss. A relatively simple yet efficient strategy of adopting CKEditor 5 into existing systems might be using CKEditor 5 for creating new content and the old editor for editing legacy content.

And earlier:

When compared to its predecessor, CKEditor 5 should be considered a totally new editor. Every single aspect of it was redesigned — from installation, to integration, to features, to its data model, and finally to its API. Therefore, moving applications using a previous CKEditor version to version 5 cannot be simply called an “upgrade”. It is something bigger, so the “migration” term fits better.

And in Overview of CKEditor 5 builds (section "When NOT to use CKEditor 5"):

In the following cases CKEditor 4 should be used instead:

• When compatibility with old browsers is a requirement.
• If CKEditor 4 contains features that are essential for you, which are not available in CKEditor 5 yet.
• If CKEditor 4 is already in use in your application and you are still not ready to replace it with CKEditor 5.

So, we've really done quite a lot to raise awarness of developers who may try to migrate to CKEditor 5. The only thing I'd improve is this:

data produced with CKEditor 4 may not be compatible with CKEditor 5

which may be changed to this:

data produced with CKEditor 4 may not be compatible with CKEditor 5 which may lead to data loss

But if you don't read the documentation, you won't find it anyway. Don't blame us, though.

I'll not comment more on this.

[megacromulent]

Preface

I think Ckeditor is the best online/html/content editor ever made. It's the only editor we've ever used, from the beginning. I feel your design decisions with Ckeditor 5 have a lot of merit, and are likely the basis for the future of content editing (in some way at least). And I don't be-grudge you any of those decisions. Please take this into account with all my comments.

Since we have not paid a dime for this product, my comments are more to the other developers that are looking for the same answers as I was, than to you expecting work done for free.

1. CKEditor 5 is NOT an HTML editor (or is it?)

To developers looking to upgrade Ckeditor from 4 to 5: This is for long time developers that have been using Ckeditor (some since it was called FCKeditor), and don't think to read every page in a guide (including the "Migration from CKEditor 4 ") because Ckeditor 5 appears to be upgrade, not a totally and completely different editor that breaks almost all backwards compatibility. (but what it breaks on the content itself, at this time, is still uncertain)

CKEditor 4 was an html editor with a "view source" button, CKEditor 5 is not an html editor (as far as I can tell), and does not have a view source button. If you insert any html content into it (whether it was generated by users or by developers) it _will_ alter that code immediately, and strip out an unknown amount of data.

There is a migration page here: https://docs.ckeditor.com/ckeditor5/latest/builds/guides/migrate.html

It will not describe what data will be removed so you will have to test (every piece of content you edit?) or use a different editor entirely, or stick with CKEditor 4. Maybe someone in-the-know can update the documentation or add a comment.

2. Conflicting views on the future plans for Ckeditor 5

@ Reinmar: You seem to be having conflicting feedback from fredck, note his first response was this. The implication being that discussion on this topic (view source) was still "up for debate".

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

So, the more input we have, the better.

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.

3. Is it technically possible to have a 'view source' button or not?

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

If "view source" can be a plugin, then can't CKeditor v5 be an HTML editor (see point 1)? There seems to be confusion on the state of Ckeditor 5, and it's future capabilities.

4. Not all content is "user generated" but still needs an editor.

Tons of content we edit is based on defaults, templates and sources not created by "users", but by designers and programmers. If CKEditor is an HTML editor, we can work with that, if it's not, then how do we insert non-user generated HTML content with full confidence it won't get mangled or have data loss?

5. What data get's removed by Ckeditor 5?

I can't find any documentation on what HTML data will be removed. Can you provide a link to show which content Ckeditor 5 will remove from HTML content inserted into it? This would help us avoid putting in content that is guaranteed to get stripped out.

6. No easily found answers on HTML content changes and editing with Ckeditor 5

I am only here to add comments because I couldn't find answers anywhere else on the internet. (so I am sure others are stuck too) I am glad you have the migration page up, but it didn't help with questions like "why does Ckeditor 5 remove data?" There are no useful results in search engines for this topic, which is confusing. The migration page states something like this, but I already know it does, so stating that it does isn't actually helpful, we need to know what decision process is used, which is my second question "how can we determine what data will be removed?" Finally when I asked "Where is the 'view source' button?" I found this page. And only having this back and forth in comments did I find out some of the answers (still only partially and not totally certain, still can't tell if Ckeditor 5 is an html editor or not, or if it might be in the future, or not??).

I realize you do not intend to continue this discussion, perhaps fredck can jump in and give us some guidance on the future of Ckeditor 5 on how it will deal with HTML content?

[Videles]

First of all thanks for the great work!

I came across this topic after I just implemented CKEditor5 and i was looking how to add the 'view source' option.

From what I understand there are many valid reasons to have this option, personally I'm also used to quickly create mark-up via this option to get the best result. But with the this new approach it is not possible to implement it.

That said I just tested the editor a little bit with just writing text and creating some lists in it. And the markup generated is much better then what i saw in any previous editors, which kinda forced you to use the view html option to clean the mark-up up. It actually creates perfect clean mark-up (not with tags etc as others mentioned though).

So for a content writer with no HTML knowledge at all this seems to be a much better solution (for this particular purpose).

So depending on the case I would choose between 4 and 5. For my current case version 5 is the better option.

[DrZiggy]

I understand the choice to make CKE-5 more a "content editor", but I do hope you also understand that a lot of developer have implemented CKE-4 as a HTML editor. It was an extremely easy tool to give users a way to edit a (full) page for some textual changes and also allow advanced users to use it as a HTML editor on the fly.

On most of the request you have simply stated "You can build a plugin" to support that. Yes, sure we can. But if I have to charge my customers twice the amount because I have to build plugins for everything, they will go to the competitor that simply implements CKE-4 and has instant support for everything.

It feels like most developers/decision makers on CKE only work for CKE and don't understand that the company's implementing you software work for a lot of different clients, all with different wishes and use cases and that we simply don't have the luxury of stating "Yeah, you're using it wrong. Do it like we say it must be used, not like you want to use it".

Obviously it's your software and you can build it however you want to, but you would make a lot of people happy if you make a distinction between CKE-4 (html-editor) and CKE-5 (content-editor) and keep them both up and running.

Besides that, it would really help if you make a decent tutorial on how to build those plugins. Let's say I want to add a button that takes a youtube link and creates the HTML needed for that.
I couldn't find any documentation on how to build something like this:

<iframe width="560" height="315" src="{{INSERT LINK HERE}}" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>

[martyjt]

hmm. I really can't believe you are removing that. Another one here , wanting to use it as an HTML editor.

A HUGE use case for this is writing apps that manage data / metadata for the web. With emerging complexities of metadata that most search engines are behind ( see https://schema.org/ ) , there is sometimes a need to make sure that the correct markup is rendered. If you copy + paste from other systems , sure your solution is to fix it , with whatever rules you have in place.

But , you need to make sure that when you copy + paste from other systems that you are not pulling things through that are not going to work with the expected metadata.

If you keep this feature out , you're shooting yourself in the foot.. and you will lose ( or not gain ) a lot of customers.

Seriously , do a customer survey to find these sorts of things out , don't just assume .

[Zen4All]

I usually do not participate in these kind of discussions, but felt I had to say this.
You say editing source code use for developers, not end users, but you seem to forget it is the developers who implement ckeditor in to software used by end users.
If the developer is unhappy about using ckeditor he will not implement it, and thus the end user will not use it either.

[archonic]

I understand why view source is not a goal. HTML is not the source - the custom data model is. I can see why people would be frustrated by the upgrade path being so prone to breakage though.

I just wanted to chime in and say that an attribute wildcard feature would solve an issue of mine. I've developed a table of contents feature (as a hold-over til #966 moves forward) which scrubs a document for headers, and creates a second "document" which is a navigation with anchor links. It works well but for it to work in the edit view, I need the headers to express their ID.

[SKGGitHub]

I had gone through half way through comments but not all. Can someone let me know if we have "view source" functionality in CKEditor5 developed now?

[SKGGitHub]

Can some one suggest please if View source plugin is available in CKeditor5?

[Reinmar]

Can some one suggest please if View source plugin is available in CKeditor5?

The answer is there, in the very first comments. And the answer is – at this moment no.

---

BTW, we're planning to write a summary of this thread in which we'll describe what features can be implemented and which are not feasible. Our goal is to ask for your feedback on which of these features would solve the problem for your scenarios and then we'll consider implementing those.

In the meantime, I'm locking this thread as it's going in circles for a couple of months. We'll be posting new information here, though, so stay tuned :)

[Reinmar]

We've been quiet on this front for a while (sorry for that!), but there was actually quite some work done internally. Mainly research, but also a couple of prototypes.

We need to understand how far we can push CKEditor 5 without breaking the editing experience and its stability. There are two extremes – the current situation and the "free HTML editing". We need to find the right balance between them.

If we'll go too far in the "free HTML editing", then (from my experience) many developers will choose that "easy" path (which is to enable as much HTML as possible) without considering the downsides. That may cause instability and badly affect the UX and this will backfire on the project because that poor experience will be attributed to CKEditor 5. We don't want that and that's why we want to be cautious.

Nevertheless, it isn't black and white. There's a whole range of HTML features which we can enable. And we plan to do that. We will start working on that in Q2 2019.

Some examples of HTML features which we consider "safe" at the moment:

• All attributes of already supported block-level markup like <p>, <h1>, <blockquote> (not sure about lists).
• All attributes of already supported inline-level markup like <a>, <strong>, etc.
• Support for new structure-level elements like <div>s or <section>s with all their attributes.
• Support for <span>s with all their attributes.
• Support for object-like elements (<iframe>, <video>, etc.).
• And more...

More details should appear in a couple of weeks.