Re: [w3c/editing] Should contenteditable=plaintext-only be standardized? (#162)

@edgarascom I can only find it by using Internet archive.
https://web.archive.org/web/20191003035115/https://w3c.github.io/editing/contentEditable.html

But I was specifically referring to the `contentEditable` states. In the linked draft there are 4 new states: `events`, `caret`, `typing` and `plaintext-only`.

Since I'm currently working on a rich text editor I'll explain a little bit what are the pain points I'm encountering.

When using `contentEditable=true`, each browser has the freedom of choosing how to render some things that are not specified in the specification. For example, there are different elements in different browsers to display bold text, different fonts, new lines, etc. And also there seem to be differences in what each browser supports.

Because of this, we, the developers can't rely on the representation of the text/document of the DOM. Accounting for all of the differences is way too hard and results in too much boilerplate code. And on the web, every byte counts, more so when its JS because it needs to be parsed and executed. And text editors do a lot of stuff behind the scenes, so making a rich text editor work fast(60fps) on mobile devices is very hard when taking all of this into account.

There are two kinds of rich text editors on the web right now, the ones that gave up, and just try to parse the DOM representation into something good enough, and the ones that try to build all the logic from zero, and use the DOM just to render the output.

I choose the second path because I wanted to control exactly how things are rendered. And I want the source of truth to be controlled by my app.

I thought about rendering using canvas. But then you need to create a caret that will work on all devices and look and feel native, and also create copy/paste functionality, and edit menus that will look native, and on mobile it's practically impossible.

Your only option is to use `contentEditable` because there is no other text input that allows you to manipulate how the text looks, and insert other elements/styles while taking care of caret/commands/menus.

A good solution would be to make an input that takes care of text editing part of things, but let us decide how to render everything. So all events are passed to us, and there is no default functionality at all. So if the user hits the "bold" button on the native menu, an event will be dispatched, but nothing will happen. the same should be true for character insertions, deletions, pasting etc.

Another missing feature is to tell the OS which actions the editor supports. For example on iPhone, if you have text selected inside a content editable "input", then the OS will show a menu with "bold", "italic", "undo", "copy" etc. But what if the editor doesn't support "bold"? we should have a way of specifying that too.

I think that the draft I linked to offers good solutions for some of these problems. And it should be higher priority. I actually think that it needs to be the highest priority. Rich content is literally the essence of the web, and its time to fix how its created.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/162#issuecomment-615941294