The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Content last reviewed on 2023-02-23
Thanks for visiting the direction page for the Content Editor, a what-you-see-is-what-you-get (WYSIWYG) editor for Markdown content maintained by the Knowledge group. While not a singular feature or official category in itself, the Content Editor is a critical component and cornerstone of the Knowledge group's strategy. More information about the Editor group's priorities and direction can be found on the Knowledge group direction page and additional questions can be directed to Matthew Macfarlane (E-Mail).
The Content Editor is a WYSIWYG editor for Markdown content.
While there are many rich text web editors out there, one aspect of the Content Editor that sets it apart is how it preserves the Markdown format. While others use intermediate file formats or require saving changes to a database, the Content Editor reads and writes valid Markdown, allowing collaboration from any editor and preserving the Markdown source.
Everyone!
For many, writing in Markdown is a barrier to collaboration. Remembering the syntax for image references or working with long tables can be tedious even for those who are relatively experienced with the syntax. Still, Markdown as a common denominator for content enables efficient collaboration in a version controlled environment. The Content Editor aims to break down these barriers by providing a rich editing experience and an extensible foundation on which we can build custom editing interfaces for things like diagrams, content embeds, media management, and more.
There are many contributors to GitLab for whom writing Markdown is like writing a second (or third, or fourth) language. When you can see the Matrix, everything starts to make sense. We don't want to take that super power away from anyone. That's why writing in the Content Editor will support standard Markdown shortcuts. Typing ## followed by your content will create a rendered Header 2 and let you continue working without removing your fingers from the keyboard.
We are starting by implementing the Content Editor in the GitLab Wiki. Eventually, after we achieve full compatibility with the custom GitLab Flavored Markdown extensions, we will work to integrate it with issue and epic descriptions. Our goal is to make the Content Editor available wherever Markdown is written in Gitlab.
With the upcoming removal of the Static Site Editor feature, we plan to make the Content Editor available in the Web Editor and Web IDE to make it easier for everyone to contribute to Markdown content in a repository. Seamless integration of the Content Editor in the web editing experience will realize nearly all the benefits of the Static Site Editor but we are no longer limiting it to Middleman-based projects configured to use the Static Site Editor.
At a really high level, the Content Editor:
We have written comprehensive development guidelines that explain what's going on under the hood and can help get you up to speed if you're interested in contributing an extension to the Content Editor.
We have to start somewhere. The beauty of the Content Editor architecture is that it can be extended to support other flavors of Markdown and even entirely separate formats like AsciiDoc or RDoc.
Our current focus is on building out support for the many extensions available in GitLab Flavored Markdown and achieving feature parity with the raw Markdown editor available when editing issue, epic, and MR descriptions and comments. Using the Content Editor to edit issue and epic descriptions is currently being tested behind a feature flag and we're working on refining the experience in preparation for general availablity.
We are also focused on building a front-end deserializer for Markdown to limit the need for a call to the backend service and providing more source mapping data to the editor. The primary benefit that comes from parsing Markdown on the front-end is that we can more granularly identify which parts of the content are being edited and limit the amount of reformatting that happens during the round-trip from Markdown to HTML and back to Markdown. In the end, what we get here is less noisy page diffs, which will then allow us to work on integrating the Content Editor elsewhere across Gitlab.