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

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

149 голосов
/ 09 июня 2010

Некоторые 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?И что должен I делать?

Примечание

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

Сноски

1 HTML 4.01

Ответы [ 14 ]

58 голосов
/ 09 июня 2010

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

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

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

49 голосов
/ 09 июня 2010

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

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

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

18 голосов
/ 09 июня 2010

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

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

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

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

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

он тот корабль.

12 голосов
/ 09 июня 2010

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

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

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

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

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

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

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

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

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

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

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

8 голосов
/ 09 июня 2010

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

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

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

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

6 голосов
/ 09 июня 2010

Если это лишнее, не указывайте.

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

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

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

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

5 голосов
/ 09 июня 2010

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

4 голосов
/ 27 октября 2012

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

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

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

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

2 голосов
/ 01 марта 2011

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

2 голосов
/ 09 июня 2010

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

но

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

Страница:
...