Эмуляция INPUT с помощью атрибута contenteditable


Содержание

Атрибут contenteditable — редактирование и сохранение контента прямо на странице

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

Как использовать атрибут contenteditable? Пример кода ниже:

Достаточно просто указать атрибут contenteditable без значения – и практически любой элемент таким образом может стать редактируемым. Но как сохранить сделанные изменения? Для этого необходимо использовать JavaScript и отправлять измененный контент на сервер при помощи Ajax.

Как может выглядеть код JavaScript для реализации функции сохранения контента? Например, если использовать библиотеку jQuery, то так:

Таким образом, отредактировать текст прямо на странице и сохранить его совсем просто. Конечно, можно улучшить код и сделать небольшой визуальный редактор, который упростил бы работу с текстом. В Drupal, например, есть визуальный редактор Quick Edit, который позволяет редактировать контент прямо на странице, но это уже другая тема. Стоит взять на заметку, что в разных браузерах может отличаться реализация работы атрибута contenteditable, но главное, что этот атрибут поддерживается почти во всех браузерах.

Как ограничить ввод символов в contenteditable, используемый в html-таблице

В настоящее время я использую html-таблицу на моей веб-странице, чтобы пользователь мог вводить определенные данные. Однако, поскольку нет ограничений на ввод символов, таблица может растягиваться в значительной степени, когда пользователь вводит столько символов, сколько пожелает.

Мне было интересно, как ограничить это contenteditable, чтобы это не происходило?

Ниже приведен фрагмент кода, который я использую для таблицы

Я нашел эту ссылку ниже для аналогичной проблемы, но, будучи новатором для jQuery и любительского разработчика, я изо всех сил стараюсь понять ответы и как их использовать.

Вы можете сделать что-то сложное с помощью keypress() обработчика событий. Предотвратите событие keypress , если содержимое больше вашего предела, возвращая false

UPDATE: Добавить прослушиватель в событие paste . Затем проверьте длину содержимого. Также запретите функцию перетаскивания, чтобы предотвратить перетаскивание содержимого.

Добавьте политику переполнения, например:

Если вы знаете, как использовать классы CSS, используйте это.

Блог Vaden Pro

  • 94 просмотра

Характеристики атрибута

В каких браузерах работает?

6.0+ 4.0+ 9.2+ 4.0+ 4.0+ 3.0+ 1.0+

Для чего используется

Позволяет пользователю редактировать текстовую часть, а именно те элементы, к которым применен атрибут. Допускаются типичные команды для обработки текста, типа удаления, вставки копируемого текста и прочее.

В каких тегах он может использоваться?

Как правильно задавать?

Простейший пример использования атрибута выглядит следующим образом:

Какие значения могут быть записаны в атрибут?

  • true — разрешает пользователю вносить свои изменения.
  • false — доступ к изменениям блока недоступен.

Допускается использование атрибута с пустым значением — contenteditable=»». В таком случае система срабатывает также, как и при значении true.

По умолчанию считывает показатели родительского элемента.

Атрибут contenteditable

Сообщает, что элемент доступен для редактирования пользователем — можно удалять текст и вводить новый. Также работают стандартные команды вроде отмены, вставки текста из буфера и др.

Синтаксис

Значения

Вместо true допустимо указывать пустое значение ( contenteditable=»» ) или вообще его не писать ( contenteditable ).

Значение по умолчанию

По умолчанию наследует значение родителя.

Пример


Спецификация ?

Спецификация Статус
WHATWG HTML Living Standard Живой стандарт
HTML5.1 Рабочий проект
HTML5 Рекомендация

Спецификация

Каждая спецификация проходит несколько стадий одобрения.

  • Recommendation ( Рекомендация ) — спецификация одобрена W3C и рекомендована как стандарт.
  • Cand >Возможная рекомендация ) — группа, отвечающая за стандарт, удовлетворена, как он соответствует своим целям, но требуется помощь сообщества разработчиков по реализации стандарта.
  • Proposed Recommendation ( Предлагаемая рекомендация ) — на этом этапе документ представлен на рассмотрение Консультативного совета W3C для окончательного утверждения.
  • Working Draft ( Рабочий проект ) — более зрелая версия черновика после обсуждения и внесения поправок для рассмотрения сообществом.
  • Editor’s draft ( Редакторский черновик ) — черновая версия стандарта после внесения правок редакторами проекта.
  • Draft ( Черновик спецификации ) — первая черновая версия стандарта.

Особняком стоит живой стандарт HTML ( Living ) — он не придерживается традиционной нумерации версий, поскольку находится в постоянной разработке и обновляется регулярно.

Браузеры ?

6 12 4 9.2 4 4

Браузеры

В таблице браузеров применяются следующие обозначения.

  • — элемент полностью поддерживается браузером;
  • — элемент браузером не воспринимается и игнорируется;
  • — при работе возможно появление различных ошибок, либо элемент поддерживается с оговорками.

Число указывает версию браузреа, начиная с которой элемент поддерживается.

Frontender Magazine

В первый раз, когда я сидел за столом напротив Якоба (Jackob @fat) он прямо меня спросил: «Как бы ты написал текстовый редактор?».

Я нарисовал древообразную структуру на доске, взмахнул руками и сказал «это говенный редактор». Затем нарисовал колонку контейнеров со стрелками указывающими на массивы, еще немного помахал руками и сказал «это хороший редактор».

Якоб приподнял бровь.

Этот пост — то, что я ответил бы ему тогда, если бы у меня был год на раздумья.

Почему ContentEditable ужасен: математическое доказательство.

ContentEditable это нативный способ для насыщенного редактирования текста в браузере. И он — грустный.

Я попробую математически доказать вам, объясняя все на пальцах, почему текущий подход к редактированию, используемый ContentEditable не работает. Это не потому, что я считаю, что математика — наиболее убедительный способ в данном случае, а потому, что она делает аргументы более абстрактными.

Я считаю, что текстовые редакторы порождают большое количество путаницы и скверно сформулированных вопросов, вроде «Что вообще значит это What-You-See-Is-What-You-Get (WYSIWYG)?»

Так что же такое WYSIWYG? Хороший WYSIWYG редактор должен удовлетворять трем аксиомам:

  1. DOM должен быть четко сопоставим с Видимыми материалами.
  2. Выделенные элементы DOM и выделенные элементы Видимых материалов должны быть четко сопоставимы.
  3. Все видимые области редактирования должны соотносится с алгебраически замкнутым и конечным набором видимых элементов.

Во-первых, я объясню что это значит и почему хороший редактор должен соответствовать этим правилам. Давайте примем их как аксиомы — слабое место любого доказательства. Мы предполагаем что они верны, пока не получили доказательства обратного.

Во-вторых, я докажу, что ContentEditable не соответствует ни одной из этих аксиом.

В-третьих, мы поговорим о том, как новые возможности браузеров и библиотеки решают эти проблемы и как мы их решаем в редакторе Medium.

Пространство DOM это инвариантность всех веб-страниц, которые могут быть созданы с помощью HTML. Все страницы можно представить как дерево элементов с текстовыми узлами в качестве листьев.

Видимое пространство («what-you-see-is-what-you-get») это пространство всех видимых страниц — того, что ты видишь на экране, когда браузер отображает страницу. Мы считаем страницы тождественными в Видимом пространстве, если они выглядят одинаково.

Движок рендера браузера переносит страницу из пространства DOM в Видимое пространство. Подразумевается что все страницы в Видимом пространстве — результат работы функции Render(x), где x — некое DOM-дерево.

Если мы говорим что отображение из одного пространства в другое в редакторе четкое, мы имеем в виду, что оно сохраняет все операции редактирования1. Если быть точнее, то Рендер четкий, если

Это способ формализации части «what you get» после «what you see». Если две страницы выглядят одинаково, и мы применяем к ним одинаковые операции редактирования, то и результат будет одинаковый 1.

Я был удивлен, как много “WYSIWYG” редакторов в веб не соответствуют этому критерию. Это может казаться очевидным, но приводит к странному экзистенциальному вопросу: что значит «одинаковый»? И это лучше рассмотреть на примерах.

Четко определенные материалы

Рассмотрим простое выражение:

Редактор Medium отображает это следующим образом

Существует множество способов добиться отображения последнего слова полужирным курсивом 2.

Все эти формы должны быть эквивалентны. Любые правки, которые вы вносите в этот текст, должны приводить к идентичным результатам в каждом из указанных случаев. И это на удивление трудно — редактировать текст с учетом всех этих DOM-форм.

В многих имплементациях ContentEditable в веб в HTML могут попасть пустой span или невидимый символ и в результате два ContentEditable-элемента ведут себя совершенно по-разному (хотя и выглядят идентично). Это не только сводит с ума, но, кроме того, ещё и затрудняет отладку.


Даже если мы знаем как реализовать четкую операцию редактирования, как мы её проверим? Если ограничить HTML простыми тегами, доказать, что две формы визуально совпадают … сложно. Лучший вариант — перебрать каждую букву, присвоить ей стиль и сравнить результат.

В идеальном мире у нас для этого было бы высокоуровневое API, позволяющее производить визуальное редактирование. Каждая операция гарантирована была бы четкой и делала одно и то же для визуально идентичных страниц. Тогда, пока единственное, что использует это API — ваш редактор, можно гарантировать что результат — четкий.

Четкое выделение материалов

Отношение между пространством DOM и Видимым пространством ужасно, но, хотя бы, это отношение типа много-к-одному. Одно дерево DOM отображается в Видимое пространство одним конкретным образом.

С выделением все намного хуже, так как это отношение типа многие-ко-многим.

Достаточно просто убедиться, что одно выделение может иметь множество соответствующих ему деревьев в пространстве DOM. Если у вас есть HTML

то курсор, находящийся перед «Бэггинс» может находится в одной из трех позиций: перед тегом strong , между тегами strong и em и после тега em . Если вы поместите курсор перед «Бэггинс» и начнете вводить текст, то он будет полужирным, курсивом или ни тем, ни другим?

Более того, одно выделение DOM может иметь множество вариантов отображение в Видимое пространство. Рассмотрите случай, когда в «ладно скроенный» после «ладно» появится разрыв строки, как на картинке выше. Курсор в конце первой строки и в начале второй строки обладает одной и той же позицией в DOM, но находится в разных позициях в Видимом пространстве. И, насколько я понимаю, невозможно предсказать какой вариант мы увидим в браузере.

Когда мы разрабатываем команды для редактора мы хотим, чтобы выделение выглядело одинаково и одинаково себя вело. Но, так как отображение из пространства DOM в Видимое пространство нечеткое — это попаболь.

Закрытый и завершенный редактор

Пару лет назад моя подруга Джулия (Julie) отправила мне сообщение в Gchat:

Мы наконец можем отказаться от Apple Style Span … ох, счастливый день настал!

Рьюсуке Нива (Ryosuke Niwa) написал чудесный пост в блоге WebKit о том, как они избавлялись от apple-style-span. Если вы его прочтете, то многие затронутые в нем проблемы покажутся вам знакомыми. ContentEditable в WebKit добавлял массу HTML-оберток, которые ничего не меняли визуально, но заставляли редактор изменять свое поведение.

Кроме того, он обратил внимание на то, что имплементация ContentEditable в WebKit должна уметь справляться с HTML, созданным в другой CMS или любой другой имплементацией ContentEditable. Наш редактор должен хорошо уживаться в этой экосистеме. Это значит, что мы должны генерировать HTML, который легко читать и понимать. И, с другой стороны, мы должны понимать, что наш редактор должен работать с контентом вставленным из буфера, который, в нашем редакторе вообще невозможно получить.

Я сталкивался с багами, которые вообще можно было воспроизвести только создав текст в Firefox, переключившись для редактирование в Chrome и затем снова в Firefox. Это вгоняет в депрессию — и разработчиков, и пользователей.

Чтобы избежать этого класса ошибок, мы считаем, что контент хорошего WYSIWYG редактора должен быть алгебраически замкнут после его редактирования. Это значит, что контентом редактора должно быть что-то, что я мог бы написать сам, не используя редактор. И оно не должно ломаться при вставке в него HTML или редактировании в другом браузере.

Фреймворк для хороших WYSIWYG-редакторов

Голый элемент с атрибутом ContentEditable это плохой WYSIWYG-редактор, так как он не соответствует ни одной из приведенных выше аксиом. Так как нам сделать хороший?

У редактора Medium есть 4 ключевых составляющих.

  1. Создать модель документа, с простым способом определить эквивалентны ли две модели визуально
  2. Создать соответствие между DOM и нашей моделью
  3. Задать операции редактирования модели с четким поведением
  4. Преобразовывать любое нажатие клавиши или кнопки мыши в последовательность таких операций

Я кратко рассмотрю каждую из этих составляющих, и как мы их можем реализовать. После этого я рассмотрю как разработчики браузеров делают ContentEditable лучше, и могут сделать некоторые из этих составляющих ненужными.

Модель редактора Medium

Модель редактора Medium состоит из двух частей: список параграфов и список разделов.

Каждый параграф содержит:

  • текст, строку обычного неформатированного текста
  • разметку, список форматированных областей, вроде «полужирное начертание с 1 по 5 символы»
  • мета-данные для изображений или элементов embed
  • лейаут, описание того, как мы должны позиционировать параграф

Раздел содержит данные списка параграфов.

Любое выделение в редакторе Medium выражается с помощью двух точек. Каждая точка это номер параграфа, смещение в тексте параграфа и тип. Большинство выделений это выделение текста. Кроме него есть медиа-выделения (когда оно включает изображение), и выделения разделов.

Достоинства такой модели в том, что две модели обладают одинаковым визуальным представлением тогда и только тогда, когда модели одинаковы. Любое изменение модели приводит к четко заданному изменению представления.

Соответствия в редакторе Medium

Далее, определяем соответствие пространства DOM пространству модели. Мы рассматриваем два различных случая: «внутреннее» и «внешнее» соответствие.

Внутреннее соответствие это когда мы берем контент внутри редактора и преобразуем его туда-сюда между DOM и моделью. Внутреннее соответствие должно быть один-к-одному.

Внешнее соответствие это когда у нас есть HTML, полученный не с помощью нашего редактора, например если пользователь копипастит HTML, найденный в интернет в пост Medium. Нужно привести его в соответствие с нашей раздело-параграфной моделью. Можно ожидать, что это приведет к потере части форматирования. В списке наших приоритетов сперва идет неформатированный текст, затем разметка, отвечающая за полужирное и курсивное начертание, за ссылки, и только потом — изображения и прочее форматирование.

Когда мы создаем соответствие нашей модели DOM, дерево выглядит так:

Узел section генерируется из модели раздела и применяет фоновые изображения или цвета к списку параграфов.

Узел section-inner генерируется на основе лаяута параграфа и определяет ширину основной колонки. Для большинства параграфов он узкий и центрированный. Для параграфов с изображениями на всю ширину, ширина 100%. Для строчной сетки лаяут обладает смещением уменьшенным вдвое.

Следующий узел это один из семантических типов параграфа: P, H2, H3, PRE, FIGURE, BLOCKQUOTE, OL-LI (упорядоченный список элементов), и UL-LI (неупорядоченный список элементов).

Когда нужно преобразовать области разметки в узлы DOM, мы сортируем их по типу: А, затем STRONG, затем EM. Мы никогда не сгенерируем якорь внутри тега STRONG. Мы преобразуем разметку так, чтобы якорь содержал тег STRONG.

Операции редактирования в редакторе Medium

У редактора Medium ровно 6 операций редактирования: InsertParagraph (ВставитьПараграф), RemoveParagraph (УдалитьПараграф), UpdateParagraph (ОбновитьПараграф), InsertSection (ВставитьРаздел), RemoveSection(УдалитьРаздел), и UpdateSection(ОбновитьРаздел).


Они делают именно то, что написано. Операции над параграфами работают с моделью параграфов и их порядком. Операции над разделами работают с моделью разделов и их порядком.

Весь возможный контент редактора можно получить с помощью последовательности этих операций и обычно создать такую последовательность — тривиальная задача.

Вполне очевидно, что контент в рамках этих операций четко определен. Они работают непосредственно с моделью, а не с DOM, поэтому легко определить когда два элемента выглядят визуально одинаково.

Отслеживание редактирования

Когда вы работаете с редактором Medium нам нужно преобразовывать все нажатия кнопок и клики в последовательность указанных выше 6 операций.

Это не просто. Мы не хотим поддерживать огромный список из всех возможных комбинаций кнопок. Он будет безумно большой для англоязычных пользователей, не говоря уже про языки с не латинскими символами и клавиатурой.

Ключевым тут является понимание того, что мы можем перечислить все способы вставить и удалить параграф с помощью обычных ContentEditable команд. Это: возврат каретки (enter, ctrl-m и т.д.), удаление (delete, backspace и т.д.), замена текста (выделите текст и начните набирать другой) и вставка. Так что мы перехватываем эти события, отменяем их обработчики и вручную преобразовываем события клавиатуры в операции редактора.

Для всех остальных событий клавиатуры мы оставляем поведение ContentEditable по умолчанию. После завершения события клавиатуры, мы получаем модель параграфа из DOM и сравниваем с моделью, которая у параграфа была ранее. Если DOM изменился, мы создаем новую операцию UpdateParagraph и передаем её в поток событий редактора, синхронизируя DOM и модель.

Быстрый перехват редактирования

Если бы у нас были неограниченные вычислительные мощности, применение этих операций было бы простой задачей. Мы бы применяли их к модели, перестраивали отображение всего поста и все.

Но в реальном мире, перерисовывание всего поста после каждого нажатия происходит слишком медленно. И вы бы видели массу уродливого мигания элементов, так как iframe и изображения постоянно бы перезагружались. Вместо этого мы отслеживаем изменения в модели и пытаемся сделать минимально возможные изменения в DOM.

Сейчас, набирая текст, я вижу как мерцает красное подчеркивание модуля проверки правописания Chrome под словом «нажатие». Причина этого в том, что редактор Medium заменяет весь параграф сразу, вместо того, чтобы изменить его часть. Если сделать более специфичное изменение в DOM, то это мерцание прекратится, но код редактора станет более сложным.

Светлое будущее текстовых редакторов

В последнее время можно было услышать ворчание некоторых контрибьюторов Chromium (Леви Веинтрауб (Levi Weintraub), Джулии Пэрент (Julie Parent), и Елта Либренда (Jelte Liebrand)), что они хотят переписать ContentEditable с использованием кастомных элементов Polymer и теневого DOM. Предложение столкнулось с множеством тех же архитектурных проблем, которые пытается решить редактор Medium.

  1. Создать модель редактора используя кастомные элементы Polymer
  2. Определить соответствие между моделью редактора и реальным DOM используя теневой DOM
  3. Все нажатия клавиш и кнопок мыши в ContentEditable блоке будут преобразовываться в абстрактное описание операции редактирования, в виде JSON объекта вроде
  4. Для polymer-элементов задаются обработчики для абстрактных операций редактирования

Если бы наш редактор получил своего рода API для таких абстрактных операций со стороны браузера, то можно было бы выбросить массу кода, описывающего преобразование нажатия кнопок в абстрактные операции редактирования. Было бы интересно попробовать выразить нашу модель параграфов с помощью элементов Polymer и теневого DOM.

Каким бы мог быть ContentEditable

Когда я пытаюсь объяснить это людям, которые работают над текстовыми редакторами, меня называют шулером.

Конечно Medium лучше, чем ContentEditable. Ты жульничаешь. ContentEditable должен выполнять функции WYSIWYG HTML-редактора общего назначения. Medium отбрасывает это требование и вы можете выбирать с какими HTML-структурами работать.

Это правда. Вся беда в неправильно поставленной задаче, что приводит к недопониманию.

Хороший WYSIWYG не совместим с хорошим HTML редактором общего назначения. Это аксиома. Невозможно создать то, чем пытается быть ContentEditable, потому, что требования к WYSIWYG и HTML редактору общего назначения противоречат друг другу.

На мою точку зрения на этот вопрос сильно повлияло эссе Стива Еггэ (Steve Yegge) «Непонятная фигня». Проблемы дизайна и UX могут быть так же не решаемы, как проблемы алгоритмов big-O. Хороший WYSIWYG-редактор обычного HTML так же невозможен, как решение проблемы останова.

ContentEditable можно спасти. Но его задачи должны измениться. С более богатым DOM API, таким как API теневого DOM, ContentEditable может стать платформой для создания нового поколения редакторов в веб. Но мы должны рассматривать его как платформу и API, а не как самостоятельный компонент, который все делает сам.

Примечания

1. Если вы изучали основы высшей математики, то понимаете, что четкое соответствие это, по сути, морфизм. Это неуклюжее слово, несущее за собой подробности, которые нам не нужны. Так что в этой статье мы будем называть его «четким соответствием».

2. CSS усложняет дискуссию и алгоритмы редактирования, которые должен имплементировать браузер. Но это никак принципиально не меняет доказательства того, что ContentEditable ужасен. Не переходя к конкретике, мы можем игнорировать CSS и ограничить анализ простым HTML.

contenteditable

На этой странице

(Mozilla / 5.0 (Windows NT 6.3, WOW64; rv: 29.0) Gecko / 20100101 Firefox / 29.0)
Атрибут contenteditable global attribute — это перечисляемый атрибут, указывающий, должен ли элемент редактироваться пользователем. Если это так, браузер изменит свой виджет, чтобы разрешить редактирование. Атрибут должен принимать одно из следующих значений:

  • true или пустую строку, которое показывает, что элемент должен быть редактируемым;
  • false , которое показывает, что элемент должен быть нередактируемым.

Если атрибут не указан, то его значение наследуется от своего родительского элемента.

Этот атрибут принимает одно из определенных значений и не является булевским. Это значит, что точное использование одного из значений true, false или пустая строка обязательно и такое сокращение, как Пример метки неразрешено. Верное использование — Пример метки .

Вы можете установить цвет, используемый для вставки текста caret
со свойством CSS caret-color .

div атрибут contenteditable

Совсем недавно перед мною встала задачка по поводу реализации автоматического изменения размера, а именно высоты у textarea, при вводе текста. Если вы уже сталкивались с подобной проблемой или столкнулись сейчас, то наверняка используете javascript. Да, в большинстве случаев это реально хороший выход из ситуации. Но зачем писать кучу огромного кода, когда можно обойтись без js. Конечно я не могу знать специфику вашей задачи, вёрстки и логики работы сайта, но вот вам моё решение.

Вместо использования обычного textarea, мы будет юзать div. Да, вы не ослышались самый обычный html div. Но зададим ему атрибут contenteditable со значением true.

Украсьте ваш блок, задайте минимальную высоту! Именно через min-height, Максимальную задавать не нужно, так как он же должен будет у нас растягиваться.

С помощью этого атрибута, мы смогли преобразовать наш блок, в текстовое поле, но при этом сохранив все свойства обычного div’а

Но так же не стоит забывать, что этот элемент так и остался обычным блоком. Стало быть, если вам необходимо будет отправлять введённый текст в БД, то необходимо немного дописать в ваш JS.


Я надеюсь что вы используете ajax. В тот момент когда мы собираем поля нашей форы, в самом конце просто добавим содержимое нашего блока. Пример нижу приведён для того случая, если у вас имеются ещё какие либо поля, по мимо нашего блока.

На своей странице вы увидите ваш блок и при клике в него вы сможете редактировать текст, а так же он будет автоматически растягиваться.

HTML редактор

Одним из принципов HTML5 является официальное признание частью стандарта нестандартных возможностей, которые уже широко используются веб-разработчиками. Одним из наилучших примеров следования этому принципу является включение в стандарт двух необычных атрибутов — contentEditable и designMode, которые позволяют сделать из обыкновенного браузера простой HTML-редактор.

Эти два атрибута не новы. Более того, их поддержка была добавлена еще в Internet Explorer 5 на заре становления Интернета. В то время большинство разработчиков отказалось от их использования, рассматривая их всего лишь как расширения Windows для Интернета.

Но с течением лет все больше браузеров начали копировать применяемый в IE практический, но причудливый подход к расширенному HTML-редактированию. В настоящее время все браузеры для настольных компьютеров поддерживают эти атрибуты, хотя они никогда и не были частью официального стандарта.

Редактирование элементов с помощью атрибута contentEditable

Рассмотрим первый инструмент для HTML-редактирования — атрибут contentEditable. Добавление этого атрибута к любому элементу позволяет редактировать содержимое этого элемента, когда оно отображается в окне браузера:

Скорее всего, вы не заметите никакой особенности в отображении этого текста в браузере. Но щелчок где-либо в отображаемом браузером тексте помещает в него курсор редактирования:

В приведенном ранее примере редактируемая область

Некоторые браузеры поддерживают встроенные команды форматирования. Например, в Internet Explorer текст можно делать жирным, курсивом и подчеркивать с помощью комбинаций клавиш + , + и + соответственно. Отменить последнее редактирование в Firefox можно посредством комбинации клавиш + . Все эти «горячие» клавиши можно использовать также в браузере Chrome.

Прежде чем приступить к использованию расширенного HTML-редактирования, стоит узнать, а для чего оно вообще-то применяется. Несмотря на мгновенно производимое впечатление, HTML-редактирование является специализированной возможностью, которая не каждому понравится. Имеет смысл использовать его, чтобы предоставить пользователям быстрый способ изменять HTML-содержимое, например, добавлять сообщения в блоги, вносить обзоры, подавать объявления или составлять сообщения другим пользователям.

Но даже если вы решите, что вам нужны такие возможности, атрибуты contentEditable и designMode могут оказаться не лучшим выбором для их реализации. Они не предоставляют разработчику всех удобств настоящего инструмента для веб-дизайна, таких как команды для редактирования разметки, возможность просматривать и редактировать исходный HTML-код, средства проверки орфографии и т.п.

Обычно атрибут contentEditable в разметку не включается. Вместо этого он включается с помощью JavaScript-кода и отключается по завершению редактирования:

Редактирование страницы с помощью атрибута designMode

Атрибут designMode похож на атрибут contentEditabie, с той разницей, что он позволяет редактировать всю веб-страницу. Это может показаться слегка проблематичным, ведь при редактировании страницы отключаются события элементов. Тогда как мы сможем нажимать кнопки, чтобы управлять процессом редактирования? Решение этой проблемы простое — редактируемый документ помещается внутри элемента , который ведет себя, как сверхмощное окно редактирования:

Этот пример должен дать вам представление о возможностях HTML-редактирования. Например, щелкните на изображении, чтобы выделить его для редактирования. Теперь можно изменять размеры изображения, перетаскивать его на новое место или совсем удалить его. То же самое можно делать и с элементами управления формы, если редактируемая страница содержит их.

Конечно же, если вы хотите превратить этот пример во что-то практическое, то вам нужно будет серьезно доработать его. Прежде всего следует добавить другие элементы управления редактированием. Если вы хотите получше разобраться в модели команд, в этом вам помогут разработчики браузера Opera (см. Rich HTML editing in the browser: part 1 и Part 2). Вторым делом нужно будет делать что-то полезное с отредактированной разметкой, например, отправить ее на сервер, используя объект XMLHttpRequest.

Еще одно предостережение. Этот пример не будет запускаться с локального жесткого диска на всех браузерах. Internet Explorer и Chrome заблокируют его по причинам безопасности, но на Firefox не будет никаких проблем. Для тестирования я использую локальный сервер.

HTML 5 переключает атрибут contenteditable с помощью javascript

enter code here Я пытаюсь сделать что-то редактируемое в Интернете с помощью такой функции

classToEdit — это набор элементов HTML с тем же именем класса или любым другим document.getElementsByClassName(cssclass)

при переходе через отладчик он перепрыгивает через линию

а также по линии

и не выполняет код в фигурных скобках после операторов if

это работает, однако, что означает, что он без проблем создает контент-свойство

также это, казалось, не имело никакого эффекта

Здесь вы создали бесконечный цикл:

Но, если вы говорите, что > «работает», вы должны определить «не работает/работает», поскольку фрагмент определенно не выполняет то, что вы ожидаете от него, если classToEdit является HTMLCollection.

Похоже, вы хотите переключить значения contentEditable , вы можете сделать это следующим образом:

Или просто без, if в цикле:

Ваш текущий код переключит значение обратно на оригинал в случае, если значение было false .

contenteditable

Всем привет. Возможно ли поставить ограничение в теге с contenteditable на ввод симовлов ?

Например:
вводишь несколько символов в тег и последний введенный символ, либо заменяет последний, либо вообще не вводится.

Спасайте, а то начинаю подумывать, что такое вообще невозможно.

06.02.2014, 18:00

Contenteditable
Вставка чистого текста в блок

Contenteditable и сохранение в БД
Есть кусок кода

1

;

Установить курсор в contenteditable
Здравствуйте, делаю для себя вспомогательный редактор кода на html5, понадобилось изменять формат.

Положение текстового курсора в CONTENTEDITABLE слое.
Требуется сделать что-то вроде функции автозаполнения и подсветки ключевых слов при редактировании.

Запретить редактировать вставленный html участок в contenteditable
Всем привет, я использую contenteditable в качестве текстового поля, все сделал, все прекрасно, по.

06.02.2014, 18:17 2

ага. и пользователь думает, что:
1) либо его клавиатура сломалась
2) либо страницу «ключница делала»

а потом, выяснив, что с клавиатурой всё в порядке, плюясь, уходит с вашей страницы

в общем, способ отпугнуть народ вы хороший придумали
—————

у вашего тега с contenteditable есть свойство innerText (или textContent )
при каждом отпускании клавиши ( onkeyup ) проверяйте длину возвращаемого значения этого свойства
если она больше вами установленного, вычисляйте избыток S и показывайте клиенту жёлтую карточку предупреждение типа
alert (‘вы превысили лимит на ‘ + S + ‘ символов. удалите их’);

Илон Маск рекомендует:  Что такое код rfc 2068
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL