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

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

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

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

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

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

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

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

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

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

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

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

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

А, вот это уже субъективно и спорно :)

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

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

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

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

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

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

Вложенные списки на самом деле лучше без , потому что тогда сложнее создать ошибочное 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

Это может помочь только тогда, когда вы проверяете документы.

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

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

• How Did We Get Here? - Dive Into HTML5
• The History of the Web
• Brief History of HTML
• HTML's History - HTML WG Wiki

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

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

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

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

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

---

. Но лишь небольшая часть этих страниц обслуживается с MIME-типом application/xhtml+xml, который бы вызвал драконовскую обработку ошибок 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). Если вы не обслуживаете свои страницы с MIME-типом application/xhtml+xml, ваш так называемый "XHTML" является XML только по названию.

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

[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 года и не продлевать его.

Те, кто выигрывают, те и отправляются.

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

Лично я всегда был бы склонен закрыть и , но я бы никогда не стал беспокоиться о

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но

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