Можно ли использовать неизвестные теги HTML?

Поправьте меня, если я ошибаюсь, но AFAIK, неизвестные теги HTML в разметке (то есть теги, не определенные в спецификации HTML, например, <foobar>), в конечном итоге будут рассматриваться как обычный <div> в среде браузера HTML 5.

Я думаю: насколько эта практика поддерживается? Я имею в виду, если я использую неизвестные теги HTML в моей разметке, какие подводные камни я могу ожидать? Может ли в ближайшие несколько секунд на меня обрушится велоцираптор?

Причина, по которой я спрашиваю, состоит в том, что если эти теги откладываются до <div>, я потенциально могу использовать эти теги более семантическим образом, чем, скажем, назначение имен классов, которые идентифицируют модули. Взгляните на эту статью, например, класса .media. Теперь, что если вместо того, чтобы записать этот CSS для таргетинга на .media, я сделаю вместо него таргетинг на <media>? По моему мнению, это делает разметку намного более читабельной и понятной, но я признаю, что это не "правильный" HTML.

РЕДАКТИРОВАТЬ

Просто чтобы быть прозрачным, я нашел этот вопрос несколько лет назад. Это было закрыто как не по теме, но я чувствую, что у меня есть верный смысл в моей собственной формулировке. Я признаю, что это близкий дубликат, но он был сделан несколько лет назад, поэтому, возможно, произошли изменения в общей среде мнений веб-разработчиков по этой теме.

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

В 2015 году мы находимся на пороге CustomElement, который широко используется, и полиполны легко доступны. Сейчас самое время подумать о том, как "создать свои собственные элементы". В ближайшем будущем вы сможете создавать новые элементы с собственным выбором тегов и поведения в полностью стандартном и поддерживаемом способе, которым все могут любить. Но пока это не будет во всех браузерах, и пока большинство людей не будут использовать поддерживающие браузеры, вы можете воспользоваться тяжелой работой Polymer или X-Tags, чтобы проверить будущее пользовательских элементов почти стандартным и в основном поддерживаемым способом, которым может понравиться немало людей, Это, вероятно, "правильная вещь". Но он не отвечает на ваш вопрос, и, откровенно говоря, я считаю, что "просто использовать X" или "не делать X" менее полезно, чем "здесь, как спецификация охватывает это, и вот что делают браузеры". Итак, вот что я люблю.

Против сердечной рекомендации (а иногда и крика) большей части сообщества веб-разработчиков, я работал с элементами "готового" за последний год во всех моих производственных проектах без polyfill, и у меня не было неразрешимых проблем (пока) и никаких жалоб. Как? Основываясь на стандартном поведении HTMLUnknownElement, является частью спецификации W3C, которая охватывает случай "созданных" элементов. Если браузер встречает непризнанный элемент HTML, существует четкий и однозначный способ его обработки, а HTMLUnknownElement определяет это поведение, и вы можете построить его поверх этого. HTMLUnknownElement также должен быть достаточно мощным и достаточно корректным, чтобы "не нарушать Интернет", когда сталкивался со всеми тегами, которые теперь устарели, например тегом <blink>. Не рекомендуется использовать HTMLUnknownElement, но теоретически и на практике абсолютно никакого вреда в этом, если вы знаете, что делаете.

Как работает HTMLUnknownElement? Это просто расширение интерфейса HTMLElement, который является стандартным интерфейсом, лежащим в основе всех элементов HTML. Однако, в отличие от большинства других элементов, HTMLUnknownElement не добавляет никакого особого поведения - вы получаете необработанный элемент, который не имеет никакого особого поведения и не ограничивает правила использования. HTMLDivElement интерфейс работает практически точно так же, расширяя HTMLElement и добавляя почти никакого дополнительного поведения. Проще говоря, составление собственного элемента почти идентично использованию div или span.

То, что мне нравится в "составляющих" элементах, - это изменение мышления. Вы должны использовать HTML-элементы или изобретать, основываясь на нескольких факторах: от того, насколько ясно читается разметка, как браузеры и программы чтения с экрана и поисковые системы анализируют ваш код, насколько вероятен ваш код быть "правильным" с помощью некоторой объективной меры. Я экономно использую составленные элементы, но я использую точно так, как это описано Ричардом, чтобы сделать вещи более значимыми для автора HTML, а не только для компьютерной службы, которая извлекает метаданные. При постоянном использовании в команде, может быть большое преимущество, поскольку созданные элементы могут кратко выразить, за что они предназначены.

Мне особенно нравится использовать созданные элементы, чтобы указать, когда я буду использовать JS для определения дополнительного поведения для элемента. Например, если у меня есть элемент, который будет иметь дочерние элементы, добавленные/удаленные JS, я буду использовать созданный элемент как ключ к тому, что этот элемент подвержен специальному поведению. Точно так же я не использую готовый элемент, когда будет достаточно стандартного элемента. Вы увидите <dynamic-list> счастливо рядом с <div> в моем коде.

Теперь о тех надоедливых валидаторах. Да, использование созданных элементов не является "действительным" в том смысле, что оно не пройдет "валидатор". Но многие часто используемые функции, шаблоны и системы разработки современных HTML и JS не позволяют выполнять все валидаторы W3C. Валидаторы не являются законом - спецификация. И закон не является обязательным - реализации во всех браузерах. Утилита валидаторов в течение многих лет уменьшалась, поскольку гибкость HTML возрастала, и как браузеры изменили свое отношение к спецификации. Валидаторы отлично подходят для людей, которым неудобно работать с HTML и нужно руководствоваться. Но если вам удобно брать руководство от спецификации и от реализаций браузера, нет никаких оснований беспокоиться о том, чтобы быть завален валидатором. Разумеется, если вы будете следовать многим рекомендациям, предлагаемым Google, Apple, Microsoft и т.д., Для реализации каких-либо экспериментальных функций, вы будете работать за пределами валидатора. Это абсолютно нормально делать, если вы делаете это намеренно, и вы достаточно знаете о том, что делаете.

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

  • Вам нужно использовать дефис в имени вашего тега. Если вы это сделаете, вы никогда не столкнетесь с будущей версией спецификации HTML. Поэтому никогда не говори <wrong>, всегда скажите <quite-right>.

  • Элементы, созданные при создании, не могут быть самозакрывающимися - вам нужно закрыть их закрывающим тегом. Вы не можете просто сказать <wrong> или <still-wrong />, вы должны сказать <totally-good></totally-good>.

  • Вам нужно определить свойство display для вашего элемента в CSS, иначе поведение рендеринга undefined.

Что об этом. Если вы это сделаете, вы должны хорошо использовать элементы с элементами в IE9 и выше, опираясь на защитную сеть HTMLUnknownElement. Для меня преимущества далеко, намного перевешивают затраты, поэтому я сильно использовал этот шаблон. Я запускаю сайт SaaS, обслуживающий крупные промышленные корпорации, и до сих пор у меня не было никаких проблем или жалоб. Если вам нужно поддерживать более старые версии IE, разумно оставаться вдали от любой технологии "2015" или их грубых приближений и оставаться в безопасности в хорошо проторенных частях спецификации.

Итак, в заключение, ответ на ваш вопрос "да, если вы знаете, что делаете".

Ответ 3

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

Ответ 5

Правило № 1 совместимости браузера: нет ошибок. Независимо от того, сколько браузеров вы тестируете, всегда есть браузеры, которые вы не можете тестировать, например, потому что они еще не существуют.
Кроме того, в большинстве браузеров в настоящее время неизвестные элементы будут обрабатываться как <span>, а не <div>.

Если вы действительно читаете исходную информацию (*), вы должны изучить XML + XSLT.
Таким образом, вы можете использовать все теги, которые хотите, и заставить их вести себя так, как вам нравится, и вам не нужно беспокоиться о том, что <media> будет реальным элементом в какой-либо будущей версии HTML.

Один хороший пример реального мира - это элемент <picture>. Если веб-сайт когда-либо использовал <picture> и полагался на представление о том, что этот элемент не будет иметь никаких стилей или специального контента сам по себе, они сейчас в беде!

(*) С XML + XSLT читаемость, очевидно, будет в части XML, а не в части XSLT.

Ответ 6

В моем случае я использую многие из них в моей графической системе GUI, основанной на Webkit, и все работает.

Ответ 7

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

Ответ 8

В вашем примере вы говорите о <media>, это может быть здорово, но если html6 добавит этот тег для другого элемента, ваш код не будет совместим с версией.

Ответ 9

Обычно не рекомендуется, например. IE не применит CSS-стили к неизвестным тегам.

Все другие браузеры отображают неизвестные теги как inline -Elements (что вызывает проблемы с вложением).

Я рекомендую вам следующую статью: http://diveintohtml5.info/ Существует раздел об неизвестных тегах.

Ответ 10

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

Поэтому как насчет этого: вместо пользовательских тегов используйте "div" + собственный CSS-класс.

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

Вместо div вы можете использовать span для той же цели. Я хотел бы использовать что-то более короткое на самом деле, скажем p, но, к сожалению, p имеет свое особое поведение, которое происходит, если вы не закрываете его.

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

Ответ 11

W3C говорит:

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

Вот источник: https://www.w3schools.com/html/html5_browsers.asp

Ответ 12

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