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

150

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

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

Сноски

1 HTML 4.01

  • 4
    Сложный вопрос ... некоторые из рекомендаций w3c даже включают примеры, которые делают оба: w3.org/TR/html401/struct/global.html#id-and-class В первом примере есть закрывающие теги </p> а во втором нет их!
  • 0
    Просто для пояснения - в случае запрещенных тегов в HTML5 «явное» / правильное XML-решение состоит в том, чтобы закрыть их с помощью /> , например, <meta charset="utf-8" /> даже если <meta charset="utf-8"> является верным HTML5?
Показать ещё 7 комментариев
Теги:
html4

14 ответов

44
Лучший ответ

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

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

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

Поделиться
  • 18
    я вижу это сейчас. <LI> это как пуля. Никто не захочет заключать целую маркированную точку в <LI>...</LI> . Таким образом, LI соответствует тому, что люди, естественно, пишут во время разметки. То же самое касается знака абзаца ( <P> ), при обработке текста вы добавляете знак абзаца в начале абзаца; и не в конце каждого тоже. Таким образом, в этой интерпретации закрывающие теги являются необязательными, потому что ни один нормальный человек не подумает, что они есть. Кроме того, сам элемент не имеет содержимого - элемент является содержимым.
  • 8
    Что вы подразумеваете под тем, что я почти всегда использую необязательные теги - вы имеете в виду, что вы включаете конечный тег или вы его опускаете ? (У меня сложилось впечатление, что вы включаете его, когда я читаю ваш ответ - но комментарий Иана Бойда выше создает у меня впечатление, что вы его исключаете .)
Показать ещё 7 комментариев
56

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

Обратите внимание, что спецификация 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

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

Поделиться
  • 4
    Подождите, почему <p>foo <p>bar</p> baz</p> не анализируется как два вложенных <p>foo <p>bar</p> baz</p> p ?
  • 18
    Поскольку элемент <P> не может содержать элементы уровня блока, а <P> является элементом уровня блока. From ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "Элемент P представляет абзац. Он не может содержать элементы уровня блока (включая сам P)."
Показать ещё 6 комментариев
17

Я добавляю некоторые ссылки здесь, чтобы помочь вам в истории 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 года и не продлевать ее.

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

Поделиться
11

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

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

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

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

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

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

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

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

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

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

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

Поделиться
  • 1
    +1 я не думал о понятии «достоверно выведено». Так что это отстаивает идею, что на самом деле не было никакого намерения, так или иначе. я предположил, что спецификация пытается быть максимально совместимой с существующим контентом HTML и спецификациями HTML.
  • 0
    Извини, Дейв, я отдал его в убежище; ему нужен представитель :) Но у вас та же идея, с более связанным и цитируемым контентом. Но хороший ответ.
8

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

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

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

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

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

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

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

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

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

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

Поделиться
5

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

Поделиться
  • 0
    Любопытно: как это помогает с обнаружением ошибок?
  • 2
    Ричард: Когда у вас есть глубоко вложенные структуры, вам гораздо легче находить ошибки, потому что закрывающие теги дают больше информации о намерениях.
Показать ещё 1 комментарий
4

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

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

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

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

Поделиться
  • 0
    Я вряд ли могу согласиться с тем, чтобы опускать необязательные конечные теги, но я считаю довольно плохой идеей опускать кавычки в атрибуты Вы рискуете своим сайтом нарушить работу некоторых браузеров. Если у вас есть 800kb html-файлов, вы делаете что-то не так.
  • 2
    @Christoph: пропуск необязательных конечных тегов (таких как </p> или </li> ) прекрасно подходит в соответствии со спецификацией HTML. Если браузер этого не понимает, значит проблема в браузере.
2

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

Поделиться
2

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

но

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

Поделиться
1

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

if ([condition])
    [код]

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

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

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

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

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

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

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

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

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

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

Поделиться
  • 1
    я надеялся получить какое-то руководство по первоначальному проектному решению, и что они бы сделали x, если бы могли.
  • 0
    В чем разница между <td> и <li> которая заставляет вас не беспокоиться о <li> ? Для меня есть небольшая разница.
Показать ещё 1 комментарий
-2

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню