как изменить поведение блокируемых контентов после нажатия на Enter в различных браузерах

Как ранее говорил Дуглас, браузеры пытаются клонировать предыдущий тег, когда клиент начинает новый абзац на редактируемой странице. Несоответствие возникает, когда браузеру нечего отступать - например, когда изначально тело страницы пусто В этом случае разные браузеры ведут себя по-разному: IE начинает переносить каждую строку в < p > тег Chrome переносит каждую строку в тег < div >.

Чтобы улучшить взаимодействие между браузерами, разработчики WebKit представили команду DefaultParagraphSeparator . Вы можете использовать следующий JavaScript при загрузке страницы для Chrome, чтобы изменить разделитель абзаца по умолчанию на < p > тег:

document.execCommand('defaultParagraphSeparator', false, 'p');

Следующее добавит <br>, когда клавиша ввода нажата во всех основных браузерах, и попытается разместить каретку сразу после нее. Однако у WebKit, Opera и IE есть проблемы с правильным размещением каретки после <br>, что следующий код не пытается исправить.

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);
}

Превосходные ссылки находятся здесь на contenteditable.

http://blog.whatwg.org/the-road-to-html-5-contenteditable

Что приводит к действительно хорошему API здесь http: / /dev.opera.com/articles/view/rich-html-editing-in-the-browser-part-1/ http://dev.opera.com/articles/view/rich-html-editing- in-the-browser-part-2 /

Если вы готовы потратить от 30 минут до часа, чтобы прочитать все это, вам совершенно не нужно будет использовать какой-то дерьмовый сторонний редактор, такой как tinyMCE или ckeditor или в любом случае, вы можете создать и настроить его самостоятельно и, честно говоря, проще и быстрее сделать это с нуля, чем справляться со всеми ненужными и ненужными API стороннего редактора WYSIWYG.

Если вы предпочитаете быть счастливым, а не гоняться за ошибками :-) было бы гораздо лучше попытаться заставить FF также использовать p или div. Не только потому, что он оказался большинством голосов :-)

Причина в том, что один только br является погранично недопустимым, если вы смотрите на тег глазами XML (он вводит смешанную модель данных - как в тексте, который не защищен тегом), и в течение многих лет (всеми браузерами) он находился в направлении полной XML-идентификации.

В зависимости от вашего реального приложения, возможно, стоит попытаться поместить div с полностью сформированным стилем и определенно с некоторым начальным содержимым - если вы видели страницы, на которых вы видите затененный текст типа «введите свой комментарий здесь», и он исчезает второе нажатие (или remians - это дизайнерское решение).

Причиной этой части является то, что семантика «contenteditable» заключается в том, что «у него уже есть контент => браузер имеет достаточно информации, чтобы знать, что делать», поэтому браузеры делают все возможное, чтобы что-то делать, когда сталкиваются с отсутствующим контентом. ситуация гораздо более случайная.

Я считаю, что если в div уже есть тег параграфа, и пользователь нажимает return, когда фокус находится внутри этого тега параграфа, то Firefox вставит еще один. Так, если у вас есть вот это:

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

и вы фокусируетесь, нажимаете return, Firefox вставит третий абзац.

Возможно, вы сможете обойтись без & nbsp ; в тегах абзацев, задав им минимальную высоту, и сможете обойтись только одним. В последний раз, когда я рассматривал этот вопрос, мне так и не удалось разобраться с этим поведением. Вероятно, вам понадобится JavaScript, чтобы обеспечить минимум один тег абзаца внутри div.