Should contenteditable=plaintext-only be standardized?

[xiaochengh]

This is a blocking issue of removing webkit-user-modify from Blink.

There seems to be an important use case of contenteditable=plaintext-only in Chrome DevTools:

In the "Elements" panel, we can modify a tag (tag name, style, class and other attributes) by doubleclicking at the tag, which turns certain part of the tag plaintext editable (as shown by the attachment ). When we finish editing, we can click outside or press Esc to switch the editable part back to uneditable.

DevTools currently implements this functionality by making certain element switch between "-webkit-user-modify: read-only" and "-webkit-user-modify: read-write-plaintext-only". There doesn't seem to be an easy way to convert the implementation to follow the standards, as the standards do not provide any means for plaintext editing other than and .</p> <p>If contenteditable=plaintext-only can be standardized, then the above use case can be well supported.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/johanneswilm"><img src="https://avatars.githubusercontent.com/u/595512?v=4" />johanneswilm</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>Good point. What do you propose concretely in terms of standardizing? Would a mentioning among the types of available contenteditable types [1] together with some prose about how it "only allows for the input of plaintext and ignores any formatting commands" be enough to start with, or should we also define some more of the behavior, possible standardize differences between existign implementations?</p> <p>[1] <a href="http://w3c.github.io/editing/contentEditable.html#editing-states">http://w3c.github.io/editing/contentEditable.html#editing-states</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/xiaochengh"><img src="https://avatars.githubusercontent.com/u/19384155?v=4" />xiaochengh</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>A brief mentioning seems good enough. I don't see any need to make it lengthy.</p> <p>Btw, it should also ignore any format in pasted/dropped text.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/ojanvafai"><img src="https://avatars.githubusercontent.com/u/1607171?v=4" />ojanvafai</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>contentEdtiable=plaintext-only is used a fair bit, so I think the only choice available is to standardize it. We had previously discussed this with other browser vendors. IIRC, there was general support, but there were some open questions that never ended up getting resolved.</p> <ol> <li>When you hit enter, does it insert a \n like textarea, or a <code><br>, <div>, <p></code> like contentEditable? Should it depend on your white-space value? Browsers are pretty inconsistent here with regular contentEditable.</li> <li>We'll also need to specify what it means to "only allow input of plaintext." For example, pasting/dropping in rich content needs to be plain-textified.</li> <li>We'll need to be clear on what it means to ignore a formatting command. For example, it should include that things like ctrl+b shouldn't fire the beforeInput/input events.</li> </ol> <p>In either case, I think speccing something and having unresolved notes in the spec for the above three issues is better than having nothing.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/gked"><img src="https://avatars.githubusercontent.com/u/12704474?v=4" />gked</a> commented <strong> 7 years ago</strong> </div> <div class="markdown-body"> <p>+1.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/tabatkins"><img src="https://avatars.githubusercontent.com/u/682840?v=4" />tabatkins</a> commented <strong> 6 years ago</strong> </div> <div class="markdown-body"> <p>Just ran into this (thanks for teaching me that <code>plaintext-only</code> exists!), because I'm doing a <code><style contenteditable style="display:block"></code> to make some "editable CSS" for a talk, and it was inserting markup into the <code><style></code> and messing things up when I pressed Enter. Our current behavior for <code>plaintext-only</code> is to insert a <code>\n</code>, which is exactly what I needed, yay!</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/samuelgozi"><img src="https://avatars.githubusercontent.com/u/470577?v=4" />samuelgozi</a> commented <strong> 5 years ago</strong> </div> <div class="markdown-body"> <p>I tested this on safari, and it seems that they insert <code><br></code> on enter instead of <code>\n</code>. I think this definitely needs to be standardized, and it seems like it's in the process, but it seems like its not a high priority and thats a shame, since content editors are the core of the web, and every single one of them could be improved by this draft: <a href="https://w3c.github.io/editing/contentEditable.html">https://w3c.github.io/editing/contentEditable.html</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/edgarasben"><img src="https://avatars.githubusercontent.com/u/725324?v=4" />edgarasben</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@samuelgozi seems like the link is broken ;/</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/samuelgozi"><img src="https://avatars.githubusercontent.com/u/470577?v=4" />samuelgozi</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@edgarascom I can only find it by using Internet archive. <a href="https://web.archive.org/web/20191003035115/https://w3c.github.io/editing/contentEditable.html">https://web.archive.org/web/20191003035115/https://w3c.github.io/editing/contentEditable.html</a></p> <p>But I was specifically referring to the <code>contentEditable</code> states. In the linked draft there are 4 new states: <code>events</code>, <code>caret</code>, <code>typing</code> and <code>plaintext-only</code>.</p> <p>Since I'm currently working on a rich text editor I'll explain a little bit what are the pain points I'm encountering.</p> <p>When using <code>contentEditable=true</code>, 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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Your only option is to use <code>contentEditable</code> 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.</p> <p>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.</p> <p>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.</p> <p>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.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/johanneswilm"><img src="https://avatars.githubusercontent.com/u/595512?v=4" />johanneswilm</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>Hey, yes so 3 of the states in that draft were made for editors as the one you describe @samuelgozi . The reason we had 3 and not just 1 was that IME and some other features like mobile browsing meant that it was difficult for us to choose just one of those states and so we kept all three for now. The last one, <code>plaintext-only</code>, could possibly also be used as part of a general editor, but it was really invented by Safari/Chrome to be used by their browser native tools for web developers like the "edit as HTML" feature. So if I recall correctly we left that one alone for the time being as it's being might be dictated by the needs of the browser-specific development consoles and cannot be adjusted to work well in other contexts.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/samuelgozi"><img src="https://avatars.githubusercontent.com/u/470577?v=4" />samuelgozi</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@johanneswilm Thanks for replying and for the clarification. Where can I find the current state of these proposals?</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/edgarasben"><img src="https://avatars.githubusercontent.com/u/725324?v=4" />edgarasben</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@johanneswilm I also would use plaintext-only no only for a code, but also because I don't want formatted text/pictures to be pasted into the area. Is there another easy way to prevent pasting any mismatching text style? </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/johanneswilm"><img src="https://avatars.githubusercontent.com/u/595512?v=4" />johanneswilm</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@samuelgozi We are now part of a new Working Group which no longer allows us to have documents here that do not yet have implementation insurances from browser makers in our main repository. We are now only allowed to have these sit in pull requests. For this reason, everything was removed in this pull request: <a href="https://github.com/w3c/contentEditable/commit/ae454fc84c784cd507a1e2f9a226d01f7ac519d4">https://github.com/w3c/contentEditable/commit/ae454fc84c784cd507a1e2f9a226d01f7ac519d4</a></p> <p>The document before that PR still represents the current state of the discussion though, so if we can get implementation commitments, we may put them back some time in the future.</p> <p>The existence of plaintext-only has been moved to the HTML spec. It does not specify anything about its behavior though.</p> <p>@edgarascom What you describe sounds like something we wanted to enable with input events in combination with really any of the contenteditable states. Unfortunately also those were only half-implemented. As I said, I am not sure if we can get browser makers to agree on specific behavior for plaintext-only, because that would then mean that they would also need to change how their development tools work. But maybe it is possible. </p> <p>In the meantime, what you can do given the current state of things, if you need to write an editor right now, is to use a contenteditable element like this:</p> <ul> <li> <p>Use a schema system and keep a copy of the document that is being edited in JavaScript.</p> </li> <li> <p>Translate that document to HTML and put that HTML as the innerHTML of the contenteditable element.</p> </li> <li> <p>With every user initated change to the contents of the contenteditable element, translate the current HTML of that element back to the format that you have the document stored in Javascript in.</p> </li> <li> <p>Diff the old and the new document, find out what has changed, store that change.</p> </li> <li> <p>Translate the new document back to HTML, see if there is any difference to the innerHTML of the contenteditable element, and if that is the case diff and patch the contenteditable element.</p> </li> </ul> <p>Very roughly described, that should get you around all the various bugs and inconsistencies in browsers and it should work even when browsers change. However, I hope you are not planning on writing such an editor as a one-person hobby project during a week or two, as it has proven it takes years to get it right. For most use-cases it is probably currently recommendable to use one of the existing JavaScript libraries and not try to write a contenteditable editor from scratch.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/samuelgozi"><img src="https://avatars.githubusercontent.com/u/470577?v=4" />samuelgozi</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@johanneswilm Thank you very much for clearing that up.</p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/edgarasben"><img src="https://avatars.githubusercontent.com/u/725324?v=4" />edgarasben</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <p>@johanneswilm Thank you for the detailed explanation! </p> <p>That's what I was afraid of, to aim for something that will be very hard to finish for me alone, taking into account my intermediate coding skills. But what I am trying to code is quite simple, that's the reason I though I could use the contenteditable. It's a simple app as an internal strategic design tool. I want to be able to write sentences in a table cells. All the sentences from cells then gets mirrored and joined to a narrative story below using <span>s. And I want to be able to edit text in both places. Also later I want to add drag and drop functionality to reorder sentences if needed.</p> <p>So far it works quite well, but the problem was the copy/paste(able) rich text. Which I fixed with plaintext-only for now (but yeah, it has a super limited support). I will have to try your described method. Also, another problem is, if I edit a sentence in a <span> and delete all of it, the cursor jumps to top above all other sentences. I will have to do something with that, give a min-width somehow... But I need to keep it as an inline element.</p> <p>By the way what do you mean by "schema system"? </p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/johanneswilm"><img src="https://avatars.githubusercontent.com/u/595512?v=4" />johanneswilm</a> commented <strong> 4 years ago</strong> </div> <div class="markdown-body"> <blockquote> <p>By the way what do you mean by "schema system"?</p> </blockquote> <p>Basically just a register of how to translate the HTML into the format you store it in and vice versa. CKEditor 5 for example has this [1]. ProseMirror has this [2].</p> <p>[1] <a href="https://ckeditor.com/docs/ckeditor5/latest/framework/guides/deep-dive/schema.html">https://ckeditor.com/docs/ckeditor5/latest/framework/guides/deep-dive/schema.html</a></p> <p>[2] <a href="https://prosemirror.net/docs/ref/#model.Document_Schema">https://prosemirror.net/docs/ref/#model.Document_Schema</a></p> </div> </div> <div class="comment"> <div class="user"> <a rel="noreferrer nofollow" target="_blank" href="https://github.com/zcorpan"><img src="https://avatars.githubusercontent.com/u/244772?v=4" />zcorpan</a> commented <strong> 1 year ago</strong> </div> <div class="markdown-body"> <p>This was added in <a href="https://github.com/w3c/editing/pull/407">https://github.com/w3c/editing/pull/407</a> </p> </div> </div> <div class="page-bar-simple"> </div> <div class="footer"> <ul class="body"> <li>© <script> document.write(new Date().getFullYear()) </script> Githubissues.</li> <li>Githubissues is a development platform for aggregating issues.</li> </ul> </div> <script src="https://cdn.jsdelivr.net/npm/jquery@3.5.1/dist/jquery.min.js"></script> <script src="/githubissues/assets/js.js"></script> <script src="/githubissues/assets/markdown.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/highlight.min.js"></script> <script src="https://cdn.jsdelivr.net/gh/highlightjs/cdn-release@11.4.0/build/languages/go.min.js"></script> <script> hljs.highlightAll(); </script> </body> </html>