Новые строки и contenteditable с вложенными нередактируемыми тегами

У меня странный случай для contenteditable элементов в HTML. У нас есть форматированный текстовый редактор, в который клиенты загружают готовые шаблоны (нами), а затем могут изменять этот шаблон по своему усмотрению (в основном).

Части наших шаблонов помечены как недоступные для прямого редактирования, но все же могут быть удалены и т. д. Однако, похоже, возникает проблема, когда один такой элемент является первым элементом в строке (сразу после тега <br/>), а пользователь нажимает DEL в строке выше. Поскольку это contenteditable=false, браузер, кажется, удаляет не <br/>, а весь нередактируемый диапазон.

Пример HTML такой

<div contenteditable=true>
    <span>blah blah blah</span><br/>
    <span contenteditable="false">You cant edit this value directly</span>
</div>

Если пользователь помещает курсор после blah blah blah и нажимает DEL, удаляется весь следующий редактируемый контент, а не разрыв строки.

Есть ли способ, javascript или иным образом, исправить это поведение?

Я дурачился, пытаясь определить положение курсора (используя rangy) и вставляя временные пробелы и т. д., но я не могу заставить его иметь желаемое поведение, а именно то, что нередактируемый тег поднимается до предыдущего линия.

Мы ограничили использование редактора только Chrome, поэтому не нужно беспокоиться о IE или FF.

jsfiddle примера


person Thomas Jones    schedule 12.07.2012    source источник
comment
Является ли <br/> частью вашего шаблона? Если да, то не могли бы вы просто использовать 3 div вместо <br/>?   -  person Lea Hayes    schedule 26.07.2012
comment
да. По причинам, в которых я не совсем уверен (вероятно, для рендеринга), мы переопределили нажатие клавиши ввода, чтобы вставить разрыв строки, вместо того, чтобы разрешить браузеру вставлять, в данном случае, элементы div.   -  person Thomas Jones    schedule 27.07.2012
comment
Другим решением может быть полный контроль над событиями удаления ключа. Вы можете использовать унаследованные функции, когда это необходимо, и блокировать событие, когда это нежелательно. Или даже используйте 100% пользовательскую логику удаления. Редактировать: Признал, что получить позицию каретки может быть немного сложно, но это, безусловно, возможно.   -  person Lea Hayes    schedule 27.07.2012
comment
@LeaHayes да, мы сделали что-то подобное. Это не идеально, но определенно лучше. rangy очень помог выяснить, где находится курсор в диапазоне   -  person Thomas Jones    schedule 31.07.2012
comment
У Aloha, кажется, есть довольно солидный редактор (который можно расширить), возможно, стоит упомянуть: aloha-editor.org   -  person Lea Hayes    schedule 31.07.2012


Ответы (2)


Сделайте каждый диапазон contenteditable, тогда пользователь не сможет удалить диапазон, который вы не хотите редактировать, и избавьтесь от редактируемого div.

Вот моя версия JSFiddle: http://jsfiddle.net/howderek/HgRsF/2/

person howderek    schedule 01.08.2012
comment
Это потенциальное решение, но оно не соответствует тому, что нам нужно, так как это находится в рамках редактора форматированного текста, а div — это блок редактируемой области. Промежутки внутри div являются результатом ряда операций по стилизации текста определенным образом. - person Thomas Jones; 02.08.2012
comment
Ok. Могу я спросить, почему вы хотите, чтобы один диапазон был защищен от редактирования, даже если он находится в области редактирования? - person howderek; 02.08.2012
comment
это было плохое дизайнерское решение с самого начала, и, к сожалению, продукт продвинулся достаточно далеко, чтобы застрять. Эти конкретные промежутки являются повторно используемыми значениями, содержимое которых управляется по-разному и может быть подключено к нескольким разрозненным документам. Они недоступны для редактирования в разделе контента, поэтому пользователи вынуждены использовать их многократно. Настоящим решением здесь было вручную обрабатывать нажатия клавиш ввода/удаления, когда это необходимо, и у нас есть хорошее решение для этого, но все еще несовершенное. - person Thomas Jones; 02.08.2012

Вопрос из 2012 года, и с тех пор эта проблема была исправлена ​​и вложенные теги contenteditable работают как положено. Есть еще некоторые проблемы, такие как эта ошибка, но в целом функция должна быть полезной.

person mik01aj    schedule 18.08.2014
comment
Кажется, это все еще отображается в примере JSFiddle, указанном выше, в моем браузере (Chrome 40) - person Chris; 23.12.2014