"View Source" functionality / plugin #592
Comments
|
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:
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! |
|
Hey fredck. Thanks for your feedback. 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:
i will ask my colleagues some more usecases, where we use this CK4 feature |
Reinmar
added
status:discussion
type:feature
|
Some more "usacases" from my colleagues:
|
|
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. |
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 5So 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 modeSo, 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. PSIt 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. |
|
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. |
|
Ok, understood. CKEditor doesn't seem to be the right choice for my use-cases, i'll find another alternative. Thanks for the information. |
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. |
|
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. |
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? |
|
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. |
|
I would like to reiterate one of the reasons from @mborejdo -
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 -
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)? |
|
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. |
|
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) |
|
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. |
|
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 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. |
|
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. |
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 |
|
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? |
|
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
<#592 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AgPAIf6nvGzOWtM0Iu7MUjdw6yd0DEOpks5s4DC4gaJpZM4PwSwQ>.
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virusvrij. www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
Dutchbrite B.V.
Rijtuigenhof 105
1054 NC Amsterdam
tel. 020-4892363
www.dutchbrite.nl
|
|
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! 👍 ) |
|
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 |
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:
Another scenario is applying a format (e.g. a heading) to a list item. It converts 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. |
|
@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 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: 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 |
|
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 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! |
|
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? |
|
On 6/13/19 7:08 PM, Archonic wrote:
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?
For those who need SOURCE, we'll just need to stay on CKEditor 4.
Most SOURCE-needingusers don't want just a text field, but want to enter
special HTML/CSS/JavaScript/JSP/etc. and then return to WYSIWYG. SOURCE
mode is used to meet special needs that are impossible to create a
plugin for every possible such need.
|
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). |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
actullay i need to know when you will support the view source and the ability to edit it in the ckeditor 5 |
|
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. |
|
We are using ckeditor 4 in a SaaS CRM as an Email Template Editor. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Reinmar
added
domain:v4-compatibility
|
Some good news finally ;) 🎉 We've just released two features that I think you'll love:
We plan to continue work on General HTML Support (GHS) as there are some gaps (see e.g. https://ckeditor.com/docs/ckeditor5/latest/features/general-html-support.html#known-issues and #2973). However, the features that GHS offers already should resolve most of your use cases. Thus, I'm closing this ticket. Thank everyone for your input ❤️ |
and others
Edit (by @Reinmar on 19 July 2021)
We've just released General HTML Support that resolves most of the issues mentioned in this thread.
Read more:
Edit (by @Reinmar on 7 March 2019)
This ticket covers the following three aspects:
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:
Thank you!
Original ticket
The text was updated successfully, but these errors were encountered: