How to prevent browser from inserting HTML into a contenteditable element

Asked 17/1, 2014 at 0:58 Answered 17/1, 2014 at 1:38

When a user inserts linebreaks in a contenteditable element, browsers insert HTML into the element.

Here is what you get when you hit [Enter] in various browsers:

IE:      <p></p>
Chrome:  <div><br></div>
Safari:  <div><br></div>
Firefox: <br />
Opera:   <br />

(Test for yourself with this JSFiddle demo.)

Is there a way to get the browser NOT to insert HTML when the user hasn't inserted any HTML? Of course, I could just use

<textarea></textarea>

...and that does behave very similar to how I want, however, I don't want a strictly "text-only" input, as I will be adding and modifying HTML in the editable element using Javascript.

I considered constantly stripping all HTML out as the user types, only allowing HTML with a special class that I create to remain. That doesn't seem like a great solution, however. Is there something like wrap='soft' or some other way to say "stop making up HTML and putting it in my element!"

Gratification answered 17/1, 2014 at 0:58 Comment(0)

If you make it content editable, you are implicitly allowing the user to change the content of the HTML.

Pressing return should insert some kind of newline - either as closing a paragraph () and starting a new one (), or entering a line break ( ). Both of which in HTML require HTML tags, for the simple fact that a standard newline character (eg. \n or \n\r) is rendered as a single space, which is not what the user would expect - so inserting a raw newline as a "soft wrap" would not make sense and will ultimately lead to users impotently slamming their enter key getting mad at your site for not inserting a break when they think it should.

An even more fun fact is that if a user highlights some text, they can (or should) be able to bold and italicize text using keyboard shortcuts, which will again insert HTML.

Short of writing Javascript to override this behaviour, I am not sure you can disable the enter key inserting HTML tags to render the requested newlines.

To demonstrate this, here is a really simple page:

<html>
<body>
<div contentEditable="true"> Some things.</div>
</body>
</html>

(In Internet Explorer at least) If you double click on the text it becomes editable. Move to the end of line and type the following:

Enter - ( A new paragaph is made (wrapping the prior text in p tags).
Type "Words", the select it and hit Crtl + b - the text is now wrapped in  tags.
Hit Shift + Enter - a line break ( ) is now inserted.
Type "More words", select it and hit Crtl + i Its now italicised in  tags.

And the source should look like:

<html>
<body>
<div contentEditable="true">
  <p>Some things.</p>
  <p>
    <strong>Words</strong>
    <br>
    <em>More words</em>
  </p>
</div>
</body>
</html>

If you want complete control over the content going into the area, I'd recommend using a WYSIWYG editor, or alternative, accept that the browser probably knows what its doing and let it do its thing so you don't need to worry about it.

Impatience answered 17/1, 2014 at 1:13 Comment(1)

Heh heh, thing is, I'm building a WYSIWYG editor... sort of. I don't actually mind user-inserted HTML in most cases, so long as it is intentional (As in your example). The reason [Enter] causing HTML bothers me is because it's incredibly difficult to remember not to hit [Enter], and because it is inconsistent between browsers. – Gratification 17/1, 2014 at 1:56

There is no cross-browser way of disabling or forcing an editable div to interpret enter keypress differently from what the browser intended.

Besides, different browsers will do different things with the new line. Some will wrap lines inside  tags, some will add  .

The idea is that it's the browser that controls the editable div, not you.
If you try to fiddle with the output in real time, you will be like a passenger occasionally trying to snatch the wheel from the driver's hands.

You're not even guaranteed to get the key events from such a div. For instance, your fiddle does not seem to work in IE11.

I would rather do it just like this very SO editor does: use a textarea for user input and generate whatever rich HTML you want in another, non-editable div.

Armenian answered 17/1, 2014 at 1:38 Comment(4)

Not really true. You can successfully intercept keypresses and insert your own content in all mainstream browsers. – Fictional 17/1, 2014 at 9:26

Yes you can, just as you can barely manage to stay on track while snatching the wheel from the driver's hands :). – Armenian 17/1, 2014 at 11:17

OK, I don't disagree that the default browser behaviour is variable and replacing it with your own is tricky to get right. However, it is always possible to get key events and do your own thing instead. – Fictional 17/1, 2014 at 11:38

@TimDown Well the OP said he considered wiping the  s off the div contents a bit messy. Trying to do a cross-browser intercept of the enter key will be even messier,IMHO. – Armenian 17/1, 2014 at 13:17

Recommended topics

Hot tags