Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"View Source" functionality / plugin #592

Open
mborejdo opened this issue Oct 6, 2017 · 104 comments

Comments

@mborejdo
Copy link

commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Author

commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Author

commented Oct 6, 2017

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

This comment has been minimized.

Copy link

commented Oct 7, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 9, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2017

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

This comment has been minimized.

Copy link

commented Oct 9, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 9, 2017

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

This comment has been minimized.

Copy link
Author

commented Oct 9, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 9, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2017

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

This comment has been minimized.

Copy link

commented Oct 19, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2017

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

This comment has been minimized.

Copy link

commented Oct 19, 2017

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 pjasiun referenced this issue Oct 23, 2017
@pjasiun

This comment has been minimized.

Copy link
Member

commented Oct 23, 2017

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

This comment has been minimized.

Copy link

commented Nov 19, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 19, 2017

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 Reinmar closed this Nov 19, 2017
@Reinmar Reinmar reopened this Nov 19, 2017
@Reinmar

This comment has been minimized.

Copy link
Member

commented Nov 19, 2017

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

This comment has been minimized.

Copy link

commented Nov 19, 2017

@pferreir

This comment has been minimized.

Copy link

commented Nov 21, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Nov 22, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 22, 2017

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.

@bs-thomas

This comment has been minimized.

Copy link

commented Mar 7, 2019

Hello @Reinmar , thanks for getting back to me and updating us. Really appreciate it. The updates you give us look exciting, and really looking forward to them!

Actually, as far as what the HTML5 standard permits, would it be possible to support those?

The reason for my request is, I can completely understand that many developers take the "easy path". But it's really up to their responsibility (and their risk) to do that, because when something bad happens, it would be their responsibility to fix it.

My suggestion is not to enable things by default, and rather have developers add what they need to it, as they need them.

At our company, we simply need the flexibility for developers to assist clients. Also, from time to time when our clients cannot do something, or is making a wild request (you know, some clients are not easy to deal with), developers would then be able to do minor hacks (such as inserting a quick JS <script> tag).

Thanks again for picking up the nudge, and giving us some cool updates!

@Videles

This comment has been minimized.

Copy link

commented Mar 7, 2019

@Reinmar

This comment has been minimized.

Copy link
Member

commented Mar 12, 2019

@tomaszmys brought the topic of XSS vectors once we'd start allowing more attributes. That's not an issue so far because CKE5 filters out all those attributes anyway. We started discussing this issue in #1624.

@luxin88

This comment was marked as off-topic.

Copy link

commented Apr 21, 2019

@tomaszmys brought the topic of XSS vectors once we'd start allowing more attributes. That's not an issue so far because CKE5 filters out all those attributes anyway. We started discussing this issue in #1624.

You can't stop malicious people from using tools to submit xss code, such as using postman.
that is Anti-gentleman is not against villains

@hybridwebdev

This comment was marked as off-topic.

Copy link

commented May 8, 2019

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 .

From reading this entire thread, I can safely say that these people do not seem to be interested in listening to what others have to say regarding this. Sadly, the attitude I got from reading this thread is that "they know better" and that if you need this feature "you're doing it wrong".

You're 100% right though. If a system like this doesn't listen to it's users feedback, it 100% will not ever grow and in fact will likely evaporate into irrelevance when some other platform that DOES listen to its users implements said features.

Realistically, there are nearly infinite reasons why a "view source" feature is needed, but it seems that doesn't matter to them as they insist we don't need it.

I've been a dev a LONG time, and honestly it seems to me like the reason they don't want to add this, is because their system is clearly too fragile to support it.

@crshumate

This comment has been minimized.

Copy link

commented Jun 13, 2019

More details should appear in a couple of weeks

Is this in a blog post or documentation somewhere? It is June 2019. I just took the time to implement CKE5 in my company's nextjs/react custom CMS thinking Source View was a market standard and no brainer.

While it's been an option and standard for years across many WYSIWYG editors, when I went to enable Source View imagine my surprise and then dismay at wasting my time implementing this and not finding a Source View option.

It's dishonest to market this as a WYSIWYG Editor w/o Source View when for over a decade every WYSIWYG that was taken seriously has had/or has this feature.

@skurfuerst

This comment has been minimized.

Copy link

commented Jun 13, 2019

@crshumate I think that's a very unfair statement you are making -- please appreciate all the hard work the guys and girls around @Reinmar are spending on all this! We've had phenomenal success (and support) integrating CKEditor5 into Neos.

@crshumate

This comment has been minimized.

Copy link

commented Jun 13, 2019

@skurfuerst How is it unfair and very unfair at that? Simply because you disagree?

I'm not mocking or dissing the work they did do. Other than Source View missing, which is a critical feature for my company and many other developers, the plugin works splendidly.

However, I am quite frustrated both at the lack of the feature and the response. In this thread they act as if we have to justify to them the feature...when for years it's been a market standard and expectation.

What I said is true: Source View is an expected market standard when it comes to WYSIWYG editors. That's the exact reason we see so many frustrated developers/implementers in this thread.

If it's not a WYSIWYG editor that's fine but don't use that term as developers have certain expectations surrounding what WYSIWYG means. Don't use it for marketing just to get eyes and interest if it lacks market standards. Otherwise they will receive a bevy of frustrated developers who are going to rip out the code.

At minimum, if we're being objective and honest, there should be a warning/explanation on the front page of the documentation explaining that Source View is not a feature so devs do not waste their time

@bs-thomas

This comment has been minimized.

Copy link

commented Jun 14, 2019

My company also wants to have the view source feature.

I think the biggest argument that CK editor has is that editing HTML in this plugin is not the right thing to do. It will also possibly break a few core features because of unexpected open-ended changes developers can make into the code.

However, I personally think that business requirements actually rule out the two arguments above.

On another note, I think that if I'm implementing
ckeditor on something like jira, I could understand that the wysiwyg editor should not have a view source button, because they would never have to play with complicated layouts using the editor. They just need the basic styling features and paragraph features.

However, if I'm implementing CK editor on a website control panel, the whole story is different and the view source feature would be almost mandatory.

Of course the feature list is really up to the dev team here. At the moment I am unable to use this version of CK editor. I'm forced to fall back to the previous version, hopefully if I'd be able to hear some good news about the view source feature I'll definitely want to jump onto this version.

Thanks all!

@archonic

This comment has been minimized.

Copy link

commented Jun 14, 2019

This feature request is ultimately asking for a text editor as a feature within a vastly more complex editor. What's stopping you from creating a feature inside your app to load a textfield instead of CKEditor5? Or from creating a different view that uses CodeMirror?

@OpenESignForms

This comment has been minimized.

Copy link

commented Jun 14, 2019

@wwalc

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

For those who need SOURCE, we'll just need to stay on CKEditor 4.

Exactly. Especially, if by "View source" one understands being able to type freely random HTML code. Personally, I think that's the most reasonable option for now. We will support CKEditor 4 until 2023 so if you need a classic WYSIWYG editor with source mode and support for typing freely any HTML, just choose or keep using CKEditor 4 for now. Unless you are ready to invest a lot of your time (&money) to write custom plugins to support that. CKEditor 4 is a rock solid, well-documented editor that has good browser support and is still actively being developed.

I understand the disappointment of some of you. We also would love to have all the features that users request in CKEditor 5 immediately. After all, that would make all CKEditor users happy, which in result would make us happy too. It's really not easy knowing that there is a thread full of disappointed people and knowing that there isn't much you can do with it at that moment.

When releasing CKEditor 5 we had two alternatives: keep it hidden from the public for further 3-4 years, until we implement enough features to satisfy 90%+ of people, or just release it and add features gradually. The first beta release of CKEditor 5 in 2017 probably satisfied <5% of people. Does it mean that it was bad to release it? I don't think so. After all, a few percents of people received something that they needed. Did 95% of people lose anything because of that? Probably not, they still could use CKEditor 4. We try to document really well all the features of both editors, so anyone at any moment can have a look at what they offer and make a conscious choice.

We continue adding features gradually to CKEditor 5 and will continue doing so for many years to come. We do have limited resources though, so we need to prioritize our work somehow (hint: if you would like us to develop faster, purchase a commercial license or sponsor some features development, we will simply hire more devs for all the money). Seeing how View source feature is important, we did what we could for now and performed internal research as @Reinmar mentioned already. We know how much effort it requires: a lot. If it was a task for a month or two we'd do this already, but it isn't (the list of topics that it covers is in #592 (comment)).

As for priorities, we keep getting many many other requests that are more in line with the needs of the current user base of CKEditor 5, for example, better tables support or being able to resize images, code blocks and so on. When we more or less address issues like that and make sure that current CKEditor 5 users have a super decent editor, we'd gradually switch to "source mode" topic and provide the rest of users an easy way to jump in into an already super decent editor. The whole effort is not only about "source mode" itself, but also about making it easy for 80%+ of people to migrate from CKEditor 4 (or any other editor).

@jaybaldwin

This comment was marked as off-topic.

Copy link

commented Jul 19, 2019

I just spent about 8 hours implementing CKEditor 5 in a critical project where source mode is a requirement due to some special HTML that can't be imported into the content area any other way, and I'm just learning now that it isn't supported. I tried to downgrade to CKeditor 4, but for whatever reason, that isn't working on the iPad solution I need this editor to work for. The decision to not include an HTML edit view in this seems incredibly left-turn out of nowhere. I liken it to Reese's peanut butter cups replacing peanut butter with Nutella suddenly and without labeling it as such. You just end up getting something that may be good but you never really wanted in the first place.

Why break an existing brand that already is one thing? This "it's a content editor not an HTML editor" is literally never how I've ever used it, and I've been using it for going on 8 years. I'll likely be forced to find something else and switch away entirely for most of my projects.

@seyaobey

This comment was marked as off-topic.

Copy link

commented Jul 19, 2019

Same here. I spent the whole day yesterday integrating ckeditor5-react into a react application and applying some custom styles to suit our theming.
View Source and html editing is critical in our project. After having spent a few hours, I just discovered that it does not support the above mentioned feature.

I reverted back to ckeditor4-react. Though it's working, it throws an error in console:

[CKEDITOR]Error Code: editor-element-conflict`.

It looks like it is trying to re-attach the existing editor.

But this is a react application. I have just mounted the ckeditor component and I have attached an onChange event to update the text content.

   <CKEditor
        data={content}
        onChange={(event, editor) => {
          if (editor) {
            handleChange(editor.getData());
          }
        }}
      />

I am not trying to unmount and re-mount this component every time. Any help from your team will be greatly appreciated as this is a very critical component in the project.

Thank you.

ckeditor

@Maxhou00

This comment was marked as off-topic.

Copy link

commented Aug 8, 2019

We will support CKEditor 4 until 2023

@wwalc So please, fix the following issue on android/ios it's not possible to select text and copy/paste. This issue is reported since 2017 and still open. Nowadays many of web user are using their smartphone, 86% of my traffic is on mobile.

Also about the source mode, you forgot that user all over the world doesn't have the same habit. In South Korea people are using "source mode" on everywhere because of the Naver blog. They are used to copy their content from their blog to somewhere else using HTML. And non of them are developer or computer engineer, they are simple user with no knowledge of programming so the "Source view" is not something needed for developer only.

I have tried to migrate from CKEDITOR4 to CKEDITOR5 because my users are mainly on smartphone and cannot select their text in the content and because the version 4 doesn't seems to be supported anymore. I was disappointed to see the "Source View" is not available on CKEDITOR5 anymore.

@Reinmar

This comment was marked as off-topic.

Copy link
Member

commented Aug 8, 2019

Also about the source mode, you forgot that user all over the world doesn't have the same habit. In South Korea people are using "source mode" on everywhere because of the Naver blog. They are used to copy their content from their blog to somewhere else using HTML. And non of them are developer or computer engineer, they are simple user with no knowledge of programming so the "Source view" is not something needed for developer only.

I really encourage you to read the thread before commenting. E.g. this comment: #592 (comment). There's no problem with allowing anyone to get the output HTML from the editor. It's a simple feature that can be developed by anyone. And this thread is not about it.

@Maxhou00

This comment was marked as off-topic.

Copy link

commented Aug 9, 2019

There's no problem with allowing anyone to get the output HTML from the editor.

Then I really encourage you to read my comment few times before you answer. At any moment I have never mentionned about reading the output HTML. I'm talking about paste their HTML inside ckeditor for creating their post.

They copy the HTML of their article from their Naver blog and then paste it on other other website (like mine) because it's faster and easier than restyling all their article.

Please don't be too focus on your deny, you haven't read my comment.

@AminaMahmod

This comment has been minimized.

Copy link

commented Sep 30, 2019

actullay i need to know when you will support the view source and the ability to edit it in the ckeditor 5
as it's so important to my work right now @Reinmar

@ruslanguns

This comment has been minimized.

Copy link

commented Oct 15, 2019

Well in my case, I am simply going to use the Markdown processor and it is really important to be able to work around Source Code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.