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

https://stackoverflow.com/questions/3008593

26-09-2019
|

Вопрос

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

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

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

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

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

Примечание

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

Сноски

¹HTML 4.01.

Решение

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

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

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

Другие советы

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

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

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

Вам не нужно </head><body> Если у вас нет сценариев Manipulation, которые на самом деле ищут <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

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

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

Некоторые выдержки из Погрузиться в 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, но продолжали служить его текстом / HTML-типом MIME.

Даже сегодня миллионы веб-страниц претендуют на XHTML. Они начинаются с Doctype XHTML на первой строке, используйте имена меток строчных букв, используйте цитаты вокруг значений атрибутов и добавьте заднюю косулью после пустых элементов, как <br /> а также <hr />. Отказ Но только крошечная фракция этих страниц подается с application/xhtml+xml Тип MIME, который заставит обработку драконовской ошибки 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 года, Какая рабочая группа родилась.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ на этот вопрос в рабочем проекте W3C:http://www.w3.org/tr/html5/syntax.html#syntax-tag-imission.

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

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

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

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

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

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

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

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

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

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

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

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

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

но

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

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

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

Если ([состояние])
код

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

Если ([состояние])
код
код

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow