Pure Elm rich text editor

Show and Tell
#1

I wrote a pure Elm rich text editor:
https://dkodaj.github.io/rte/

It differs from other pure Elm solutions I’ve seen (for example, jxxcarlson’s) in that it is not restricted to monospace fonts. It differs from mweiss’ package in that it requires virtually no javascript (cca. 20 lines are needed to connect to the clipboard and prevent some stuff).

Known limitations:
• it becomes sluggish around 10K characters and unusable by 50K (by then, it consumes 100MB of memory)
• it cannot justify text
• it cannot be the child of a position:relative node
• it uses a global onKeyDown subscription, so you must inactivate it when the user is typing into an inputbox or textarea
• unclear how it interacts with screen readers.

Comments welcome!

40 Likes
#2

Firstly, wow is it beautiful!

I did notice that when I disable editing that my highlight stays though.

But still, amazing!

#3

This is super cool! Amazing work!

One UI question: what is the “H” button supposed to do? In some cases it seems to make the text bold, in others it makes the text bold and much bigger.

And one more general point, re: global onKeyDown subscriptions. Firefox has a fantastically annoying feature that if you hit the ’ or / keys while you’re typing, it pops up a “Quick find” search box and diverts the rest of your input into the box. This is a bit of a problem for using your demo on Firefox at the moment.

I would dearly love to know how to override this Firefox feature, because it’s messed up my own previous attempts of building custom text inputs that listen to global onKeyDown subscriptions. Does anyone have any tips?

#4

It appears to be a toggle button for a Heading, I reckon bold and bigger is the correct functionality, and just bold is not (maybe a bug?). Probably shouldn’t be active inside the code block, for instance, but that’s just my take on it.

@dkodaj looks cool, are you planning to publish it as a package?

#5

Am looking forward to trying this out! Yess!!

#6

Thanks for the compliment! Also for noticing the bug; corrected.

#7

The ‘H’ button turns the paragraph into an h1 node. It does not work properly inside code blocks, because the code highlighter’s styles override it. I should probably disable it inside code blocks.

My Firefox (86.0, Ubuntu) does nothing if you type ‘/’ or ‘’’, but I’ve added preventdefaults to the html just in case.

Correction: the reason my Firefox does not open the quick search box is that I’ve disabled it in the settings. Preventdefaults don’t help here. Darn.

Re publishing it as a package: I have a nagging fear that it’s not production-ready (for example, I’m not sure how serious the performance issued I mentioned above are), but the plan is to turn it into a package sooner or later.

3 Likes
#8

Oh the side note, I am happy to see fellow philosopher among Elm folk :slight_smile:

#9

This is really pretty!

In terms of limitations, if you are looking to eventually achieve parity with contenteditable textarea capabilities, you can make a pretty good checklist from the pitfalls called out in this Medium article..

#10

Yess :smile: We can finally start discussing whether pure functions are conscious.

1 Like
#11

Thanks for the link, this checklist is very useful. I should definitely think more about tablet and mobile support.

Supporting Hiragana etc sounds unrealistic without having a Japanese keyboard and some knowledge of the language. So that’s a job for future generations I’m afraid.

#12

Wow, amazing work. Thank you for doing this.

#13

Great! Going to try this out in a current project. Will be posting an issues and fixes that I can. Cheers!

#14

I have read your blogpost about how you solve selection for this editor - very cool!

cc @brian this project might be up your alley - I remember our discussions about “Document” type :slight_smile:

#15

Great! Going to try this out in a current project. Will be posting an issues and fixes that I can.

Brilliant, let me know how it goes. Please note that the current version does not work in Firefox without turning off the “Search for text when you start typing” option.

#16

Did a similar thing for connection to selections as a custom element, as part of the work I did on text editing in Elm.

#17

I’ve added a hidden input box that stays focused when the user is typing, so Firefox’s quick search window should not appear regardless of browser settings.

1 Like
#18

This is really cool! I love torturing web text boxes, so don’t be too hard on me for trying to find the limits in yours.

First, I noticed that pasting emojis (go to a page like this one https://getemoji.com/ , and copy-paste any emoji into the text) tends to break. It works the first time, but on the second paste, 2 emojis appear, and if you try to select, cut and paste the 2 emojis, broken characters start to appear.

On the plus side, I really loved that “Page Up”, “Page Down”, “Start of line” and “End of line” keys all worked! Also, I had no problem inserting most special characters directly from the keyboard (even characters like †, although for some reason α didn’t work). Another really good thing is cutting a selection that goes across lines and formats. Works flawlessly.

All in all really cool project, I’ll look for an excuse to use it somewhere!

1 Like
#19

Great work! :heart:
This can open many doors.

#20

I noticed that pasting emojis (go to a page like this one https://getemoji.com/ , and copy-paste any emoji into the text) tends to break. It works the first time, but on the second paste, 2 emojis appear, and if you try to select, cut and paste the 2 emojis, broken characters start to appear.

It also seems to freeze if you put in 5 or 6 emojis and start deleting them. Thanks for noticing this interesting bug, I’ll see what I can do!