Почему CSS работает с поддельными элементами?


438

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

Пример:

imsocool {
    color:blue;
}
<imsocool>HELLO</imsocool>

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

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

Кроме того, почему он не знал, что готовые элементы существуют и работают с CSS. Они необычные?


62
HTML - это способ придания значения данным, который может быть понят широким кругом средств (включая людей и браузеры). Ваши выдуманные теги не добавляют никакого смысла. Это одна из многих причин, почему он не хочет, чтобы вы их использовали.
punkrockbuddyholly

59
@MrMisterMan на самом деле я думаю, что они делают. Что более <p>555-212-2344</p>значимо - или <supportPhone> 555-212-2344 </ supportPhone>
Юрий Галантер

169
@YuriyGalanter <p class = "supportPhone">; P
punkrockbuddyholly

30
@MrMisterMan Просто помните, что все эти правила и программные конструкции были созданы людьми не умнее вас, и вы можете изменить это, вы можете влиять на это, вы можете создавать свои собственные вещи, которые могут использовать другие люди.
L_7337

90
Я мог бы отметить, что то, что вы делаете, это в основном XML, а не HTML. XML является более абстрактным языком разметки, который позволяет вам представлять данные «полезным» способом, который вы описываете - т.е. с семантическим значением прилагается. Затем вы можете использовать XSLT-преобразование для рендеринга ваших данных в HTML
ose

Ответы:


470

Почему CSS работает с поддельными элементами?

(Большинство) браузеров предназначены для (до некоторой степени) прямой совместимости с будущими дополнениями к HTML. Нераспознанные элементы анализируются в DOM, но с ними не связаны семантика или специализированная отрисовка по умолчанию.

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

(Хотя следует отметить, что ведется работа по определению средств расширения HTML с помощью пользовательских элементов , но в настоящее время эта работа находится на ранней стадии разработки, поэтому ее, вероятно, следует избегать до тех пор, пока она не станет зрелой.)

Почему мой профессор не хочет, чтобы я использовал выдуманные элементы?

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

Также; почему он не знал, что готовые элементы существуют и работают с CSS. Они необычные?

Да. Люди не используют их, потому что у них есть вышеуказанные проблемы.


30
«Они не разрешены спецификацией HTML» Не обязательно верно. Они не соответствуют спецификации пространства имен HTML, но спецификация HTML5 является гораздо более широкой вещью, которая допускает создание пользовательских спецификаций, и прямо указывает, как обрабатывать такие вещи в отношении обработки CSS и API (DOM).
Бен Леш

4
Уже есть библиотеки, особенно Angular.js, которые позволяют расширять HTML с помощью пользовательских элементов. Возможно, не в том смысле, что вы имеете в виду, поскольку элементы просто анализируются с помощью javascript и обычно переводятся в реальные, но если вы хотите расширить html с помощью пользовательских тегов, вы можете сделать это с Angular
Charlie Martin

11
+1 За «Они могут конфликтовать с будущими стандартами». Помните, что это может сработать сейчас, но оно должно работать в течение 3-4 лет после того, как вы начали.
Tim.baker

70
Мне нравится иметь тег <ninja>, чтобы скрывать элементы dom вместо применения отображения стиля: нет, например: <ninja> Некоторые скрытые вещи </ ninja>
kiranvj

18
Еще один действительно важный момент: специальные браузеры для слепых или людей с ограниченными возможностями могут использовать правильные элементы HTML для разных целей (например, упростить навигацию по страницам, следуя заголовкам). Таким образом, отсутствующая семантика + рендеринг по умолчанию может не сильно повлиять на обычные браузеры, но эти специальные браузеры, вероятно, будут сбиты с толку, что резко снизит удобство использования вашего веб-сайта.
Арве Систад

98

TL; DR

  • Пользовательские теги недопустимы в HTML. Это может привести к проблемам рендеринга.
  • Делает дальнейшую разработку более сложной, поскольку код не переносим.
  • Действительный HTML предлагает много преимуществ, таких как SEO, скорость и профессионализм.

Длинный ответ

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

Однако это приводит к неверному HTML. Что не хорошо для вашего сайта.

Точка правильного CSS / HTML | Переполнение стека

  • Google предпочитает это, так что это хорошо для SEO.
  • Это повышает вероятность того, что ваша веб-страница будет работать в браузерах, которые вы не тестировали.
  • Это заставляет вас выглядеть более профессионально (по крайней мере, для некоторых разработчиков)
  • Совместимые браузеры могут рендерить [правильный HTML быстрее]
  • Он указывает на кучу неясных ошибок, которые вы, вероятно, пропустили и которые влияют на вещи, которые вы, вероятно, еще не тестировали, например на кодовую страницу или языковой набор страницы.

Зачем проверять | W3C

  • Валидация как инструмент отладки
  • Валидация как проверка качества на будущее
  • Валидация облегчает обслуживание
  • Валидация помогает учить хорошим практикам
  • Валидация является признаком профессионализма

8
Еще один аргумент в пользу правильного кода: если вам нужно передать другому разработчику или вы работаете в команде, другие участники или новый разработчик должны немедленно понять, чего вы пытаетесь достичь. , , С недействительными, составленными тегами это может стать очень трудным ...
Пэт Добсон

9
AKA. Будущее развитие и облегчение обслуживания.
Дэн Гран

68

YADA (еще один (другой) ответ)

Изменить: Пожалуйста, смотрите комментарий от BoltClock ниже относительно типа против тега против элемента. Я обычно не беспокоюсь о семантике, но его комментарий очень уместен и информативен.

Хотя уже есть множество хороших ответов, вы указали, что ваш профессор побудил вас опубликовать этот вопрос, чтобы вы (формально) учились в школе . Я подумал, что немного подробнее расскажу не только о CSS, но и о механике веб-браузеров. Согласно Википедии , «CSS - это язык таблиц стилей, используемый для описания ... документа, написанного на языке разметки». (Я добавил акцент на «а») Обратите внимание, что в нем написано «написано в HTML» гораздо меньше, чем в конкретной версии HTML. CSS можно использовать в HTML, XHTML, XML, SGML, XAML и т. Д. Конечно, вам нужно что-то, что будет отображатьк каждому из этих типов документов также применяется стиль. По определению, CSS не знает / не понимает / не заботится о конкретных тегах языка разметки. Таким образом, теги могут быть «недействительными» в отношении HTML, но в CSS нет понятия «допустимый» тег / элемент / тип.

Современные визуальные браузеры не являются монолитными программами. Они представляют собой смесь различных «двигателей», которые выполняют определенную работу. Как минимум, я могу представить себе 3 движка, движок рендеринга, движок CSS и движок javascript / VM. Не уверен, является ли анализатор частью механизма рендеринга (или наоборот) или это отдельный механизм, но вы поняли идею.

Будь или не визуальный браузер ( другие уже обращался тем факт , что экран читатели могли бы иметь другие проблемы , касающиеся недействительными теги применяется) форматирование зависит от того , синтаксического анализатора листьев «недействительной» метки в документе , а затем применяет ли движок рендеринга стилей к этому тегу. Так как это усложнит разработку / поддержку, движки CSS не написаны так, чтобы понимать, что «это документ HTML, поэтому вот список допустимых тегов / элементов / типов». Механизмы CSS просто находят теги / элементы / типы и затем говорят механизму рендеринга: «Вот стили, которые вы должны применить». Вопрос о том, решит ли движок рендеринга на самом деле применить стили, зависит от него.

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

Этот ответ уже слишком длинный, поэтому я на этом закончу.


10
Хотя вы упомянули, что «теги» стали общим термином для элементов, с которым я не могу и не буду не согласиться, это не меняет того факта, что правильный термин для них по-прежнему «элементы». В частности, тег является синтаксической функцией HTML и XML и может отсутствовать в других языках документов, совместимых с CSS. Итак, утверждение о том, что CSS-стили «тегируют», как их часто называют люди, не совсем справедливо по отношению к языковой агностике CSS.
BoltClock

53

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

В старых браузерах (я думаю, IE7-) вы можете применить Javascript-трюк, после которого они также будут работать.

Вот связанный вопрос, который я нашел, когда искал пример.

Вот вопрос об исправлении Javascript . Оказывается, это действительно IE7, который не поддерживает эти элементы из коробки.

Также; почему он не знал, что выдуманные теги существуют и работают с CSS. Они необычные?

Да вполне. Но особенно: они не служат дополнительной цели. И они новички в html5. В более ранних версиях HTML неизвестный тег был недействительным.

Кроме того, учителя, кажется, иногда имеют пробелы в своих знаниях. Это может быть связано с тем фактом, что им необходимо обучать студентов основам данного предмета, и на самом деле не стоит знать все подробности и быть в курсе последних событий. Однажды меня playпосадили в тюрьму, потому что учитель думал, что я запрограммировал вирус, просто потому, что я мог заставить компьютер воспроизводить музыку, используя команду в GWBasic. (Правдивая история и да, давно). Но, какова бы ни была причина, я считаю, что совет не использовать привычные элементы является разумным.


3
@OnoSendai Вы заставили меня усомниться, но я действительно думаю, что они отображаются как «блочные элементы без дополнительной разметки», так что, в основном, как div.
GolezTrol

6
@OnoSendai Элемент блока может иметь свойство display блока , но это не обязательно. Например, теги привязки были повышены до статуса блока (это означает, что вы можете помещать в них блочные элементы, такие как div), но при этом все еще имеете встроенное свойство display.
cimmanon

8
Начальное значение displayравно inline, поэтому комментарий @ OnoSendai является правильным.
BoltClock

2
@cimmanon: aэлементы теперь имеют прозрачную модель содержимого, поэтому, являются ли они блочными или встроенными, зависит от того, является ли их предок блочным или встроенным. Этот ответ говорит о неизвестных элементах, для которых HTML не определяет модель содержимого. Что касается CSS, если в браузере нет displayзначения по умолчанию, используется начальное значение.
BoltClock

1
@ BoltClock'saUnicorn Значит ли это, что <div> <a> foo </a> <a> bar </a> </ div> будет отображать два тега <a> в виде блоков? Это кажется немного подозрительным ...
пушистый

27

На самом деле вы можете использовать пользовательские элементы. Вот спецификация W3C на эту тему:

http://w3c.github.io/webcomponents/spec/custom/

И вот учебник, объясняющий, как их использовать:

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

Как отметил @Quentin: это предварительная спецификация на ранних этапах разработки, и она накладывает ограничения на то, какими могут быть имена элементов.


7
Следует отметить, что это предварительная спецификация на ранних этапах разработки и что она накладывает ограничения на то, какими могут быть имена элементов.
Квентин

2
+1 Не знал, что использует W3C, githubно на самом деле они используют.
Витор Канова

22

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

FALSE (ish): нестандартные элементы HTML: «не разрешено», «запрещено» или «недействительно».

Не обязательно. Они "не соответствуют" . Какая разница? Что-то может «не соответствовать» и все же быть «разрешенным». W3C не собирается отправлять HTML-полицию к вам домой и отвозить вас.

W3C оставил вещи таким образом по причине. Соответствие и спецификации определяются сообществом. Если у вас есть небольшое сообщество, использующее HTML для более конкретных целей, и все они согласны с некоторыми новыми элементами, необходимыми для упрощения, они могут иметь то, что W3C называет «другими применимыми спецификациями» . (очевидно, что это слишком упрощенно, но вы поняли)

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

FALSE (МОГ): Нестандартные HTML элементы будут приводить к визуализации вопросов

Возможно, но вряд ли. (замените «будет» на «может»). Единственный способ, которым это может привести к проблеме рендеринга, - это если ваш пользовательский элемент конфликтует с другой спецификацией, такой как изменение спецификации HTML или другой спецификации, выполняемой в той же системе (такой как SVG, Math или что-то нестандартное).

Фактически, причина , по которой CSS может стилизовать нестандартные теги, заключается в том, что в спецификации HTML четко указано, что:

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

Примечание: если вы хотите использовать пользовательский тег, просто помните, что изменение спецификации HTML в более позднее время может привести к разрушению вашего стиля, поэтому будьте готовы. Однако очень маловероятно, что W3C будет реализовывать этот <imsocool>тег.

Нестандартные теги и JavaScript (через DOM)

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

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

TL; DR: Соответствие спецификации сделано для целей коммуникации и безопасности. Несоответствие по-прежнему допускается всем, кроме валидатора , единственной целью которого является обеспечение соответствия, но использование которого является необязательным.

Например:

var wee = document.createElement('wee');
console.log(wee.toString()); //[object HTMLUnknownElement]

(Я уверен, что это привлечет пламя, но есть мои 2 цента)


3
HTML не только определяет, как элементы должны обрабатываться в CSS, CSS-спецификация, по большей части, не зависит от языка документа по дизайну (это уже как бы подразумевается в некоторых других ответах, но я отмечу это здесь для удобство). Если есть любое поведение , которое является специфическим для HTML и / или XHTML, он всегда отображается , даже в информативный текст (например , «ID HTML - элемента задается idатрибутом»), а не только нормативный текст (см Фоновые и границ 3 в течение пример).
BoltClock

18

Согласно спецификации:

CSS

Селектор типа это имя типа элемента языка документа , написанного с использованием синтаксиса CSS уточненных имен

Я думал, что это называется селектором элементов , но, по-видимому, это на самом деле селектор типа . Далее в спецификации говорится о том, CSS qualified namesкакие ограничения не накладывают на имена. То есть, если селектор типа соответствует синтаксису квалифицированного имени CSS, это технически правильный CSS и будет соответствовать элементу в документе. Не существует специфичных для CSS ограничений для элементов, которые не существуют в конкретной спецификации - HTML или иным образом.

HTML

Нет никаких официальных ограничений на включение любых тегов в документ, который вы хотите. Тем не менее, документация говорит

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

И это позже говорит

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

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

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


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

@ Andrew Steitz: Думайте об этом так: element: type :: person: name. У вас может быть много элементов разных типов, причем каждый элемент имеет один тип, и таким же образом у вас может быть много людей, у каждого из которых есть имя. Селекторы работают с деревом документов, и каждый селектор может соответствовать некоторому количеству элементов дерева документа, которое можно сузить с помощью селектора класса, селектора идентификатора, селектора атрибута ... или селектора типа. Что бы вы ни использовали, вы все равно подходите элементам. Таким образом, «селектор элементов» не имеет смысла в этом случае - все эти вещи будут селекторами элементов.
BoltClock

@ BoltClock'saUnicorn: True, но класс, ID и атрибут - это все атрибуты (LOL) «элемента», то есть «штуковины» внутри угловых скобок. Они описывают «элемент», в чьем открывающем теге они находятся. Да, <a> и <div> являются конкретными «типами» элементов, но я сомневаюсь, что кто-нибудь назовет класс, ID и атрибуты «элементами». Я полностью согласен с тем, что все селекторы действительно являются «элементными» селекторами, но в ОБЩЕМ ИСПОЛЬЗОВАНИИ люди обычно называют «типовые» селекторы «селекторами». Это был пункт моего предыдущего комментария. Извините, это было неясно. :-)
Andrew Steitz

@ExplosionPills - в спецификациях HTML не говорится, что неизвестные элементы запрещены, но поскольку каждый элемент имеет перечисляемый список имен элементов, которые разрешены в качестве его дочерних элементов (т. Е. Его модель содержимого), он не обязан это делать. Просто нигде неизвестный элемент не разрешен как дочерний элемент разрешенного элемента. Применение HTMLUnknownElement к таким элементам является частью спецификации прецессии, то есть того, что потребители HTML должны делать с документами, действительными или нет, и не является частью того, что авторы должны делать, чтобы сделать их документы действительными.
Alohci

@Alohci Я имею в виду не допускается в том смысле, что они будут исключены из DOM, а не семантически недействительными
таблетки взрыва

13

Это возможно с html5, но вы должны принять во внимание старые браузеры.

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

Что-то вроде этого,

<!-- Custom tags in use, refer to their CSS for aid -->

Когда вы создаете свой собственный тег / элементы, старые браузеры не будут понимать, что это такое, как элементы html5, такие как nav/ section.

Если вы заинтересованы в этой концепции, то я рекомендую сделать это правильно.

Начиная

Пользовательские элементы позволяют веб-разработчикам определять новые типы элементов HTML. Эта спецификация является одним из нескольких новых API-примитивов, попадающих под эгиду Web Components, но, пожалуй, наиболее важной Веб-компоненты не существуют без функций, разблокированных пользовательскими элементами:

Определите новые элементы HTML / DOM. Создайте элементы, которые расширяются из других элементов. Логически объедините пользовательские функции в единый тег. Расширьте API существующих элементов DOM.

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

Итак, подведем итоги,

Pros

  • Очень элегантно и легко читается.

  • Приятно не видеть так много divs. :п

  • Позволяет уникальному ощущению кода

Cons

  • Поддержка старых браузеров очень важна.

  • Другие разработчики могут не знать, что делать, если они не знают о пользовательских тегах. (Объясните им или добавьте комментарии, чтобы сообщить им)

  • Наконец, одна вещь, которую следует принять во внимание, но я не уверен, это блочные и встроенные элементы. Используя пользовательские теги, вы в конечном итоге будете писать больше css, потому что пользовательский тег не будет иметь сторону по умолчанию.

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

Обновление 1/2/2014

Вот очень полезная статья, которую я нашел и решил поделиться, Custom Elements .

Изучите технологию Почему пользовательские элементы? Пользовательские элементы позволяют авторам определять свои собственные элементы. Авторы связывают код JavaScript с именами пользовательских тегов, а затем используют эти имена пользовательских тегов так же, как и любые другие стандартные теги.

Например, после регистрации специального вида кнопки, называемой супер-кнопкой, используйте супер-кнопку, например, так:

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

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


3
« Other developers may have no clue what to do if they don't know about custom tags.Я ненавижу этот аргумент. Предполагается, что другие разработчики тоже будут изучать новые вещи, и если они не понимают методов, используемых в вашем коде, они должны быть благодарны вам за указание на недостатки в их знаниях. Может быть, это немного несправедливо в этом случае, потому что пользовательские теги существуют только как черновик, но я слышал тот же аргумент при использовании надлежащих стандартизированных методов.
GolezTrol

1
Я не говорю, что поддерживаю это, но многие разработчики не продолжают учиться. Почти нет причин не комментировать что-либо, если оно немного сложное или новое. Мы все правильно комментируем наши сценарии? Чтобы показать, что мы выполняем и как, то же самое с пользовательскими тегами.
Джош Пауэлл

1
Конечно, если это просто добавление комментариев. Я думал, что вы имеете в виду, что вам вообще не следует использовать пользовательские элементы, потому что другие люди не поймут. Добавление небольшого комментария при добавлении менее используемой техники - хорошая вещь. Будьте осторожны с комментариями в HTML, хотя. Они могут оказаться на клиенте, потребляя пропускную способность и, возможно, раскрывая детали реализации, о которых ваши посетители не хотят узнавать. Но в качестве альтернативы вы можете добавить комментарии как комментарии PHP / ASP, чтобы они все еще были в шаблоне, но оставались на сервере.
GolezTrol

1
@GolezTroi, дело не в том, что вы никогда не должны делать вещи, которые бросают вызов другим разработчикам, это вопрос рентабельности. Если выполнение следующих действий более сложным для следующего разработчика законно делает ваш код лучше и чище, сделайте это. Но не делай гнусных вещей просто ради удовольствия.
БостонДжон

1
@JoshPowell Комментарии не должны быть о том, что и как (код уже говорит об этом, и если он недостаточно ясен, переписать код, пока он не будет), но должен сказать мне, почему . Есть несколько вещей хуже, чем множество комментариев, которые просто говорят, что sendmailфункция отправляет почту или что-то в этом роде. Меня больше интересует, почему вы отправляете почту - и если имя функции делает это очевидным, прекрасно! Тогда мне не нужен комментарий, который является идеальным случаем. Я все равно прочитаю код.
Кристофер Кройциг

4

Почему он не хочет, чтобы вы их использовали? Они не являются ни общими, ни частью стандарта HTML5. Технически они не разрешены. Они взломать

Я люблю их сам, хотя. Вы можете быть заинтересованы в XHTML5. Это позволяет вам определять свои собственные теги и использовать их как часть стандарта.

Кроме того, как указали другие, они недействительны и, следовательно, не переносимы.

Почему он не знал, что они существуют? Я не знаю, за исключением того, что они не являются общими. Возможно, он просто не знал, что ты мог.


2
XHTML5 не существует - была рабочая группа, пытающаяся создать XHTML 2, но она провалилась несколько лет назад.
максимум

1
@papirtiger: XHTML5 - это HTML5, обслуживаемый как XML, но вы правы в том, что не существует независимого стандарта XHTML, кроме XHTML 1.1.
BoltClock

1
Так что это XHTML5, но это , кажется, мало чем отличаются от HTML5 по этому вопросу пользовательских тегов. Поэтому я считаю, что утверждение о XHTML5, позволяющее вам определять дополнительные теги в отличие от HTML5, неверно, что может объяснить отрицательное влияние, даже если я не уверен в том, что XHTML5 может повысить или понизить этот ответ.
GolezTrol

1
Согласно проекту W3C HTML5, HTML и XHTML (сейчас) являются «конкретными синтаксисами», представляющими один и тот же «абстрактный язык». Они имеют те же основные функции, за исключением тех, которые имеют смысл только в одном синтаксисе (пространства имен XML, переключатель синтаксического анализатора HTML): w3.org/TR/html5/introduction.html#html-vs-xhtml
IMSoP

2

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

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

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


2

Я думаю, что выдуманные теги просто более запутаны или неясны, чем p с идентификаторами (обычно это какой-то блок текста). Мы все знаем, что ap с идентификатором - это абзац, но кто знает, для чего предназначены выдуманные теги? По крайней мере, это моя мысль. :) Поэтому это больше вопрос стиля / ясности, чем функциональности.


3
Спасибо, фея грамматики :)
runelynx

2

Другие сделали отличные замечания, но стоит отметить, что если вы посмотрите на такую ​​среду, как AngularJS , есть очень веский случай для пользовательских элементов и атрибутов. Они передают не только лучшее семантическое значение для xml, но также могут обеспечить поведение, внешний вид и восприятие веб-страницы.


2

CSS - это язык таблиц стилей, который можно использовать для представления документов XML, а не только (X) документов HTML. Ваш фрагмент с готовыми тегами может быть частью легального XML-документа; это будет один, если вы заключите его в один корневой элемент. Вероятно, у вас уже есть <html> ...</html>вокруг этого? Любой текущий браузер может отображать документы XML.

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

(X) HTML имеет преимущества перед обычным XML, поскольку элементы имеют семантическое значение, которое полезно в контексте представления веб-страницы. Инструменты могут работать с этой семантикой, другие разработчики знают значение, она менее подвержена ошибкам и лучше читается.

Но в других контекстах лучше использовать CSS с XML и / или XSLT для презентации. Это то, что ты сделал. Так как это не было вашей задачей, вы не знали, что делаете, и HTML / CSS - лучший способ работать большую часть времени, когда вы должны придерживаться его в своем сценарии.

Вы должны добавить (X) заголовок HTML к вашему документу, чтобы инструменты могли давать вам значимые сообщения об ошибках.


2
Нет, это совсем не юридический (правильно сформированный) XML. Есть <style>элемент, а затем ... <body>элемент. XML-документ должен иметь только один корневой элемент; в этом случае либо <style>элемент является корневым элементом, но <body>мешает, либо необходимо добавить корневой элемент, делая оба элемента его дочерними. Если вы не замените <style>элемент ссылкой на таблицу стилей (даже URI данных <?xml-stylesheet href="data:text/css,imsocool { color: blue; }"?>будет работать нормально), так что корневым элементом станет <body>.
BoltClock

2

... Я просто заменяю все свои составленные теги на абзацы с идентификаторами.

Я на самом деле не согласен с его предложением о том, как сделать это правильно.

  1. <p>Тег для пунктов. Я вижу людей, использующих его все время вместо div - просто для пробелов или потому, что он кажется более мягким. Если это не параграф, не используйте его.

  2. Вам не нужно или не нужно прикреплять идентификаторы на все, если вам не нужно целенаправленно ориентироваться (например, с помощью Javascript). Используйте классы или просто прямой div.


2

С самого начала CSS разрабатывался как независимый от разметки, поэтому его можно использовать с любым языком разметки, создающим древовидные структуры DOM (например, SVG). Любой тэг, который соответствует name tokenпродукции, полностью действителен в CSS. Так что ваш вопрос скорее о HTML, чем о самом CSS.

Элементы с пользовательскими тегами поддерживаются спецификацией HTML5. HTML5 стандартизирует способ анализа неизвестных элементов в DOM. Таким образом, HTML5 - это первая спецификация HTML, которая позволяет строго говоря настраивать пользовательские элементы. Вам просто нужно использовать тип <!DOCTYPE html>документа HTML5 в вашем документе.

С самими именами тегов ...

В этом документе http://www.w3.org/TR/custom-elements/ рекомендуются пользовательские теги, которые вы выбираете, чтобы они содержали хотя бы один символ «-» (тире). Таким образом, они не будут конфликтовать с будущими элементами HTML. Поэтому вам лучше изменить документ на что-то вроде этого:

<style>
so-cool {
    color:blue;
}
</style>

<body>
    <so-cool>HELLO</so-cool>
</body> 

2

Видимо никто не упомянул об этом, поэтому я буду.

Это побочный продукт браузерных войн .

Еще в 1990-х годах, когда Интернет впервые начал распространяться, конкуренция усилилась на рынке браузеров. Чтобы оставаться конкурентоспособными и привлекать пользователей, некоторые браузеры (особенно Internet Explorer) пытались быть полезными и «удобными для пользователя», пытаясь выяснить, что имели в виду дизайнеры страниц и, таким образом, допустили неправильную разметку (например, <b><i>foobar</b></i>правильно отобразить жирным шрифтом). курсив).

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

В то время как многие думали, что войны браузеров закончились, за последние несколько лет после выпуска Chrome началась новая война между поставщиками браузеров, Apple снова начала расти и стала продвигать Safari, а IE утратил свое доминирование. (Вы можете назвать это «холодной войной» из-за предполагаемого сотрудничества и поддержки стандартов со стороны производителей браузеров.) Поэтому неудивительно, что даже современные браузеры, которые предположительно строго соответствуют веб-стандартам, на самом деле пытаются быть «умными» и разрешить такое поведение, нарушающее стандарты, чтобы попытаться получить преимущество, как и раньше.

К сожалению, это разрешающее поведение привело к массовому ( некоторые могут даже сказать, раковые) росту плохо размеченных веб-страниц. Поскольку IE был самым снисходительным и популярным браузером, и из-за продолжающегося нарушения стандартов Microsoft, IE стал печально известным за поощрение и продвижение плохого дизайна, а также за распространение и увековечивание испорченных страниц.

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


Я бы сказал, что обвинять эту особую причуду в IE немного не по назначению, потому что, когда официально были добавлены несколько новых тегов (для HTML5), IE был единственным основным браузером, который требовал особой «шиммы», чтобы сделать их стилизованными , Отчасти это было связано с более агрессивными режимами обновления других браузеров (то есть старые версии IE держатся дольше, чем старые версии Chrome из Firefox), но это полная противоположность того, что IE «самый снисходительный».
IMSoP

HTML5? А? <imsocool>не новый тег в HTML5. Это не имеет ничего общего с HTML5 или IE 8, 9 и т. Д. Такое поведение не является новой причудой; это побочный продукт многолетних браузерных войн. Даже если IE не несет ответственности за текущие стандартные нарушения (хотя к гневу веб-разработчиков они по- прежнему отказываются соответствовать должным образом), они, безусловно, были известны тем, что в течение многих лет продвигали плохие методы кодирования. Более конкретные снисходительные браузеры (IE - худший нарушитель) появились в самое неподходящее время, как раз в тот момент, когда Интернет начал развиваться, а разработчики веб-сайтов начали изучать HTML… неправильно.
Synetech

Я не говорил, что это имеет какое-либо отношение к HTML5, но оно имеет отношение к нестандартным тегам (как, например, <header>до тех пор, пока HTML5 не стал целевым стандартом), к которым старые версии IE, безусловно, не «терпимы». Легкость также не то же самое, что несоблюдение - HTML5 - чрезвычайно прагматичный стандарт, который допускает, что плохо сформированный HTML будет существовать, в отличие от идеализма более ранних спецификаций W3C, и эта «мягкость», возможно, способствует демократическому росту сети.
IMSoP

Опять же, я не говорю о каком-либо конкретном браузере или версии. Я объясняю, что снисходительность в целом является побочным эффектом войн браузеров. IE допускает много нестандартных и даже выровненных некорректных действий, таких как отсутствующие теги, недопустимые теги и атрибуты, а также несовпадающие теги ( <b><i>foobar</b></i>). Это не секрет и даже хорошо раскритикованный и очень клеветнический вопрос. Как я уже сказал, IE был не единственным браузером, который допускал плохую разметку, но, поскольку он занимал такую ​​большую долю рынка и появлялся как раз в правильное (или неправильное) время, он в значительной степени способствовал плохой разметке в целом .
Synetech

1

Хотя браузеры обычно связывают CSS с тегами HTML независимо от того, являются ли они действительными или нет, вы должны АБСОЛЮТНО НЕ делать этого.

С технической точки зрения в этом нет ничего плохого. Однако использование составных тегов - это то, что вы НИКОГДА не должны делать в HTML.

HTML является языком разметки, что означает, что каждый тег соответствует определенному типу информации.

Ваши составленные теги не соответствуют какой-либо информации. Это создаст проблемы с веб-сканерами, такими как Google.

Читайте больше информации о важности правильной разметки .

редактировать

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

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

Пользовательские теги не соответствуют каким-либо стандартам, поэтому вместо них следует использовать span / div со свойствами class / ID.

Есть очень конкретные исключения к этому, такие как Angular JS


3
«Никогда» никогда не является правильным ответом - вы, кажется, забыли о XHTML;)
Izkata

div и span также не соответствуют какой-либо информации. Google и программы чтения с экрана, кажется, справляются с этим хорошо. Важно использовать семантическую разметку, но это вовсе не аргумент против использования пользовательских тегов.
GolezTrol

2
Div - это группы из нескольких связанных элементов, предназначенные для отображения в виде блоков и манипулирования ими как таковыми. Пролеты относятся к элементам, которые должны быть стилизованы аналогично и должны отображаться в виде строки, а не как блок. Пользовательские теги не соответствуют каким-либо стандартам, поэтому вместо них следует использовать span / div со свойствами class / ID.
Дэн Грин-Лейпцигер

Я удалил вашу информацию о программах чтения с экрана, потому что это неверно. Вспомогательные технологии будут читать <imsocool>some awesome text</imsocool>хорошо, потому что они будут интерпретироваться как <>...</>. Чего не произойдет, так это того, что они не смогут самостоятельно перейти к этому фрагменту текста, как если бы это было <p>. Конечно, если вы написали свой собственный DOCTYPE и сопоставили imsocoolего p, это сработало бы.
Райан Б

0

Хотя в CSS есть вещь, называемая «селектором тегов», на самом деле он не знает, что такое тег. Осталось определить язык документа. CSS был разработан для использования не только с HTML, но и с XML, где (при условии, что вы не используете DTD или другую схему проверки) теги могут быть чем угодно. Вы можете использовать его и с другими языками, хотя вам нужно будет придумать свою собственную семантику для того, чтобы точно соответствовать вещам типа «теги» и «атрибуты».

Браузеры обычно применяют CSS к неизвестным тегам в HTML, потому что это считается лучше, чем полное разрушение: по крайней мере, они могут что-то отображать. Но это очень плохая практика, чтобы использовать «поддельные» теги сознательно. Одной из причин этого является то, что новые теги время от времени определяются, и если они определены, они выглядят как ваш поддельный тег, но не совсем так, что может вызвать проблемы с вашим сайтом в новых браузерах.


0

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.