Yet another developer writing a rich text editor

Back in 2012, when I discovered the possibilities of having a rich text input by simply adding the contenteditable=true attribute to my element, I tried to build a full content editor. I didn’t know the purpose of it at that point in time, however, it was nice to dig into these new possibilities. I remember it was a simple editor, although you could drop files and images into it, and it would automatically upload the files and attach them to the editor area. Expand the image previews as well. Furthermore, it also embedded content from Youtube and other platforms. It was a lot of fun. It was a lot of o hacks and workarounds as well. Not any longer after that, I sent this idea to the cemetery of side projects.

Later in 2017, I decided to give another shot and to play with it a bit only on codepen. Back then, the idea was to create a writing editor, collaborative, where people could share the whole document or just parts of it. My approach this time wasn’t ideal since the beginning and I realized that I’d need to invest in something different. Again, left this idea aside.

Here we go again

However nowadays, that I have this feeling urging that I need to build something, I’ve decided to review that idea and build something with a different goal and scope. So far, the project aims to be a collaborative note-taking app. My goal is to create a great experience for writing there, such as that it can be used for something else. It’s a block editor. Not as complex and complete as this one from WordPress, but still with all the main functionality It’s really challenging to build it.

I’m aware that contenteditable isn’t a simple thing to work with. Especially because every browser implements it differently. Moreover, the document.execCommand isn’t the most indicated method to format the content. Recently this year, it was considered obsolete and its use discouraged. This turns this building process even more challenging.

I’m well-read of Why ContentEditable is Terrible and Content-Editable – the good, the bad and the ugly also took a look at some rich text editors that don’t use execCommand, Trix Editor, from Basecamp, the QuillJS and the Guttenberg project from WP. QuillJS and the editor from Guttenberg were hard for me to follow since they have their own implementation that reflects the DOM. Similar to what Google Docs, as far as I understood. The Trix editor, I could only find it source code in CoffeeScript, which I’m not familiar with, but it was helpful also somehow.

How do you like your formatting toolbar?

Anyway, I’ve decided to leave that part behind as of now and focus on having something working. I’m currently facing a design dilemma that I want to share. At first, I thought that having the formatting bar close to the text I’m typing would be more convenient, but the results are not as practical as in the theory. I want to have a mouse-free editor, where the writer don’t need to leave the keyboard to add any formatting. I thought about using markdown to do it, but it’s not suitable for everyone.

This is an example of inline formatting.

I didn’t like the results of the inline formatting bar and decided to create an alternative version, using the more common contextual formatting bar above the editor. Although now, the eye focus changes from the text to the top bar when applying text format. My feeling is that this can be overcome by using shortcuts, the same as the regular editors do.

iOS Safari doesn’t help

Something to note, also, is that the inline formatting toolbar wouldn’t look great on mobile. On iOS, for example, the os adds its own inline formatting toolbar, which makes the experience sub-optimal – you have two inline formatting toolbar fighting against each other. Besides, the selection fragment has an index position higher than the document. So it also happens that the selection is going to be displayed on top of the formatting bar.

Another problem on mobile, especially iOS, is that I cannot position the formatting bar just above the soft-keyboard. There’s no maintainable way of doing it. I don’t have the keyboard height, it doesn’t change the viewport and hence doesn’t trigger onresize event, and, well, the StackOverflow is full of topics discussing this marvelous implementation from Apple.

That said, the only reasonable way that I found to display the formatting bar on mobile, was to keep it on top of the page. It’s not ideal, but it would work. What happens is that, on mobile, you need to take your attention from the keyboard anyway, to select the text. At this moment, I can expect the writer to select one format option from the top bar without losing focus.

Below there’s the editor on focus mode. The design follows the mobile implementation (vice-versa) and I can give the same experience on both devices.

This discussion seems trivial, but it’s not. If I cannot give a great writing experience to the writer, there’s no point to discuss the technologies I’m going to use. I’m facing a lot of other challenges to make this work, in special implementing its own Undo/Redo strategy and setting the caret position to the editor.

As soon as I overcome any other challenge, I’m going to take some time to write it down here again.

Published by Daniel Salvagni

A Brazilian front-end developer currently based in Berlin.

Leave a comment

Leave a Reply

%d bloggers like this: