knossos
knossos copied to clipboard
modrinth
Adopt vue-codemirror for Markdown textareas
Because it makes sense for Markdown to have syntax highlighting. More intuitive editing, etc
honestly a lot of this could be solved by just not using CodeMirror and rewriting it from scratch. CodeMirror (or maybe just vue-codemirror?) is really weird to work with anyway and i don't think it would be too hard to recreate something similar/better with better performance and UX.
Initially I talked about using the VS Code editor Monaco as a joke, but as it turns out, Monaco has a lesser bundle size than Codemirror. Monaco is more up to date with newer technologies and also is actively used in VS Code, so I think this could be an alternative.
The Monaco Editor is generated straight from VS Code's sources with some shims around services the code needs to make it run in a web browser outside of its home.
As it turns out Monaco isn't supported on mobile. But it works on mobile though
It looks like mobile support for Monaco has improved over time, but it's still a bit clunky. Some workarounds can be done to make it more accessible.
Disclaimer: I'm not familiar with the
cssclasses.I added the
divattributecontenteditable = "true"to alldivs withclass="view-lines monaco-mouse-cursor-text". Then the text selection and cursor placement were much better! (on my iPhone and iPad)Now I don't know where to add this attribute in this repository.
Note: I copied part of this website and modified the html directly
https://github.com/microsoft/monaco-editor/issues/246#issuecomment-997437826
That issue includes some recommendations like switching to a different editor for mobile support. Monaco seems like a possible alternative to codemirror w/ some adjustments.
The codemirror editor doesn't add much in terms of UX, besides line numbers (are line numbers really that helpful for markdown?) and syntax highlighting. However, the text editing experience is worse in some cases, like with horizontal scroll on long lines of text.
What it also adds is proper/better monospaced font usage, which people like me desperately need as stuff like tables look worse with non-monospaced font used. I'm personally also a fan of Syntax highlighting here. It also helps finding possible typos, or cases where markdown would render text in a way you don't want.
The horizontal scroll thing is... something I guess? Never encountered it so far so Idk what it is about. Also, there are IMO way worse things that need addressing here, like that you can't resize the text field and instead have to scroll to X lines of text which is frustrating to say the least.
If you with horizontal scroll mean that text goes beyond the text box's with and you have to shift+scroll to get to it... Why not make it auto-linebreak when it reaches the end of the text field? Line numbers would in this case help see if a line is still part of the same line or not.
The CodeMirror library makes up about 14% of the final bundle, which is huge for a small portion of the site. The CSS also adds a lot for maintainability (colors, so if we change theme colors, there's a lot to change).
I mean, this stuff can be reused for feature things such as comments/reviews when they would be implemented. Not to mention are release notes also benefiting from this stuff.
Overall, I think GitHub is a good reference for what a Markdown editor should be like, and they don't have/need syntax highlighting. I would be open to adding features like a header, bold, italic, codeblock, and other buttons.
I would agree on the button stuff. Would help a lot. Tho GitHub isn't the best source to look at. They do have code highlighting, tho only for markdown files in a repository and also a lot more subtle, but it is there.
I again can't see a big issue with the code highlighting here. It can help a person understand how a text may get formatted, which is easier than looking at same-coloured text and try to figure out why line X is showing so weirdly.
Those are just my points to.
I sent this in discord too, but @Andre601, most of the issues solved by the codemirror PR that you said can be done in the current textarea with some styling. (like adding a monospaced font and making it auto-resize/be user-resizable).
I'm personally also a fan of Syntax highlighting here. It also helps finding possible typos, or cases where markdown would render text in a way you don't want.
I actually don't think this is the case, as both can be achieved by using the preview. While possible typos is a small benefit, it can also be done right now using the preview.
If you with horizontal scroll mean that text goes beyond the text box's with and you have to shift+scroll to get to it... Why not make it auto-linebreak when it reaches the end of the text field? Line numbers would in this case help see if a line is still part of the same line or not.
These two points are contradicting. If the codemirror editor wraps when the lines overflow, the line numbers will no longer be useful. Currently, what the editor does is not wrap the lines and make the user horizontal scroll to see long lines of text. I believe this is worse UX (linters force code to wrap at 80 spaces for this reason too!, to avoid horizontal scrolling). Because of that, I don't think the line numbers would ever be useful.
The best way to see what line is part of what line in markdown is to look at the preview. The editor doesn't really solve that either. The preview does though, and that hasn't changed.
I mean, this stuff can be reused for feature things such as comments/reviews when they would be implemented. Not to mention are release notes also benefiting from this stuff.
That's a total of 2 places on the site (since the project creation is being removed), which will have a slightly better markdown editor experience.
I again can't see a big issue with the code highlighting here. It can help a person understand how a text may get formatted, which is easier than looking at same-coloured text and try to figure out why line X is showing so weirdly.
Like I said earlier, you don't really understand how the text gets formatted from syntax highlighting. You understand it with the preview and looking at the markdown guide. The costs are to maintainability of the repo and load times to users. This PR makes a lot harder to edit themes/add one due to way more colors. It's bundle size is big (a text editor should not be bigger than every page on the site). It also doesn't integrate with SSR.
Like I said earlier, you don't really understand how the text gets formatted from syntax highlighting. You understand it with the preview and looking at the markdown guide.
Personally when I edit Markdown I rarely look at the preview tab if syntax highlighting is present because it tells very clearly what the styling would be even if it isn’t presented in the preview. For GitHub, I do look at the preview tab because I’m not sure if I’ve made a typo or anything, since there is no syntax highlighting.
I actually don't think this is the case, as both can be achieved by using the preview. While possible typos is a small benefit, it can also be done right now using the preview.
btw, why not make it optionally side by side? that makes for an easier preview experience
I'm also a fan of syntax highlighting, yeah you can see the results with the preview tab, but constantly switching tabs to see if it works or not for people inexperienced with markdown is annoying. And it does make seeing errors way nicer and quicker. Though, if there was an option to have the viewer split (and make the card width wide enough so that the text boxes aren't too thin), that would also alleviated it.
As for the size, is it not possible to only send it when you visit the pages where it's used?
As for the size, is it not possible to only send it when you visit the pages where it's used?
It is only sent on used pages, but the editor is a significant chunk of the bundle of that page.
Closing since this is very outdated and probably abandoned. If it were to be reopened it would need to be completely redone anyway. Adding some sort of markdown editor improvements are on Prospector's radar, though.
