WYSIWYG Megathread

[connor]

Hi, we’ve been getting a lot of requests related to content editing lately, so I just wanted to centralize those here, as many of them will be added when we introduce our new WYSIWYG editor in (probably) version 1.6.

Cannot guarantee that the things asked for will necessarily be included, but new editing features will be much more tractable once that changeover has been made (and in some ways are therefore hard to comment on before the changeover).

Anyway, if you have anything you’d like to be included as part of the new editor, post it here. And if someone else makes a suggestion you like, don’t forget to like their comment to help us understand which ideas are generating the most interest!

[warum7]

When it comes to complex cards/documents sometimes highlighting in different colors comes in handy. It’s not neseccary at all, however still a nice to have feature.

[freisatz]

I would like the Markdown edit mode to use a monospace font. This is useful when coding tables, for instance. Plus, it is another visual indicator what edit mode you are currently in (wysiwyg would differ visually as it does not use a monospace font, obviously). Tbh, I didn’t think this through in respect to potential side effects.

[connor]

@warum7 Yep, definitely see the usefulness of this. Will need to figure out a good way to allow for this that works well alongside colored cards.

@freisatz In the WYSIWYG editor, code will be monospaced. We can also look into using a mono-spaced font for tables, as that makes sense. But yes, probably not monospaced for all content (even in edit mode).

[warum7]

@connor

Well I’d say the easiest way would be defining the same color values as of the card but either a bit darker or a bit lighter.
Or a more complex approach (I guess) would be disabling the color of the card at the position where a certian text is highlighted.

[kareldries]

• I guess there’s a lot of things you can pick up from Typora’s editor in general. The way it handles tables for example, where you can change the row order with Alt+ArrowKey Up/Down.
• Moving one or more lines of text up or down anywhere with a key combo would be useful as well.
• Quickly copy pasting code snippets to clipboard by means of an icon instead of selecting the code manually.

[tekacs]

Something that’s been on my mind since this thread came up is the portability (ideally as text) of whatever Supernotes’ editor ends up generating. In this regard the current markdown editor is practically perfect.

Are you able to comment at all on what the WYSIWYG editors results will be stored as (and exposed through the API as)?

A lot of WYSIWYG editors out there result in some kind of messy custom, not-super-semantic HTML output, with widespread disagreement on whether to nest tags or flatten them and use styles, etc. etc. — all of this results in output which is really hard to reverse engineer to get back to the semantic meaning of the author (compared to the current use of markdown which, whilst restricted in what it can do, is amazing at retaining the author’s intent). A few like Prosemirror have a WYSIWYM model which can be saved in place of HTML and then rendered to HTML, at least preserving some of the original intent.

For building a large library of notes, it’s super important (at least from my point of view) to have the ability to pull the notes out, manipulate them, etc. — so this is one of the closer topics to my heart (and why I find Evernote impractical to use for example — their notes are wildly un-portable and custom).

Would love to hear your thoughts on this and how you’re thinking about the resultant output.

[connor]

Absolutely, portability is very important.

Internally, the WYSIWYG editor’s data is stored as JSON. However, there will be options (both via the API and in the official frontend) to export/get your cards in Markdown/HTML format. The goal is for this to be as straightforward as possible, so you can view a markdown representation of a single card or get all your cards in MD at once. Obviously as more features are added to the editor, markdown will not be able to maintain feature parity in any meaningful sense, so the serialization process will result in some loss of meta. But for the basic content, we always want you to be able to get it in (at the very least) Markdown format.