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

Некоторые 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

Ответ 1

Необязательные - это все те, которые должны быть семантически понятны, где они заканчиваются, без использования конечного тега. НАПРИМЕР. каждый <li> подразумевает a </li>, если перед ним нет ни одного.

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

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

Ответ 2

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

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

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

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

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

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

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

Invalid:

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

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

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

будет анализироваться как:

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

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

Ответ 3

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

Некоторые выдержки из Погружение в HTML5:

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

W3C видел это как фундаментальную проблему с сетью, и они решили исправить ее. XML, опубликованный в 1997 году, нарушил традицию прощения клиентов и дал указание, что все программы, которые потребляют XML, должны обрабатывать так называемые "корректные" ошибки как фатальные. Эта концепция неудачи при первой ошибке стала известна как "драконовская обработка ошибок" после греческого лидера Draco, который установил смертную казнь для относительно незначительные нарушения его законов. Когда 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, но продолжали обслуживать его с помощью типа text/html MIME.

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

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

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

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

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

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

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

Побеждают те, кто выигрывает.

Ответ 4

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

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

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

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

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

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

HTML 5 с самого начала был направлен на "мощение коров".

И что мне делать?

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

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

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

Ответ 5

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

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

И что мне делать?

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

Ответ 6

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

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

но

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

Ответ 10

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

Ответ 11

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

if ([condition])
[код]

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

if ([condition])
[code]
[code]

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

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

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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