Preventing front matter and custom syntax from rendering in WYSIWYG mode

Summary

The Toast UI Editor is awesome and we’ve begun to use it at GitLab. I’m currently exploring options for how we can prevent certain portions of a source file from being edited in WYSIWYG mode. For example:

• Simple = raw markdown file (.md solved automatically)
• Complex = mixed languages (.html.md.erb example here)

Context

You can view additional context in this issue but I’m currently under the impression that a custom HTML renderer is the way to go.

Questions

1. Do any approaches other than the custom HTML renderer come to mind?
2. I’d imagine preventing frontmatter from being edited in the WYSIWYG mode would be a common expectation. Do you know of an existing solution or custom HTML renderer that prevents frontmatter from rendering in WYSIWYG mode?
3. Can you point us to any existing open source custom HTML renderers that others have created? These would be great learning resources and/or jump-off points.

Thank you

Thank you in advance for any feedback and hopefully we can contribute back to Toast UI Editor as we make progress. For example if #2 above doesn’t exist already, I’d imagine others would find such a custom renderer useful.

[js87zz]

@derek-knox Sorry for late replying. We are planning to develop our front-matter plugin or option and start to develop today as below.

• Create the option for parser that can be injected from outside in our markdown parser(toastmark).
  • This is necessary for not only the front-matters but also for other custom syntax(markdown), so we will review and add this option. It is an important part of our next major update.
• Using node(front-matter) created through custom parser, control rendering of WYSIWYG, markdown preview.
  • Currently, we think that front-matter should be hidden in WYSIWYG, markdown preview because it is unnecessary in WYSIWYG editor, preview.
• The issue is that front matter text cannot be stored in WYSIWYG mode so that we will save the raw front-matter text internally.(In next version, it can be stored in our WYSIWYG model.)

Additional, We consider only the yaml format as below.

---
title: title
---

Thank you!

[js87zz]

@derek-knox We added frontMatter option(#1171) and release it in v2.4.0.

I will explain about a few things as below.

• The front matter is supported by configuring the option because there are a lot of related layer to make it hard to separate as plugin. Also, since it is not an official specification of commonmark, we decide that it is better to provide it as an option like gfm.
• The front matter is parsed into the paragraph with customType prop using our custom parser.
• It is hidden in the markdown preview or viewer mode.
• We decided to show the front matter in WYSIWYG. This is different from what I said before, for the following reasons. The purpose of our editor is the synchronization between Markdown and WYSIWYG. Therefore, if it is editable in Markdown, it should also be editable in WYSIWYG as below. You can have a question that WYSIWYG should provide a different format for editing front matter, but we think it is something that needs to be planned and solved later.
• What you wanted at first was to prevent to edit the front matters in WYSIWYG. This can be solved through the following example code.

const editor = new Editor({
  el: document.querySelector('#editor'),
  // ...
  // configure front matter option
  frontMatter: true,
  customHTMLRenderer: {
    paragraph(node, { origin, options }) {
      const { customProp = {} } = options;
      const showFrontMatter = customProp.showFrontMatter && node.customType;
      const attributes = {};

      // prevent to edit the front matter in WYSIWYG
      if (showFrontMatter) {
        attributes.contenteditable = false ;
      }
      return { ...origin(), attributes };
    },
  }
});

Additionally, there are some issues that cannot be implemented in our current structure such as markdown custom syntax and exact synchronization between WYSIWYG and Markdown. And front matter option needs supplement(syntax highlighting, internal logic for switching to WYSIWYG). To solve these problems, we are currently planning to rebuild the editor completely in the next major version and are already in progress. I will register the related information on next week, so if you are interested, please give me your opinion! Thank you 😃