Feedback from Content Editor MVC in Wiki

This issue was created to collect feedback related to the Content Editor and its initial implementation in the Wiki. We have gathered the feedback we needed to mature the editor so we'll be closing this issue. If you have additional feedback, please create a new issue and label it with ~"group::editor" and Content Editor

---

GitLab %14.0 includes the first publicly-available implementation of the new Content Editor, a WYSIWYG editing experience for Markdown. Our first goal is to make the Content Editor the default Markdown editor for the GitLab Wiki, with full support for GitLab Flavored Markdown extensions.

Currently, we have support many of the basic Markdown content types like

• Headers
• Bold and italic text
• Inline code and code blocks
• Blockquotes
• Links

In the coming milestones, we're excited to continue working on more complex content types like Images and Tables.

Direction

The Content Editor was architected as a reusable and extensible component, meant to be consumed by more than just the Wiki. Behind the scenes, the editor reads and writes Markdown. This is an important distinction because it would have been easier to read Markdown and write out a proprietary format. We feel this prohibits collaboration on content from those who don't wish to use the Content Editor and prefer to edit content in the repository directly. If you like writing Markdown in vim, we don't want to stop you.

As we complete support for GitLab Flavored Markdown, we'll be looking to spread the Content Editor around GitLab wherever Markdown content is edited. Our second target is likely going to be issue and epic descriptions, something we're very excited to work on!

Related issues and epics

• Content Editor Strategy
• Use Content Editor in Wiki
• WYSIWYG Editing in Wiki
• Evaluation of editor libraries against UX requirements

added to epic &6109 (closed)

changed the description

changed milestone to %Backlog

added Content Editor groupeditor [DEPRECATED] labels

assigned to @ericschurter

changed the description

Setting label(s) devopscreate sectiondev based on ~"group::editor".

added devopscreate sectiondev labels

mentioned in issue #332895 (closed)

changed the description

Hi! I'm the Product Manager for the Editor group and I want to thank you for your interest in the Content Editor.

FYI I'll be out of the office leading up to the 14.0 release so if you stumbled in here early because you found the editor early, I'll respond to all your feedback when I'm back on 2021-06-21

Hi @ericschurter ,

I've tried the editor on gitlab.com (the beta one) today. It is really nice to use and is a huge benefit for users who don't like markdown (I personally write most of my stuff in markdown ).

What I miss is the shortcut for inserting a hyperlink. Most application using CTRL + K (I guess MacOS has CMD + K) including GitLab itself (in the markdown view). The workflow through the link button and the inline textfield/apply-button feels not very straight forward for non markdown users (I assume people who are using Word or Google Docs).

Also I'm not sure how I can insert images. When I drag an image into the browser (in my case Brave) the whole image will be opened instead of importing it (in the markdown version it would insert the link). I'm not sure where I can add an image (there is no button in the toolbar) or if this is a missing feature right now.

I second this, could not drag and drop an image, so reverted to old interface

What I miss is the shortcut for inserting a hyperlink

Yes! Good catch, I just created #334189 (closed) to track that enhancement.

Also I'm not sure how I can insert images

Unfortunately you can't at the moment but you'll be happy to know it's planned for the %14.1 milestone! #328641 (closed)

@tonka3000 @mebibou Neglected to ping you directly on that

Appreciate the feedback and I hope we can get image insertion very soon for you!

Issue: After inserting a code block at the end of the content, there is no way to continue the content with regular text, i.e., to get the cursor out of the code block.

I also had this happen. I was able to work around it by entering a space after the location I intended to place the code block and was then able to move the cursor past.

Thanks for the feedback @pierre.carbonnelle and @davidahopp!

I created #334190 (closed) to address the code block behavior. It turns out that the official way to do this is to use Cmd/Ctrl + Return to exit the code block. But please don't do this because there is a conflicting shortcut and that will actually submit the form on the page. I have this open bug to address that behavior as well #334191 (closed).

Unfortunately, this is still an issue

Good to have: A vertical scroller might be helpful while editing as wiki will definitely run for multiple pages.

Second on this. Locking the format bar so that you can always see it while editing is very much needed.

@muthuraj.ramasamy @davidahopp Thanks for the feedback!

I agree, and we've been exploring some concepts for increasing the usable space of the editor in this issue: #328750 (closed). And we also feel pretty strongly that the future of the editing UI will be more of a block-based, contextual menu experience (similar to what you'd find in Notion or Medium) to specifically address the toolbar shortcomings. We're planning that out still, but it'll be tracked here: &5915

Hi! Nice work :)

I have an issue with the [[_TOC_]] feature described here.

The visual editor (unexpectedly) allows editing of the TOC, which on saving becomes "hardcoded" (the [[_TOC_]] macro is replaced by literal/hardcoded markdown).

Perhaps the visual editor should treat these macros specially?

Thanks!

@naikymen Thanks for the kind words!

The [[_TOC_]] shortcut is part of our custom extensions to Markdown and something we are tracking in this epic: &5438. We plan to support this, all GitLab Flavored Markdown extensions, and some really exciting custom content nodes in the future!

Even worse: even if I don't edit the TOC, the [[_TOC_]] is replaced by the corresponding text (with links, etc.) and hence becomes obsolete at once when the headings are changed.

So I cannot use the content editor on pages that have [[_TOC_]] (or then I always have to re-edit it in Markdown, delete the corresponding, long text and add back the [[_TOC_]]).

@userq I'm not sure I see what you're experiencing, but it's possible you're using a version before we shipped support for the [[_TOC_]] macro. We shipped this issue in 14.4 that should fix the behavior for pages that include a Table of Contents.

Here's what I see when I edit a page that includes a ToC:

In later iterations, we'll work on making this more interactive and update as you type, but for now it should not require any re-editing.

Thanks, you are right. Now we finally got an update (to 14.7.2) and the [[TOC]] problem disappeared. The "```" becomes "```plaintext" problem remains, but it is not that important. (So "```" becomes "```plaintext" when you use the "Edit rich text", but TOC:s are not changed anymore, so I'm quite happy.)

doesn't work on waterfox. loading forever

Thanks for the report @c33s, I just created #334195 (closed) to investigate

A quick follow-up, I found our list of supported browsers right after creating the issue. Since Waterfox isn't on our list of supported browsers, we're not likely to pick this up any time soon but it would make a great community contribution so I'll leave the issue open.

If the bug affects other browsers we can revisit. But please feel free to add any specific browser details, error messages, or other information in the linked issue @c33s. Thanks again!

Nice work guys!

I prefer using the old editor. Two killer features for me (compared to GitHub Wikis) are

• the ability to drag and drop images and
• the ability to copy paste tables from LibreOffice and get automatic md formatting

Something I miss is:

• some syntax coloring in the (old) editor (if possible) and
• automatic list continuation, i.e. pressing Enter should generate another list entry in the new line (indentation and tick box as neccessary). This works in GitHub issues editor (but not in their Wikis editor).

Thanks @gerazov! I hope you'll be happy to hear that images and tables are the next two features we're working on! We've planned inserting images and rendering and editing content in a table for %14.1

We'll continue to iterate on the experience of those content types in later milestones as well, including adding custom UI for editing images and table structure.

some syntax coloring in the (old) editor (if possible)

I think what you're saying is you like the syntax highlighting in the new editor when viewing code blocks. We can do a lot more with this new editor in that area for sure. Your feedback actually had me thinking more and I just created #334198 (closed) to start the conversation about theming the editor. We'll keep it on our radar as we refine the UI and introduce the Content Editor elsewhere in GitLab.

automatic list continuation

Agreed, this is super nice. I like this about the new editor but it could be useful in other contexts. I could see this being added to our Source Editor (the counterpart to the Content Editor, for editing source code). I created #334200 to explore this. That said, the "classic" Wiki editor isn't using Source Editor either, so it wouldn't likely inherit this functionality.

I can't upload an image from the clipboard, i.e. copy & paste.

@kahraman78 You're right, unfortunately a known limitation. The good news is this is planned for %14.1! Follow along with this issue: #328641 (closed)

Sadly, the shortcut crtl+enter for saving the document DOES save the document but not the one from the new editor but the underlying plaintext document which does not contain any changes from the editor. Thus all changes are lost :(

Wow, you're right @julianseeger. I just created #334191 (closed) to investigate but we'll get that resolved as soon as possible. Thanks for the report!

It's nice (for simple user), but could some feature add for experts, like:

• Split-Screen (Markdown and Preview) or toogle-function
• Scrollbars or that toolbar always on top
• Paste image from clipboard

Then was the new editor very great. Thanks.

Hi @Matthias.Lensing, thanks for giving the new editor a try and for the kind words!

Split-Screen (Markdown and Preview) or toogle-function

We've started thinking about that in this issue: #328764 (closed). The idea is that for the vast majority of users, writing in the new editor will be preferred. But a way to switch over and view the source would be helpful in some cases.

Scrollbars or that toolbar always on top

I mentioned this in another thread above, but the UI for the editor is something we intend to iterate on in the coming milestones. We're hoping a full-screen experience will be easier to use and moving toward a block-style editor (similar to what you'd see in Medium or Notion) will bring the controls closer to your cursor.

Paste image from clipboard

Yes! We're working on inserting images in %14.1 and I'll be sure to capture that they should be able to be pasted from the clipboard.