HTML: Включить или исключить необязательные закрывающие теги?

149

Некоторые закрывающие теги HTML ¹ являются необязательными , а именно:

</HTML>
</HEAD>
</BODY>
</P>
</DT>
</DD>
</LI>
</OPTION>
</THEAD>
</TH>
</TBODY>
</TR>
</TD>
</TFOOT>
</COLGROUP>

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

</IMG>
</INPUT>
</BR>
</HR>
</FRAME>
</AREA>
</BASE>
</BASEFONT>
</COL>
</ISINDEX>
</LINK>
</META>
</PARAM>

Примечание: xhtml отличается от HTML. xhtml - это форма xml, которая требует, чтобы у каждого элемента был закрывающий тег. Закрывающий тег может быть запрещен в html, но обязателен в xhtml.

Являются ли дополнительные закрывающие теги

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

Другими словами, я должен включать их, или я не должен включать их?

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

С другой стороны, случайная статья о DevGuru гласит :

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

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

Иными словами: что сделал HTML 1, 2, 3 в отношении этих, теперь необязательных, закрывающих тегов. Что делает HTML 5? И что мне делать?

Заметка

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

Сноски

¹ HTML 4.01

html html4

— Ян Бойд
источник

4

Трудный вопрос ... некоторые из рекомендаций w3c даже включают примеры, которые выполняют оба: w3.org/TR/html401/struct/global.html#id-and-class Первый пример имеет закрывающие </p>теги, а второй опускает их!

— Ричард Дж.П. Ле Гуен

Просто чтобы уточнить - в случае с запрещенными тегами в HTML5 «явное» / правильное XML-решение состоит в том, чтобы закрыть их с помощью символа />, например, <meta charset="utf-8" />даже если <meta charset="utf-8">действительный HTML5?

— cboettig

@cboettig Да. <meta charset="utf-8" />является недействительным HTML, это должно быть <meta charset="utf-8">. С другой стороны <meta charset="tuf-8">, недействителен xhtml, это должно быть<meta charset="utf-8" />

— Ian Boyd

@IanBoyd действительно? в HTML5? В черновом руководстве W3C для полиглота html / xhtml говорится об использовании <meta charset="UTF-8"/>с закрывающим тегом. Иначе как полиглот или xhtml могли когда-либо проверяться как html5 и xml?

— cboettig

@cboettig Ты прав. Разметка полиглота (т. Е. HTML-совместимые документы XHTML ) не может быть верной HTML 4.01. HTML5 (все еще в стадии разработки) имеет понятие элементов Void - элементов, которые не могут иметь конечный тег . Предположительно большинство браузеров мягкие и простят ваши ошибки в разметке.

— Ян Бойд

49

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

За всеми запрещенными конечными тегами сразу же следует их конечный тег, поэтому было бы излишним <img src="blah" alt="blah"></img>каждый раз печатать .

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

— aslum
источник

18

я вижу это сейчас. <LI>это как пуля. Никто не захочет завернуть целую маркированную точку в <LI>...</LI>. Таким образом, это LIсоответствует тому, что люди естественно пишут во время разметки. То же самое касается знака абзаца ( <P>), при обработке текста вы добавляете знак абзаца в начале абзаца; и не в конце каждого тоже. Таким образом, в этой интерпретации закрывающие теги являются необязательными, потому что ни один нормальный человек не подумает, что они есть. Кроме того, сам элемент не имеет содержимого - элемент является содержимым.

— Ян Бойд

8

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

— KajMagnus

3

@IanBoyd А для последнего абзаца?

— Pacerier

22

@Pacerier Люди пишут параграфы текста в течение сотен лет. Никто никогда не смущался, когда заканчивался абзац.

— Ян Бойд

4

Соответствующая ссылка для HTML5, для тех, кто нашел этот ответ при попытке найти актуальную справочную документацию: w3.org/TR/html5/syntax.html#optional-tags

— Майк 'Pomax' Kamermans

59

Бывают случаи, когда помогают явные теги, но иногда это ненужная педантичность.

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

Например, вам никогда не нужно </body></html>. Никто никогда не помнит, чтобы поставить <tbody>явно (до такой степени, что XHTML сделал исключения для него).

Вам не нужно, </head><body>если у вас нет DOM-манипулирующих скриптов, которые на самом деле ищут <head>(тогда лучше закрыть это явно, потому что правила для подразумеваемого завершения <head>могут вас удивить).

Вложенные списки на самом деле лучше без них </li>, потому что тогда сложнее создать ошибочное ul > ulдерево.

Действительно:

<ul>
  <li>item
  <ul>
    <li>item
  </ul>
</ul>

Недействительным:

<ul>
  <li>item</li>
  <ul>
    <li>item</li>
  </ul>
</ul>

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

<p>foo <p>bar</p> baz</p>

будет разбираться как:

<p>foo</p><p>bar</p> baz

Это может помочь только при проверке документов.

— Корнель
источник

4

Подождите, почему <p>foo <p>bar</p> baz</p>не разбирается как два вложенных pтега?

— Эрик

19

Потому что <P>элемент не может содержать элементы уровня блока и <P>является элементом уровня блока. From ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "Элемент P представляет абзац. Он не может содержать элементы уровня блока (включая сам P)."

— Ян Бойд

1

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

— Pacerier

6

@Pacerier CSS никак не может повлиять на DOM. Сначала анализируется DOM, а затем CSS отображает его. blockОтображение CSS - это совсем не то, что содержимое на уровне блоков HTML (просто так получается, что большинство элементов уровня блоков HTML по умолчанию отображаются в виде блоков CSS).

— Корнель

2

@ anton1980 Нет, это не то же самое. Обработка пропущенных необязательных закрывающих тегов четко определена и работает надежно во всех совместимых браузерах. OTOH выдумка <t>не будет работать, как <title>.

— Корнел

18

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

Некоторые выдержки из Dive Into HTML5 :

[T] тот факт, что «сломанная» разметка HTML все еще работала в веб-браузерах, побудила авторов создавать поврежденные HTML-страницы. Много битых страниц. По некоторым оценкам, более 99% HTML-страниц в Интернете сегодня содержат по крайней мере одну ошибку. Но поскольку эти ошибки не заставляют браузеры отображать видимые сообщения об ошибках, никто их не исправляет.

W3C видел в этом фундаментальную проблему с сетью, и они решили ее исправить. XML, опубликованный в 1997 году, вышел из традиции прощения клиентов и постановил, что все программы, использующие XML, должны рассматривать так называемые ошибки «правильной формы» как фатальные. Эта концепция отказа от первой ошибки стала известна как «драконовская обработка ошибок» после греческого лидера Драко, который назначил смертную казнь за относительно незначительные нарушения его законов. Когда W3C переформулировал HTML как словарь XML, они обязали, что все документы, обслуживаемые новым application/xhtml+xmlтипом MIME, будут подвергаться драконовской обработке ошибок. Если бы на вашей странице XHTML была хотя бы одна ошибка правильности, у веб-браузеров не было бы выбора, кроме как прекратить обработку и отобразить сообщение об ошибке для конечного пользователя.

Эта идея не была повсеместно популярной. При предполагаемой частоте появления ошибок 99% на существующих страницах, постоянной возможности отображения ошибок для конечного пользователя и недостатке новых функций в XHTML 1.0 и 1.1 для обоснования стоимости, веб-авторы в основном игнорировали application/xhtml+xml. Но это не значит, что они полностью игнорировали XHTML. О, определенно нет. Приложение C спецификации XHTML 1.0 предоставило авторам всего мира лазейку: «Используйте что-то, похожее на синтаксис XHTML, но продолжайте использовать его с text/htmlтипом MIME». И это именно то, что сделали тысячи веб-разработчиков: они «обновились» до синтаксиса XHTML, но продолжали обслуживать его с MIME-типом text / html.

Даже сегодня миллионы веб-страниц утверждают, что они являются XHTML. Они начинаются с типа документа XHTML в первой строке, используют строчные имена тегов, используют кавычки вокруг значений атрибутов и добавляют косую черту после пустых элементов, таких как <br />и <hr />. Но только небольшая часть этих страниц обслуживается с application/xhtml+xmlтипом MIME, который запускает драконовскую обработку ошибок XML. Любая страница, обслуживаемая MIME-типом text/html- независимо от типа документа, синтаксиса или стиля кодирования - будет проанализирована с использованием «прощающего» анализатора HTML, беззвучно игнорируя любые ошибки разметки и никогда не предупреждая конечных пользователей (или кого-либо еще), даже если страницы технически сломаны.

XHTML 1.0 включал эту лазейку, но XHTML 1.1 закрыл ее, и никогда не завершенный XHTML 2.0 продолжал традицию требовать драконовской обработки ошибок. И именно поэтому существуют миллиарды страниц, которые претендуют на то, чтобы быть XHTML 1.0, и только несколько, которые претендуют на то, чтобы быть XHTML 1.1 (или XHTML 2.0). Так вы действительно используете XHTML? Проверьте свой тип MIME. (На самом деле, если вы не знаете, какой тип MIME вы используете, я могу в значительной степени гарантировать, что вы все еще используете text/html.) Если вы не обслуживаете свои страницы с типом MIME application/xhtml+xml, ваш так называемый «XHTML» XML только в названии.

[T] люди, которые предложили развивать формы HTML и HTML, столкнулись с двумя вариантами: отказаться или продолжить свою работу за пределами W3C. Они выбрали последний, зарегистрировали whatwg.orgдомен, и в июне 2004 года родилась рабочая группа ЧТО .

[T] Рабочая группа WHAT тихо работала и над некоторыми другими вещами. Одной из них была спецификация, первоначально названная Web Forms 2.0 , которая добавляла новые типы элементов управления в формы HTML. (Вы узнаете больше о веб-формах в A Form of Madness .) Другой был черновик спецификации под названием «Веб-приложения 1.0», который включал в себя основные новые функции, такие как холст рисования в прямом режиме и встроенная поддержка аудио и видео без плагинов .

В октябре 2009 года W3C закрыл рабочую группу XHTML 2 и выпустил это заявление, чтобы объяснить свое решение :

Когда W3C объявил о рабочих группах HTML и XHTML 2 в марте 2007 года, мы указали, что будем продолжать следить за рынком XHTML 2. W3C признает важность четкого информирования сообщества о будущем HTML.

Хотя мы признаем ценность вкладов Рабочей группы XHTML 2 за эти годы, после обсуждения с участниками руководство W3C приняло решение разрешить срок действия устава Рабочей группы в конце 2009 года и не продлевать его.

Те, кто выиграл, те, кто грузит.

— Срикар Додди
источник

12

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

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

Что сделал HTML 1, 2, 3 в отношении этих, теперь необязательных, закрывающих тегов.

DTD для HTML 2 встроен в RFC, который, наряду с оригинальным HTML DTD , имеет дополнительные начальные и конечные теги повсюду.

HTML 3 был заброшен (благодаря войнам браузеров) и заменен HTML 3.2 (который был разработан для описания текущего состояния сети).

Что делает HTML 5?

HTML 5 с самого начала был ориентирован на «прокладку коровников».

И что я должен делать?

Ах, теперь это субъективно и аргументировано :)

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

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

— Quentin
источник

1

+1 я не думал о понятии «достоверно выведено». Так что это подтверждает идею о том, что на самом деле не было никакого намерения, так или иначе. Я предположил, что спецификация пытается быть максимально совместимой с существующим контентом HTML и спецификациями HTML.

— Ян Бойд

Извини, Дейв, я отдал его в убежище; ему нужен представитель :) Но у вас та же идея, с более связанным и цитируемым контентом. Но хороший ответ.

— Ян Бойд

8

Что делает HTML 5?

Ответ на этот вопрос содержится в рабочем проекте W3C: http://www.w3.org/TR/html5/syntax.html#syntax-tag-omission.

И что я должен делать?

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

— ghoppe
источник

+1 за ссылку на черновик спецификации HTML 5 и соответствующий раздел. Но HTML 5 не говорит так или иначе.

— Ян Бойд

6

Если это лишнее, оставьте это.

Если это служит какой-либо цели (даже, казалось бы, тривиальной цели, такой как умиротворение вашей IDE или умиротворение ваших глаз), оставьте это в.

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

Глядя на раздел спецификации RFC HTML-5, связанный выше, вы видите, что дополнительные теги странным образом связаны с наличием комментариев! Это должно сказать вам, что авторы не носят дизайнерские шляпы. Вместо этого они играют в игру «документируйте причуды» в основных реализациях. Поэтому мы не можем воспринимать спецификацию слишком серьезно в этом отношении.

Итак, решение таково: не переживайте. Переходите к чему-то, что действительно имеет значение. :)

— Джон
источник

5

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

— Гейб
источник

2

Ричард: Когда у вас есть глубоко вложенные структуры, вам гораздо легче находить ошибки, потому что закрывающие теги дают больше информации о намерениях.

— Гейб

1

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

— SquareCandy

4

Я рекомендую, чтобы вы опускали большинство необязательных тегов закрытия и все необязательные атрибуты, которые вы можете использовать. Многие IDE будут жаловаться, поэтому вы можете не справиться с пропуском некоторых из них, но это лучше для меньшего размера файла и меньшего количества помех. Если у вас есть генераторы кода, определенно пропустите конечные теги, потому что вы можете получить хорошее уменьшение размера. Обычно это не имеет значения, так или иначе.

Но когда это имеет значение, тогда действуй. В моей недавней работе мне удалось уменьшить размер моего отрендеренного HTML с 1,5 МБ до 800 КБ, исключив большинство сгенерированных атрибутов конечных и избыточных значений для открытого тега, где текст элемента был таким же, как и у элемента. стоимость. У меня есть около 200 тегов. Я мог бы реализовать это каким-то другим способом, но это было бы больше работы ($$$), так что это позволяет мне легко сделать страницу более отзывчивой.

Просто из любопытства я обнаружил, что если я удаляю кавычки вокруг атрибутов, которые им не нужны, я могу сэкономить 20 КБ, но моей IDE (Visual Studio) это не нравится. Я также был удивлен, обнаружив, что действительно длинный идентификатор, который генерирует ASP.NET, составляет 20% моего файла.

Идея, что мы когда-либо сможем получить какую-либо релевантную часть HTML-кода, была изначально ошибочной, поэтому делайте все, что будет лучше для вас и ваших клиентов. Большинство инструментов, которые я когда-либо видел или использовал, скажут, что они генерируют xhtml, но на самом деле они не работают на 100%, и строгое соблюдение в любом случае не дает никакой выгоды.

— user1777246
источник

Я с трудом могу согласиться с тем, чтобы опускать необязательные конечные теги, но я считаю довольно плохой идеей опускать кавычки в атрибутах. Вы рискуете своим сайтом нарушить работу некоторых браузеров. Если у вас есть 800kb html-файлов, вы делаете что-то не так.

— Кристоф

2

@Christoph: пропуск необязательных конечных тегов (например, </p>или </li>) прекрасно подходит в соответствии со спецификацией HTML. Если браузер этого не понимает, значит, проблема в браузере.

— Конрад Боровски,

2

Лично я фанат XHTML и, как и ghoppe, «стараюсь никогда не опускать конечные теги, потому что это помогает мне быть строгим, а не опускать необходимые теги».

но

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

— Ричард Дж.П. Ле Гуэн
источник

2

Использование конечных тегов облегчает работу с фрагментами, потому что их поведение не зависит от родственных элементов. Одна эта причина должна быть достаточно убедительной. Кто-нибудь имеет дело с монолитными HTML-документами?

— CurtainDog
источник

1

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

если ([условие])
[код]

но ты не можешь сделать это ...

if ([условие])
[код]
[код]

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

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

— MiguelR
источник

Не могли бы вы привести пример такого сложного HTML-кода? По моему опыту необязательные конечные теги не так обманчивы.

— Корнел

Я помню, что у меня была проблема с IE7 несколько лет назад, когда я нашел открывающий тег li на отдельной строке от текста, который он содержал, и без закрытия li IE7 рассматривал все маркеры как одну большую. размещение тега и текста на одной строке или закрытие тега решит проблему. Я, кажется, не могу сейчас это повторить, так что это, вероятно, также имеет отношение к CSS в игре. но я бы не стал винить вас за то, что вы восприняли это как "у меня есть девушка ... в Канаде!" история.

— MiguelR

0

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

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

— Джоэл Мюллер
источник

1

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

— Ричард Дж.П. Ле Гуен

1

Я понимаю это, но визуализированный элемент DOM имеет как начало, так и конец, даже если ваш HTML-тег не имеет. Если вы включите <li>тег без закрывающего тега, в какой-то момент браузер должен будет решить, где заканчивается элемент, и действовать так, как будто вы поместили конечный тег в этот момент. Это может быть относительно тривиальным количеством логики, но «некоторые» по-прежнему больше, чем «нет», и я не думаю, что было бы неразумно предполагать, что отсутствие дополнительных конечных тегов делает для браузера больше работы, чем их включение.

— Джоэл Мюллер

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

— Ричард Дж.П. Ле Гуен

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

— Джоэл Мюллер

@RichardJPLeGuen Я думаю, все зависит от того, как именно выглядят правила. Когда вы закрываете </table>и ваш стек содержит <table><tbody><tr><td>, вы можете просто закрыть все, пока не совпадете с <table>. Аналогично для открытия <p>в не круглосуточном контексте. Но может быть гораздо сложнее, я не знаю.

— Maaartinus

-1

Делайте все, что считаете нужным, чтобы сделать код более читабельным и понятным.

Лично я всегда склонен закрывать <td>и <tr>, но я никогда бы не беспокоиться <li>.

— Мэтью Уилсон
источник

1

я надеялся получить какое-то руководство по первоначальному проектному решению, и что они сделали бы x, если бы могли.

— Ян Бойд

В чем разница, <td>и <li>это заставляет вас не беспокоиться <li>? Для меня есть небольшая разница.

— ghoppe

Технических отличий нет, это чисто субъективно. Я чувствую, что могу лучше прочитать HTML, если закрою td и tr. Но я никогда не чувствовал в этом необходимости.

— Мэтью Уилсон

-2

Для запрещенных типов закрытия используйте синтаксис, например: <img />С, />чтобы закрыть тег, который принят в XML

— Дани
источник

1

Он не работает в HTML4 (он соответствует неясному синтаксису SGML, который немного отличается). В HTML5 это разрешено, но бессмысленно.

— Корнел