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

Ответ 4

Да, мы можем.

Существует новая спецификация о пользовательских элементах/тегах - http://w3c.github.io/webcomponents/spec/custom/.

Только с этим вы должны использовать js для регистрации нового элемента

Подробнее об этом можно узнать в

https://developers.google.com/web/fundamentals/getting-started/primers/customelements

Ответ 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

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