Атрибут contenteditable в HTML


Содержание

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

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

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

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

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

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

HTML :: Атрибут contenteditable

В HTML универсальный атрибут contenteditable (от англ. editable content – редактируемое содержимое) разрешает редактирование содержимого элемента прямо в браузере.

Несмотря на то, что атрибут contenteditable является универсальным, в элементах типа ‘input’ или ‘textarea’ он не работает, соответственно и значение атрибута родительского элемента не наследуется. Для этих целей в таких элементах используются свои атрибуты.

Синтаксис

Значения

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

Разрешается вообще не указывать значение. Если атрибут присутствует, то подразумевается значение «true» , иначе используется значение по умолчанию.

Значение по умолчанию: значение элемента ‘html’ принимается за false , другие элементы наследуют значение родительского элемента.

Атрибут contenteditable в HTML

Доброго времени суток и сразу приступим к делу.

Допустим у нас есть такой html — код

и мы хотим вместо знаков вопроса подставить какие то свои данные.

Для этого в html5 был введен атрибут contenteditable, который поддерживается практически всеми элементами. Если элементу установить этот атрибут и передать ему в качестве значения true, то у нас появится возможность редактирования текстового содержимого этого элемента.

Рассмотрим более подробно:

Теперь как видите у нас появилась возможность редактирования содержимого тегов span

Но тут следует учитывать , отредактированные данные нигде не сохраняются.

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


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

На этом все дорогие друзья надеюсь вы когда нибудь найдете применение этому атрибуту.

Атрибуты HTML-тегов

С тем, что такое HTML теги, мы уже разобрались. Мы выяснили, что у них есть содержимое. Однако это ещё не всё. У тегов также есть атрибуты, которые расширяют их возможности, а у атрибутов, в свою очередь, есть значения. С их помощью элементу можно задавать параметры, определять стиль оформления. Например, тегом

вы обозначили абзац. Но как сделать, чтобы он был выровнен по правому краю? Для этого понадобится определённый атрибут с соответствующим значением. Как некоторые теги не имеют пары, так и некоторые атрибуты могут употребляться без значений.

Как писать атрибуты?

Атрибуты — зарезервированные слова (как и теги, только без угловых скобок), значения же их могут быть разными. Так же, как и теги, атрибуты со значениями рекомендуется писать маленькими буквами, хотя браузерам, в общем-то, безразлично — это просто правило хорошего тона: по-русски ведь ТОЖЕ НЕ ПРИНЯТО ПИСАТЬ ПРИ ВКЛЮЧЕННОМ CAPS LOCK. А чем HTML хуже?

Значения с атрибутами записываются в таком формате:

Писать атрибуты всегда нужно внутри открывающего тега, после зарезервированного слова.

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

Универсальные атрибуты

Каждый HTML-тег наделён собственным набором атрибутов. Некоторые атрибуты могут быть доступны для нескольких тегов, другие же могут работать только с одним. Ещё есть группа универсальных (глобальных) атрибутов, которые можно использовать с любым тегом. Вкратце ознакомимся с атрибутами этой категории.

  • accesskey позволяет задать сочетание клавиш для доступа к определённому объекту страницы. Например, вы можете сделать так, чтобы с помощью комбинации клавиш Alt+1 пользователь переходил по определённой ссылке. Таким образом разработать систему клавишной навигации.

В качестве значения атрибута могут выступать цифры 0-9 или буквы латинского алфавита:

  • class позволяет связать тег с заранее заданным с помощью CSS оформлением. Использование атрибута позволяет существенно уменьшить код, ведь вместо того, чтобы повторять ввод одного и того же блока CSS, можно просто ввести имя соответствующего ему класса.
  • С помощью contenteditable можно разрешить пользователю редактировать любой элемент HTML-страницы: удалять, вставлять, изменять текст. Этот же атрибут даёт возможность редактирование и запретить. Значения имеет всего два: true — правку разрешить, false — запретить.
  • При помощи атрибута contextmenu вы можете наделить любой элемент документа уникальными пунктами контекстного меню на своё усмотрение. Само меню создаётся в теге , а атрибуту contextmenu присваивается его идентификатор.
  • dir определяет направление текста: слева направо (ltr) или справа налево (rtl).
  • draggable позволяет запретить (false) или разрешить (true) пользователю перетаскивать наделённый этим атрибутом элемент страницы.
  • dropzone указывает браузеру, что делать с перетаскиваемым элементом: копировать (значение copy), перемещать (move) или создать на него ссылку (link).
  • h >
  • translate разрешает (yes) или запрещает (no) перевод содержимого тега.

  • align задаёт выравнивание элемента. Например, с его помощью можно выровнять текст по левому краю (значение left), по правому краю (right), по центру (center) или по ширине (justify). Для изображений (тег ) также доступно выравнивание по верхней границе самого высокого элемента строки (top), по нижней границе (bottom), а значение middle делает так, что средняя линия картинки совпадает с базовой линией строки.

Стоит иметь в виду, что использовать атрибут align не рекомендуется, а выравнивать текст лучше с помощью CSS.

Пример использования атрибутов

В качестве примера рассмотрим строку HTML-кода:

Вся строка создаёт абзац текста, который пользователь может в браузере самостоятельно изменять.

Разберём каждый элемент строки.

— открывающий тег контейнера, хранящего абзац.

Между символами > и

Полезные ссылки:

  • Основы HTML — бесплатный 2-х часовой видеокурс по основам HTML;
  • Бесплатный курс по верстке сайта — пример блочной вёрстки с чистого листа;
  • Вёрстка сайта с нуля 2.0 — полноценный платный курс.

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.

Блог Vaden Pro

  • 94 просмотра

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

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

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

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

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

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

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

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

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

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

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

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

Атрибут contenteditable в HTML

Доброго времени суток и сразу приступим к делу.


Допустим у нас есть такой html — код

и мы хотим вместо знаков вопроса подставить какие то свои данные.

Для этого в html5 был введен атрибут contenteditable, который поддерживается практически всеми элементами. Если элементу установить этот атрибут и передать ему в качестве значения true, то у нас появится возможность редактирования текстового содержимого этого элемента.

Рассмотрим более подробно:

Теперь как видите у нас появилась возможность редактирования содержимого тегов span

Но тут следует учитывать , отредактированные данные нигде не сохраняются.

Если вы хотите чтобы ваши данные сохранились после перезагрузки страницы, то можете воспользоваться cookie, локальным хранилищем или 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, CSS, JavaScript кода

Можно сделать и самому визуальный онлайн редактор HTML, CSS, JavaScript кода. Его не нужно скачивать, он очень простой в создании и использовании и совершенно бесплатный. ㋛ У меня, например, есть такие статьи, где можно прямо на странице подправить CSS. Очень удобно.

Атрибут contenteditable

Атрибут contenteditable позволяет редактировать любой элемент.

Динамически изменяемый HTML (а-ля редактор HTML)

Создадим поле, куда можно ввести код HTML, ниже другое поле, которое показывает его отображение. Поскольку textarea сам переводит в спец. символы, то скрипт будет минимальным:

JavaScript на лету

Для того, чтобы внешний JavaScript выполнялся после загрузки HTML документа, применяют атрибуты defer и async.

Для того, чтобы JavaScript подгружался на лету, можно создать новый тег script

12 комментариев:

ctdf Если ввести в css * или ввести в html тег style *, то весь сайт, а не только тот блок в котором выводиться результат.
И получается что это не онлайн редактор HTML, css и js, т.к. используя его вы редактируете не только строго отведённое вам место, а всю страницу включая онлайн редактор, и следовательно результат может быть влиянием онлайн редактора на страницу, которая влияет на онлайн редактор, результат не предсказуем.

Вставка ContentEditable в HTML-таблицы

Я хранение HTML для таблицы в $ scheduletext. Я хочу, чтобы иметь возможность редактировать любую ячейку таблицы при нажатии так, я использую JQuery для мыши на действия. При нажатии на ячейку она гаснет, но не позволит мне набрать в нем, то, что мне нужно изменить, чтобы иметь возможность ввести в это?

Для редактирования и тестирования, так как запустить свой код , вам также необходимо в таблице, CSS Doesnt помешают . Я бросил его в JSfiddle, мы надеемся сделать его проще для тех , кто пытается дать мне руку: https: // jsfiddle. сеть / 4yczepsj / Спасибо заранее !!

EDIT: По какой-то причине JSfiddle не делает вообще ничего при нажатии, но на живой модели на моем сайте клетка гаснет при нажатии, но ничего не может быть введено.

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

Я сделал следующие изменения:

  • добавлена ​​TabIndex так таблица клетки tabable.
  • дать фокус на ячейку таблицы на мыши.
  • добавить contenteditable атрибут в фокусе.
  • выбрать содержимое ячейки таблицы в фокусе.
  • удалить contenteditable на blur (когда тд теряет фокус).
Илон Маск рекомендует:  Плагин к фотошопу, и как его сделать
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL