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

151

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

<greeting>Hello!</greeting>

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

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

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

  • 2
    Возможно, вы не захотите добавлять слишком много информации в статью HTML5, написанную более 4,5 лет назад.
  • 9
    Статья Крокфорда странная. Важное предложение звучит так: «Это мое предложение по более мягкому, более мягкому HTML 5». Другими словами, это не тот HTML5, который мы знаем сегодня, а предложение о другом HTML 5 в качестве преемника HTML 4. Странно, потому что он датирован ноябрем 2007 года, когда W3C уже почти год работал над HTML5. , Его использование слова «разрешено» здесь сбивает с толку. Пользовательские теги никогда не были «соответствующими» / «действительными», но анализаторы браузера продолжают работать в их присутствии. Так или иначе, предложение Крокфорда не получило никакой силы. Едва ли какая-то его часть включена в HTML5.
Показать ещё 6 комментариев
Теги:
tags
element
custom-element

11 ответов

151
Лучший ответ

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

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

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

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

Однако из этого отличная прогулка по статье в Google Developers о Custom Elements v1:

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

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

  • 3
    Это хороший ответ (+1), но правило несколько круглое. «Пользователи не должны делать то, что не разрешено ...»
  • 7
    @Alohci, вы должны были добавить следующие 3 слова в вашу цитату: «по этой спецификации».
Показать ещё 8 комментариев
14

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

Пользовательские агенты должны обрабатывать элементы и атрибуты, которые они не используют понимать как семантически нейтральные; оставляя их в 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 (мой блог)

  • 0
    Похоже, вы не читали весь этот раздел. Мало того, что это в основном об атрибутах , это даже сильно препятствует настройке.
  • 0
    Повторяя мои другие комментарии, да, извините, я не знал, чтобы указать, что это мой блог. Я предположил, что многое было очевидно. Статья имеет прямое отношение, хотя. И я добавлю, это не предназначено для того, чтобы служить справкой для поддержки каких-либо «претензий», которые я выдвинул, но чтобы показать в более длинном формате, как это сделать, чтобы оно работало.
Показать ещё 5 комментариев
14

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

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

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

Элемент body может содержать Flow content, где содержимое потока определяется как элементы: a,   сокр,   адрес,   (если он является потомком элемента карты),   статья,   в стороне,   аудио,   б,   BDI,   БДО,   BLOCKQUOTE,   ш,   кнопка,   холст,   процитировать,   код,   команда,   DataList,   дель,   Детали,   д.ф.н.,   ДИВ   дл,   Эм,   встраивать   FIELDSET,   фигура,   сноска,   форма,   h1,   h2,   h3,   h4,   h5,   h6,   заголовок,   HGroup,   час,   я,   IFrame,   IMG,   вход,   ины,   KBD,   серийник,   метка,   карта,   отметка,   математика,   меню,   метр,   нав,   NoScript,   объект,   ол,   вывод,   п,   заранее,   прогресс,   кв,   Рубин,   s,   сэмпл,   script,   раздел,   Выбрать,   маленький,   пролет   сильный,   style (если присутствует атрибут scoped)   к югу,   вир   .SVG,   Таблица,   текстовое поле,   время,   и,   ул,   вар,   видео,   WBR   и текст

и т.д.

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

  • 0
    Итак, мы можем предположить, что если пользовательские элементы не упомянуты, они также не разрешены. Это кажется достаточно справедливым.
  • 3
    Этот ответ теперь недействителен, теперь в браузерах начинает появляться новый стандарт пользовательских элементов W3 Web Components: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/…
Показать ещё 4 комментария
7

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

Пользовательские элементы и атрибуты действительны в 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 element) [...]. Если синтаксис и семантика данного Соответствующий документ HTML5 не изменяется при использовании применимых спецификация (ы), то этот документ остается соответствующим HTML5 документ".

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

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

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

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

4

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

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

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

4

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

  • 1
    Этот проект принят?
  • 0
    Части появляются в Firefox и Chrome - мы тесно сотрудничаем и ожидаем, что к концу 2013 года будут внедрены полные реализации.
Показать ещё 10 комментариев
3

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

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

Итак, если вы используете сериализацию XML HTML5, вам будет разрешено сделать что-то вроде этого:

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

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

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

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

Однако для автора, хотя может быть законным встраивать пользовательский элемент на страницу (по крайней мере, в сериализацию XML), вы не получите ничего, кроме node в 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 - более поздние версии работают совсем по-другому. Однако, поскольку спецификация все еще находится в разработке, это не то, что я бы рекомендовал использовать в производственном коде в любом случае.

1

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

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

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

<my-element>

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

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

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

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

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

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 до сих пор). Все, что вам нужно, это просто альфа-символ (a-z, A-Z), чтобы запустить тег, а затем вы можете использовать любой из символов без альфа. Если в CSS вы должны использовать "\" (обратную косую черту), чтобы найти элемент, например, потребуется Query\^ {...}. Но в JS вы просто называете это, как видите. Надеюсь, это поможет. Пример здесь

-Mink CBOS

  • 2
    Это самый странный HTML, который я видел за последнее время :)
1

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

  • 0
    Может быть, это произойдет, когда они перестанут поддерживать <center> и <marquee> ?
0

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

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

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

  • 1
    Он был действителен для валидатора, потому что вы создавали эти элементы с помощью JavaScript, а валидатор их не видел, потому что он не запускает ваш JavaScript. Он будет видеть только ту страницу, которая отображается при первой загрузке.
  • 0
    Именно так. Хотя HTML не является допустимым, пользовательские теги все еще являются действительными SGML, а HTML в конце концов является SGML CSS можно использовать для стилизации пользовательских тегов, и он отлично работает в IE. :) Кроме того, вы можете указать свое собственное DTD со своими собственными элементами в спецификации DOCTYPE, так что мои пользовательские теги могут фактически проверяться даже без JavaScript - но мне все равно - система графического интерфейса игрового движка определенно не Google работа :)
Показать ещё 4 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню