how to change behavior of contenteditable blocks after on enter pressed in various browsers

Question

When pressing enter in <div contenteditable="true"> </div> in firefox <br /> is produced - that's ok. But in Chrome or IE a new <div> or <p> is created. What should I do to make Chrome and IE behave like Firefox .

Answer 1

contenteditable is not a valid attribute for the div tag. It seems to be specific to Microsoft. I would avoid it, and replicate the functionality using Javascript.

var d = document.getElementById("myDiv");
d.onclick = function(){
  d.innerHTML = "<br />";
}

Or with jQuery,

$('#myDiv').click(function(){
  $(this).html('<br />');
});

This should give you more reliable results without having to use a browser/company specific attributes. Giving you more valid code too :)

Update

In which case I would reference this question, http://stackoverflow.com/questions/302122/jquery-event-keypress-which-key-was-pressed

And adjust the javascript to get the contents of the div, append a "
" and then repopulate it.

Answer 2

I believe that if the div already has a paragraph tag inside it, and the user presses return while focus is inside that paragraph tag, then Firefox will insert another one. So, if you have this:

<div contenteditable="true">
    <p>&nbsp;</p>
    <p>&nbsp;</p>
</div>

and you focus, the press return, Firefox will insert a third paragraph.

You might be able to get around having the & nbsp ; in the paragraph tags by giving them minimum heights, and you might be able to get away with having only one. I never got to the bottom of the behaviour to my satisfaction the last time I looked at this. You'll probably need some JavaScript to enforce a minimum of one paragraph tag inside the div.

Answer 3

The following will add a <br> when the enter key is pressed in all major browsers and attempts to place the caret directly after it. However, WebKit, Opera and IE all have issues with placing the caret correctly after the <br>, which the following code does not attempt to correct.

function enterKeyPressHandler(evt) {
    var sel, range, br, addedBr = false;
    evt = evt || window.event;
    var charCode = evt.which || evt.keyCode;
    if (charCode == 13) {
        if (typeof window.getSelection != "undefined") {
            sel = window.getSelection();
            if (sel.getRangeAt && sel.rangeCount) {
                range = sel.getRangeAt(0);
                range.deleteContents();
                br = document.createElement("br");
                range.insertNode(br);
                range.setEndAfter(br);
                range.setStartAfter(br);
                sel.removeAllRanges();
                sel.addRange(range);
                addedBr = true;
            }
        } else if (typeof document.selection != "undefined") {
            sel = document.selection;
            if (sel.createRange) {
                range = sel.createRange();
                range.pasteHTML("<br>");
                range.select();
                addedBr = true;
            }
        }

        // If successful, prevent the browser's default handling of the keypress
        if (addedBr) {
            if (typeof evt.preventDefault != "undefined") {
                evt.preventDefault();
            } else {
                evt.returnValue = false;
            }
        }
    }
}

var el = document.getElementById("your_editable_element");

if (typeof el.addEventListener != "undefined") {
    el.addEventListener("keypress", enterKeyPressHandler, false);
} else if (typeof el.attachEvent != "undefined") {
    el.attachEvent("onkeypress", enterKeyPressHandler);
}

Answer 4

If you prefer to be happy rather than chase bugs :-) it would be much better to try to make FF use p or div as well. Not just besause it turned out to be a majority vote :-)

The reason is that br alone is borderline illegal if you look at a tag with XML eyes (it injects mixed data model - as in a text that's not guarded by a tag) and the thrend has been for years (by all browsers) towards full XML-ization.

Depending on your actual app it might be worth to try to put a div with fully formed style and definitely with some initial content - if you saw pages where you see grayed-out text like "type your comment here" and it dissapears the second you click into it (or remians - that's a design decision).

The reason for that part is that the semantics of "contenteditable" is "it already has content => browser has enough info to know what to do" so while browsers do their best to do something when faced with no content it makes the situation much more random.

Answer 5

well if you start using html5 it's normal that you have problems in different browsers.. specially IE :)