Допустимы ли пользовательские элементы HTML5?

181

Я не смог найти точного ответа на вопрос, являются ли пользовательские теги действительными в HTML5, например:

<greeting>Hello!</greeting>

Я ничего не нашел в спецификации так или иначе:

http://dev.w3.org/html5/spec/single-page.html

А пользовательские теги, похоже, не проверяются с помощью валидатора W3C.

d13
источник
2
Возможно, вы не захотите добавлять слишком много информации в статью HTML5, написанную более 4,5 лет назад.
jessegavin
9
Статья Крокфорда странная. Важное предложение звучит так: «Это мое предложение по более мягкому, более мягкому HTML 5». Другими словами, это не тот HTML5, который мы знаем сегодня, а предложение о другом HTML 5 в качестве преемника HTML 4. Странно, потому что он датирован ноябрем 2007 года, когда W3C уже почти год работал над HTML5. , Его использование слова «разрешено» здесь сбивает с толку. Пользовательские теги никогда не были «соответствующими» / «действительными», но анализаторы браузера продолжают работать в их присутствии. В любом случае, предложение Крокфорда не получило никакой силы. Едва ли какая-то его часть включена в HTML5.
Alohci
3
Пользовательские элементы становятся первоклассными теперь, когда в Firefox и Chrome начинает
появляться
3
Что касается Дугласа Крокфорда, мне хочется верить всему, что он говорит.
wnrph
1
Таблица поддержки веб-браузера для пользовательских элементов caniuse.com/#feat=custom-elements
Adrien Be

Ответы:

169

Спецификация пользовательских элементов доступна в Chrome и Opera и становится доступной в других браузерах . Он предоставляет средства для регистрации пользовательских элементов формальным образом.

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

Пользовательские элементы являются частью более широкой спецификации W3, называемой веб-компонентами , наряду с шаблонами, импортом HTML и Shadow DOM.

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

Однако из этой превосходной статьи о разработчиках Google о пользовательских элементах v1:

Имя пользовательского элемента должно содержать тире ( -). Итак <x-tags>, <my-element>и <my-awesome-app>все действительные имена, а <tabs>и <foo_bar>нет. Это требование заключается в том, что анализатор HTML может отличать пользовательские элементы от обычных элементов. Это также обеспечивает прямую совместимость при добавлении новых тегов в HTML.

Некоторые ресурсы

jessegavin
источник
3
Это хороший ответ (+1), но правило несколько круглое. «Пользователи не должны делать то, что не разрешено ...»
Alohci
8
@Alohci, вы должны были добавить следующие 3 слова в вашу цитату: «по этой спецификации».
jessegavin
1
Я также прочитал эту часть спецификации, и это действительно смутило меня. И вот почему: 1) настраиваемые атрибуты разрешены в HTML5. Это подтверждает круговую аргументацию Алочи. 2) Нигде в спецификации не говорится, что пользовательские элементы не разрешены.
d13
Эта цитата в лучшем случае расплывчата. Конечно, W3C имеет более конкретную позицию, так или иначе?
Вспышка
2
Эта ссылка на customelements.io больше не нужна. Не могли бы вы обновить / удалить его?
Нисарг
22

Это возможно и разрешено:

Пользовательские агенты должны рассматривать элементы и атрибуты, которые они не понимают, как семантически нейтральные; оставляя их в DOM (для процессоров DOM) и стилизуя их в соответствии с CSS (для процессоров CSS), но не выводя из них никакого значения.

http://www.w3.org/TR/html5/infrastructure.html#extensibility-0

Но, если вы намереваетесь добавить интерактивность, вам нужно сделать ваш документ недействительным (но все же полностью функциональным), чтобы соответствовать IE 7 и 8.

См. Http://blog.svidgen.com/2012/10/building-custom-xhtml5-tags.html (мой блог)

svidgen
источник
Похоже, вы не читали весь этот раздел. Мало того, что это в основном об атрибутах , это даже сильно препятствует настройке.
Эндрю Барбер
Повторяя мои другие комментарии, да, извините, я не знал, чтобы указать, что это мой блог. Я предположил, что многое было очевидно. Статья имеет прямое отношение, хотя. И я добавлю, это не предназначено для того, чтобы служить справкой для поддержки любых «претензий», которые я выдвинул, но чтобы показать в более длинном формате, как это сделать, чтобы оно работало.
svidgen
1
Дело просто в следующем: спецификация явно разрешает эти вещи. И в большинстве случаев обескураживающего поведения спецификация довольно четко говорит с поставщиками пользовательских агентов, а не авторами HTML.
svidgen
3
Это утверждение, приведенное выше, похоже, было удалено в самой последней версии w3.org/TR/html5/introduction.html#extensibility . До сих пор я не могу найти никакой документации о том, может ли использование пользовательских элементов HTML без дефиса быть допустимым или нет, или вам нужны операторы JS для проверки пользовательских элементов HTML с дефисами ( html5rocks.com/en/tutorials/webcomponents/ обычаи ).
Джон Слегерс
@JohnSlegers Да, похоже, документация и / или привязка были немного переставлены. Я обновил ссылку. Цитата в моем ответе находится в нижней части раздела « Расширяемость ».
svidgen
14

NB. Приведенный ниже ответ был верным, когда он был написан в 2012 году. С тех пор все немного изменилось. Спецификация HTML теперь определяет два типа пользовательских элементов - «автономные пользовательские элементы» и «настраиваемые встроенные элементы». Первый может идти везде, где ожидается фразовое содержание; это большинство мест внутри тела, но не, например, дочерние элементы элементов ul или ol или элементов таблицы, отличных от элементов td, th или caption. Последние могут идти туда, куда может пойти элемент, который они расширяют.


Это на самом деле является следствием накопления контентной модели элементов.

Например, корневой элемент должен быть htmlэлементом.

htmlЭлемент может содержать только головной элемент , за которым следует элемент тела.

bodyЭлемент может содержать только содержимое потока , где содержание потока определяются как элементы: a, abbr, адрес, область (если это потомок элемента карты), статья, в стороне, аудио, b, bdi, bdo, blockquote, br, кнопка, холст, ссылаться, код, команда, список данных, del, подробности , dfn, div dl, em, embed, fieldset, рисунок, нижний колонтитул, форма, h1, h2, h3, h4, h5, h6, заголовок, hgroup, hr, i, iframe, img, ввод, ins, kbd, keygen, метка, карта, метка, математика, меню, метр, навигация, noscript, объект, ol, output, p, pre, progress, q, ruby, s, samp, script, section, select, small, span, strong, style ( если атрибут scoped присутствует), sub, sup, svg, table, textarea, time,u, ul, var, видео, wbr и текст

и так далее.

Модель контента ни в коем случае не говорит: «Вы можете поместить в нее любые элементы, которые вам нравятся», что было бы необходимо для пользовательских элементов / тегов.

Alohci
источник
Итак, мы можем предположить, что если пользовательские элементы не упомянуты, то они также не разрешены. Это кажется достаточно справедливым.
d13
4
Этот ответ теперь недействителен, новый стандарт пользовательских элементов веб-компонентов W3 начинает появляться в браузерах: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/…
csuwldcat
1
@csuwldcat - На самом деле нет. Стандарт HTML5 или более поздней версии все равно нуждается в обновлении, чтобы такие пользовательские элементы стали частью его модели содержимого. Это интересные новости, хотя. В каких браузерах я могу их использовать?
Alohci
3
@Alochi - очевидно, что любые другие спецификации со старым языком нужно будет обновить, чтобы отразить эту новую реальность, но HTML является живым стандартом и не блокирует другие спецификации - обновления будут сделаны, как только мы перейдем к следующим этапам стандарта отслеживать. Вы можете поиграть с нативными реализациями веб-компонентов в Chrome Canary, а вскоре и в Firefox Aurora. Кроме того, для 3 из 4 спецификаций веб-компонентов доступны полифилы, которые очень хорошо работают во всех современных браузерах модеров, включая спецификации и функции пользовательских элементов.
csuwldcat
То есть пользовательские элементы могут быть размещены в определенных местах? Или вы говорите, что они вообще не разрешены?
Мелаб
12

Основные пользовательские элементы и атрибуты

Пользовательские элементы и атрибуты действительны в HTML при условии, что:

  • Имена элементов строчные и начинаются с x-
  • Имена атрибутов строчные и начинаются с data-

Например, <x-foo data-bar="gaz"/>или <br data-bar="gaz"/>.

Общая конвенция для элементов x-foo; x-vendor-featureРекомендовано.

Это справляется с большинством случаев, поскольку, возможно, редкость тому, что разработчику потребуется вся мощь, связанная с регистрацией их элементов. Синтаксис также адекватно действителен и стабилен. Более подробное объяснение ниже.

Расширенные пользовательские элементы и атрибуты

По состоянию на 2014 год появился новый, значительно улучшенный способ регистрации пользовательских элементов и атрибутов. Он не будет работать в старых браузерах, таких как IE 9 или Chrome / Firefox 20. Но он позволяет вам использовать стандартный HTMLElementинтерфейс, предотвращать коллизии, использовать неназванные x-*и неназванные data-*имена и определять пользовательское поведение и синтаксис, которые браузер должен соблюдать , Это требует немного причудливого JavaScript, как подробно описано в ссылках ниже.

HTML5 Rocks - Определение новых элементов в HTML
WebComponents.org - Введение в пользовательские элементы
W3C - Веб-компоненты: пользовательские элементы

Относительно обоснованности основного синтаксиса

Использование data-*пользовательских имен атрибутов в течение некоторого времени было вполне допустимо и даже работает со старыми версиями HTML.

W3C - HTML5: расширяемость

Что касается пользовательских (незарегистрированных) имен элементов, W3C настоятельно рекомендует против них и считает их несоответствующими. Но браузеры обязаны поддерживать их, и x-*идентификаторы не будут конфликтовать с будущими спецификациями HTML, а x-vendor-featureидентификаторы не будут конфликтовать с другими разработчиками. Пользовательский DTD может использоваться для работы с любыми требовательными браузерами.

Вот некоторые соответствующие выдержки из официальных документов:

«Применимые спецификации МОГУТ определять новое содержимое документа (например, элемент foobar) [...]. Если синтаксис и семантика данного соответствующего документа HTML5 не изменяются при использовании соответствующих спецификаций, то этот документ остается соответствующим HTML5 документ."

«Пользовательские агенты должны обрабатывать элементы и атрибуты, которые они не понимают как семантически нейтральные; оставлять их в DOM (для процессоров DOM) и стилизовать их в соответствии с CSS (для процессоров CSS), но не выводить из них никакого значения».

«Пользовательские агенты не могут свободно обрабатывать несогласованные документы по своему усмотрению; модель обработки, описанная в этой спецификации, применяется к реализациям независимо от соответствия входных документов».

«Интерфейс HTMLUnknownElement должен использоваться для элементов HTML, которые не определены в этой спецификации».

W3C - HTML5: соответствие документов
WhatWG - Стандарт HTML: элементы DOM

Beejor
источник
11

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

  1. Следует ли считать HTML-документ с пользовательскими тегами допустимым HTML5? Ответ на это явно "нет". Спецификация указано, какие именно теги допустимы в каких контекстах. Вот почему средство проверки HTML не будет принимать документ с пользовательскими тегами или со стандартными тегами в неправильных местах (например, тег «img» в заголовке).

  2. Будет ли HTML-документ с пользовательскими тегами обрабатываться и отображаться стандартным, четко определенным образом в браузерах? Здесь, возможно, удивительно, ответ «да». Даже если документ технически не будет считаться допустимым HTML5, спецификация HTML5 точно определяет , что именно должны делать браузеры, когда они видят пользовательский тег: короче говоря, пользовательский тег действует примерно как <span>- он ничего не значит и ничего не делает с помощью по умолчанию, но он может быть стилизован под HTML и доступен через javascript.

мистифицировать
источник
5

Пользовательские элементы HTML - это новый стандарт W3, в который я внес вклад, который позволяет вам объявлять и регистрировать пользовательские элементы с помощью анализатора. Вы можете прочитать спецификацию здесь: Спецификация пользовательских элементов веб-компонентов W3 . Кроме того, Microsoft поддерживает библиотеку (написанную бывшими разработчиками Mozilla), которая называется X-Tag - это делает работу с веб-компонентами еще проще.

csuwldcat
источник
1
Этот проект принят?
Starx
Части приземляются в Firefox и Chrome - мы тесно сотрудничаем и ожидаем, что к концу 2013 года будут
внедрены
1
Теперь 2014, есть полные реализации приземлились?
Хасиб Махмуд
1
@JamieHutber и увидим, как ваши веб-страницы ломаются в последних браузерах через год. Правило № 1 для совместимости браузера: игра по правилам.
Мистер Листер
1
@HasibMahmud спецификации теперь доработаны, и через пару недель появятся на Chrome Beta, Firefox Aurora через ~ 6 недель. Вы можете использовать их в Firefox Aurora сегодня, переключив флаг конфигурации dom.webcomponents.enabledна true.
csuwldcat
4

Чтобы дать обновленный ответ, отражающий современные страницы.

Пользовательские теги действительны, если либо,

1) они содержат тире

<my-element>

2) Они встроены в XML

<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>

Это предполагает, что вы используете тип документа HTML5 <!doctype html>

Учитывая эти простые ограничения, теперь имеет смысл сделать все возможное, чтобы ваша HTML-разметка была действительной (пожалуйста, прекратите закрывать такие теги, как <img>и <hr>, это глупо и неправильно, если вы не используете тип документа XHTML, который вам, вероятно, не нужен).

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

Хенрик Вендельбо
источник
3

Цитирование из раздела «Расширяемость» спецификации HTML5 :

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

Поэтому, если вы используете сериализацию XML для HTML5, вы можете сделать что-то вроде этого:

<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>

Однако, если вы используете синтаксис HTML, вы гораздо более ограничены в своих действиях.

Для функций уровня разметки, предназначенных для использования с синтаксисом HTML, расширения должны быть ограничены новыми атрибутами формы «x-vendor-feature» [...] Не следует создавать новые имена элементов.

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

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

Для более подробного ознакомления с предметом ознакомьтесь с разделом «Введение в веб-компоненты» , в котором также содержится информация о Shadow DOM и другие соответствующие спецификации. Эти спецификации все еще находятся в стадии разработки - вы можете увидеть текущий статус здесь - но они активно развиваются.

Например, простое определение greetingэлемента может выглядеть примерно так:

<element name="greeting">
  <template>
    <style scoped>
      span { color:gray; }
    </style>
    <span>Simon says:</span>
    <q><content/></q>
  </template>
</element>

Это говорит браузеру отображать содержимое элемента в кавычках с префиксом текста «Саймон говорит:», который оформлен в сером цвете. Как правило, пользовательское определение элемента, подобное этому, будет храниться в отдельном html-файле, который вы импортируете со ссылкой.

<link rel="import" href="greeting-definition.html" />

Хотя вы также можете включить его, если хотите.

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

Джеймс Холдернесс
источник
2

просто используйте все, что вы хотите, без декларации DOM

<container>content here</container>

добавьте свой собственный стиль (display: block), и он будет работать с любым современным браузером

Эрик Бойло
источник
1

data-*атрибуты действительны в HTML5 и даже в HTML4 во всех веб-браузерах, которые их уважают. Добавление новых тегов технически нормально, но не рекомендуется только потому, что:

  1. Это может конфликтовать с чем-то, что добавлено в будущем, и
  2. Делает HTML-документ недействительным, если он не добавлен динамически через JavaScript.

Я использую пользовательские теги только в тех местах , что Google не заботится, для ecample в IFRAME игрового движка, я сделал <log>тег , который содержал <msg>, <error>и <warning>- но через JavaScript только. И это было полностью в силе, по словам валидатора. Он даже работает в Internet Explorer со своим стилем! ;]

Петър Петров
источник
1
Он был действителен для валидатора, потому что вы создавали эти элементы с помощью JavaScript, а валидатор их не видел, потому что он не запускает ваш JavaScript. Он будет видеть только ту страницу, которая отображается при первой загрузке.
animuson
Именно. Хотя HTML не является допустимым, пользовательские теги все еще являются действительными SGML, а HTML в конце концов является SGML. CSS можно использовать для стилизации пользовательских тегов, и он отлично работает в IE. :) Кроме того, вы можете указать свое собственное DTD с собственными пользовательскими элементами в спецификации DOCTYPE, так что мои пользовательские теги могут действительно проверяться даже без JavaScript - но мне все равно - система графического интерфейса игрового движка определенно не Google работа :)
Петър Петров
1
Ну, тут есть подвох. Вы не можете просто добавить пользовательские элементы. Вы должны определить и зарегистрировать их в DTD, чтобы они считались «действительными» HTML. То, что что-то работает, не значит, что оно действительно.
animuson
Если вы просто добавите квалификатор к именам элементов, таким как <x-msg>, <x-log> и т. Д., То вы будете соответствовать спецификации Web Components / Custom Elements.
Нил Монро
В игровом движке, где Webkit предназначен только для визуализации вашего динамического графического интерфейса, никто не будет заботиться о DTD. Любой неизвестный тэг HTML является HTMLUnknownElement для JS, до сих пор прекрасно работает с JQuery и CSS, так что ваш GUI получает некоторую семантику в конце: <inventory>, <item type="potion" sprite="2">- так это лучше назвать SGML + CSS , а не HTML, несмотря на это HTML элементы , которые имеют определение работать как есть - кнопки, списки, ...
Петър Петров
1

Пользовательские теги недопустимы в HTML5. Но в настоящее время браузеры поддерживают их анализ, а также вы можете использовать их с помощью CSS. Так что если вы хотите использовать пользовательские теги для текущих браузеров, тогда вы можете. Но поддержка может быть отменена, когда браузеры реализуют стандарты W3C строго для анализа содержимого HTML.

Нисарг шах
источник
1
Может быть, это произойдет, когда они перестанут поддерживать <center>и <marquee>?
Равенстин
1

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

<button id="find">click me</button>
<Query? ?attach="find" ?content="alert( find() );" ?prov="Hello there :D" >
I won't be displayed :D
</Query?>

<style type="text/css">

[\?content] {

display: none;

}

</style>

<script type="text/javascript">

S = document.getElementsByTagName("Query?")[0];

Q = S.getAttribute("?content");

A = document.getElementById( S.getAttribute("?attach") );

function find() {

  return S.getAttribute("?prov");

}

(function() {

A.setAttribute("onclick", Q);

})();

</script>

будет работать отлично (пока в новых версиях Google Chrome, IE, FireFox и мобильных Safari). Все, что вам нужно, это просто буквенный символ (az, AZ), чтобы начать тег, а затем вы можете использовать любой из не буквенных символов. Если в CSS вы должны использовать «\» (обратную косую черту), чтобы найти элемент, например, потребуется Query \ ^ {...}. Но в JS вы просто называете это так, как видите. Я надеюсь, что это поможет. См пример здесь

-Минк CBOS

Эпхелон Данцлер
источник
3
Это самый странный HTML, который я видел за последнее время :)
Дэн Даскалеску,