Gitea: Replace EasyMDE with textarea

[silverwind]

SimpleMDE is unmaintained and in my opionion very bloated for what it does. It ships with a full version of CodeMirror (a code editor) embedded which enables markdown syntax highlight in the editor, but I think its a neglible feature that is mostly unnecessary as comments are meant to be viewed in rendered mode primarily.

I suggest we switch to a plain <textarea> like the ones Github and Gogs use. Some buttons to insert pre-generated snippets at the cursor can be provided. Emoji can be supported via :token: to Unicode replacement or directly as Unicode as always. Image-based custom emoji can not render in it, but they may in the rendered view (thought Unicode should be preferred).

[jolheiser]

I personally love this idea, I always end up turning it off immediately.
That being said, I think many users enjoy the WYSIWYG.

If we had a toolbar similar to GH that injected symbols (e.g. bold would wrap your cursor with ****) perhaps that would be a good trade-off?
I'm unsure about removing a feature unless we have a good alternative.

[silverwind]

Yes of course, formatting buttons must be provided for a viable alternative. Also, @mentions and :emoji have to work. I wonder if there is maybe a JS library around that can provide markdown-formatting functionality to a <textarea>, or if we have to code those up ourselves.

I think it may be beneficial to first do the transition to unicode emoji (which means replacing emojify.js with something that emits proper unicode instead of images, except on custom emoji).

[bobemoe]

I did a review of several WYSIWYG markdown editors over in https://github.com/go-gitea/gitea/issues/9619 and found Ace was beginning to look promising as it was also being considered for the code editor.

I'm afraid I didn't find time to continue with it but it may be worth checking out from https://github.com/go-gitea/gitea/issues/9619#issuecomment-578486731 onwards

I would be happy with plain <textarea> too, but also agree some of my colleagues would prefer (basic) WYSIWYG.

[silverwind]

I think WYSIWYG goes against the spirit of Markdown, which is meant to be edited in plaintext.

[bobemoe]

Yeah, you're right. Something simple like this GitHub editor would be perfect.

[silverwind]

Indeed, GH's one is quite nice. It's just a lightweight textarea with a few formatting/snippets buttons. I guess such functionality can be replicated in like 5-10kB of JS.

[guillep2k]

We need to keep in sight that many Gitea end users are not programmers (e.g. someone who reports a bug on an end-user product), so I think WYSIWYG is important as an option.

[silverwind]

I don't think Markdown is hard to learn and with the formatting buttons offered, it should become clear how it works pretty fast. GitHub never offered Markdown WYSIWYG and I think it's just silly if we would do so.

[lunny]

@silverwind We could make that as a user level options. :)

[suli3]

Most of the un-programmers are familiar with office, what they want to do is copy doc words to the issue and hope that these words could be as shown in the office.

[silverwind]

copy doc words

Markdown only supports a small subset of what is possible in such documents (colors, font face, exact font sizes, underline, background color and many more). Those users would be better off just attaching said document.

[silverwind]

https://github.com/patrickfatrick/marky-marked might be a alternative, it's 12.2kB gzipped. The only thing I don't like is that it relies on FontAwesome, but I guess we replace icons with SVG.

[SuperSandro2000]

We could make that as a user level options. :)

For me this sounds like feature creep. MD is perfectly fine for a issue board.

[lafriks]

Or this one https://github.com/nhn/tui.editor, I don't know how big this one is tho

[mrsdizzie]

https://github.com/github/markdown-toolbar-element : )

[lafriks]

While for comments I agree that we would need just toolbar but for markdown editor (wiki & markdown files) we need something better :)

[silverwind]

@toast-ui/editor is heavyweight, even more so than simplemde, but I guess for the "full" editor, it might not matter.

https://bundlephobia.com/result?p=@toast-ui/editor@2.2.0
https://bundlephobia.com/result?p=@github/markdown[email protected]
https://bundlephobia.com/[email protected]
https://bundlephobia.com/[email protected]
https://bundlephobia.com/[email protected]

[igalic]

does any of these suggested editors not exhibit the same input bugs (on mobile browsers) as SimpleMDE? (https://github.com/go-gitea/gitea/issues/11352)

cuz my understanding (from that other bug at least) is that that's the reason to replace it

[lafriks]

Toast UI editor demo was working just fine for me on android phone

[bobemoe]

The lack of spell checker was my main issue with SimpleMDE (https://github.com/go-gitea/gitea/issues/9619)

[lafriks]

We could also use EasyMDE (fork of SimpleMDE) https://github.com/Ionaru/easy-markdown-editor/
Just checked it does work better on mobile but also has some issues: https://github.com/Ionaru/easy-markdown-editor/issues/77
Also text selection on mobile does not seem to work

[silverwind]

I'm still in favor of a simple textarea (possibly with a live preview) with formatting buttons on top which is just the best in terms of accessibility and compatibilty and GitHub also does exactly that and it seems to work for them.

Toast UI looks to be architured similar to SimpleMDE with CodeMirror under the hood and after opening https://ui.toast.com/tui-editor/ and clicking the "All Extensions" tab, I already see a bug where the preview area is rendered incorrectly in Firefox, so it's rather off-putting.

[mrsdizzie]

I agree with @silverwind -- I have to turn the current editor off completely because it is a bad overall experience (I've heard other devs who do the same). Anything that breaks built in spell check and correction feels like it should be a total non-starter for any text editing and that seems to apply to most of these various 'mde' type projects.

The Github package seems to offer almost everything people are asking for (many built in shortcuts for adding various markdown elements), is accessible by default, doesn't break spell check, and has a clear future of being maintained -- which seems to be an issue for several of the javascript dependencies we've adopted in the past:

https://github.com/github/markdown-toolbar-element

Also fwiw I think the textarea with a preview tab model does count as WYSIWYG generally as you are able to easily see exactly what the final output will look like on each adjustment before publishing.

[a1012112796]

Hmm, It's meaningfull, But please do something to keep SimpleMDEImagePaste or similar thing which is verry usefull when adding Image, Thanks

[igalic]

I agree with @silverwind -- I have to turn the current editor off completely because it is a bad overall experience

how???

[mrsdizzie]

@igalic

[silverwind]

Hmm, It's meaningfull, But please do something to keep SimpleMDEImagePaste or similar thing which is verry usefull when adding Image, Thanks

Yes of course, image pasting has to work. It's actually rather simple to do in vanilla JS.

markdown-toolbar-element looks quite nice. It does not ship icons so we can integrate our own.

[CL-Jeremy]

Emoji can be supported via :token: to Unicode replacement or directly as Unicode as always. Image-based custom emoji can not render in it, but they may in the rendered view (thought Unicode should be preferred).

Good to see this already works with emoji.js

I've started some very crude work on porting Twemoji to support older platforms (probably as a non-mainline patchset): https://github.com/CL-Jeremy/gitea/commit/5e843a9a3d6735f6c38376098bed81dc8017202d

Tested on IE 11/Windows 7, Chrome Dev 44/Android 4.2.2, Firefox 38, Firefox 45. They basically look exactly the same as latest Firefox on Windows 7 after https://github.com/go-gitea/gitea/pull/12522 gets merged.

The remaining task is to either intercept the data from API (in index.js) or directly add some sort of cookie-based mechanism in backend like GitLab does, so dynamic content (reactions, markdown) works. The emoji popup is working already as is. For those on Windows and non-standard Linux distros, this could be a fallback in favor of removing static Noto Color Emoji (which is already outdated as of now).

[silverwind]

Are you restoring image-based emoji? I don't think we should ever go back to those and I'd rather like to stay fully unicode-based and drop the one image emoji. This is also where GitHub is heading. In 1.13 we specifically limited the supported browser browser list to not support ancient browsers.

[CL-Jeremy]

Yes I am. If you are talking about emojify.js, those lack a lot of features like skin tones. Twemoji is feature-complete, free (emojify.js used Apple's design), remains up to date and is hosted on a global CDN network without bloating local resources.

I actually visited the commit and read this:

Not included here are image fall back URLS. I don't really think they are necessary for anything new being written in 2020. However, managing the emoji ourselves would allow us to add these as a feature later on if it seems necessary.

I completely understand and respect your decision and concerns. IE is still broken in many regards and I only included some of the fixes in my branch to facilitate testing (like babelizing escape-goat and polyfilling Array.from/Map.values). I'm personally for better compatibility (seeing how other platforms still at least render half-well on older platforms) but without active maintenance (while allowing voluntary patches, as long as they don't add too much burden). I take image fallback as a viable solution since it almost only deals with displaying UI with minimal user interaction, so features could hardly break here. It's also a solution to vendoring static Noto Color Emoji.

[silverwind]

What is Twemoji exactly? Image fallback or unicode font?

[CL-Jeremy]

What is Twemoji exactly? Image fallback or unicode font?

Both. It's like EmojiOne and all those fonts, which are built into various formats, but this one is used in production and yet freely available. It's what Twitter is still using in 2020 (for obvious reasons).

What's special about those is that recent Firefox ships with them (early Firefox ships with EmojiOne) as a built-in TTF file (called Twemoji Mozilla), so Firefox automatically falls back to them (that's why I suggested explicitly adding it to the font stack to prioritize it over DejaVu Sans/Segoe UI Symbol or some Japanese JIS-compatible fonts). So almost all Gecko/Servo browsers have no need for web fonts whatsoever.

It's also made freely available by Twitter as PNG and SVG images with URLs mapped right to their code points, hosted on GitHub via CDN. I'm using those in the above mentioned branch opportunistically with less than 10 lines of code.

[silverwind]

Unicode font is fine with me and this does sound like a better alternative then the heavyweight Noto. Image fallback should not be in the mainline repo thought. I guess one could do a customization to run a replacement script to support really old clients with fallback images, but browsers like IE11 are already in a rather broken state since 1.12 and we dropped support for them in 1.13.

[CL-Jeremy]

It's also possible to fall back at per-glyph basis, so missing glyphs could still be rendered as images. Aesthetically less appealing though.

I guess one could do a customization to run a replacement script to support really old clients with fallback images, but browsers like IE11 are already in a rather broken state since 1.12 and we dropped support for them in 1.13.

I'll investigate that. I haven't found a way to customize in depth and I don't think it's possible without something like DOMObserver which is just too costly to implement.

[lafriks]

Another good alternative imho could be:
https://prosemirror.net/examples/markdown/

[igalic]

and it doesn't create word and letter duplication or deletion! wow!

[silverwind]

Not sure it's suitable because our preview must be server-rendered.