HTML: включити чи виключити необов’язкові теги закриття?

149

Деякі закриваючі теги 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

html html4

— Ян Бойд
джерело

4

Важке запитання ... деякі рекомендації для w3c навіть включають приклади, які виконують і те, і інше: w3.org/TR/html401/struct/global.html#id-and-class Перший приклад містить закриваючі </p>теги, а другий опускає їх!

— Річард JP Le Guen

Просто для уточнення - у випадку заборонених тегів у HTML5 "явним" / правильним рішенням XML є закриття їх символом a />, наприклад, <meta charset="utf-8" />хоча <meta charset="utf-8">дійсний HTML5?

— cboettig

@cboettig Так. <meta charset="utf-8" />є недійсною HTML, воно повинно бути <meta charset="utf-8">. З іншого боку <meta charset="tuf-8">, недійсний xhtml, він повинен бути<meta charset="utf-8" />

— Ian Boyd

@IanBoyd насправді? в HTML5? У проекті посібника W3C для поліглоту html / xhtml зазначено, що він використовується <meta charset="UTF-8"/>із закритим тегом. Інакше як поліглот або xhtml коли-небудь можна перевірити як html5 та xml?

— cboettig

@cboettig Ти маєш рацію. Розмітка поліглотів (тобто сумісні з HTML XHTML-документи ) не може бути дійсним HTML 4.01. HTML5 (ще триває робота) має поняття Void елементів - елементів, які не можуть мати кінцевий тег . Імовірно, більшість браузерів щадні та пробачать помилки розмітки.

— Ян Бойд

49

Необов’язкові - це всі, які повинні бути семантично чіткими, де вони закінчуються, не потребуючи кінцевого тегу. Кожен EG <li>означає, </li>якщо перед ним немає жодного права.

Усі заборонені кінцеві теги негайно супроводжуватимуться їх кінцевим тегом, тому було б зайвим вводити <img src="blah" alt="blah"></img>кожен раз.

Я майже завжди використовую необов’язкові теги (якщо у мене є дуже вагомі причини цього не робити), оскільки він надає більш читабельний і оновлений код.

— aslum
джерело

18

я бачу це зараз. <LI>як куля. Ніхто не захотів би загортати цілу мітку <LI>...</LI>. Тож таким чином LIвідповідає тому, що люди природно писали б під час розмітки. Sames позначає позначку абзацу ( <P>), при текстовій обробці ви додаєте позначку абзацу на початку абзацу; і не в кінці кожного теж. Тож у цій інтерпретації закривальні теги необов’язкові, оскільки жодна нормальна людина не подумає їх мати. Плюс, сам елемент не має змісту - елемент - це зміст.

— Ян Бойд

8

Що ви маєте на увазі під тим, що я майже завжди використовую необов’язкові теги - ви маєте на увазі, що ви включаєте кінцевий тег або ви залишаєте його поза ? (У мене склалося враження, що ви включаєте її, коли я читаю вашу відповідь, - але коментар Ian Boyd вище, створює враження, що ви її виключаєте .)

— KajMagnus

3

@IanBoyd А для останнього абзацу?

— Pacerier

22

@Pacerier Люди пишуть абзаци тексту вже сотні років. Ніхто ніколи не плутається, коли закінчується абзац.

— Ян Бойд

4

Відповідне посилання на HTML5 для тих, хто знайшов цю відповідь, намагаючись знайти фактичну довідкову документацію: w3.org/TR/html5/syntax.html#optional-tags

— Майк 'Pomax' Kamermans

59

Бувають випадки, коли явні теги допомагають, але іноді це непотрібність педантизму.

Зауважте, що специфікація 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

Це може допомогти лише при підтвердженні документів.

— Корнель
джерело

4

Зачекайте, чому <p>foo <p>bar</p> baz</p>не розбирається як два вкладені pтеги?

— Ерік

19

Оскільки <P>елемент не може містити елементів рівня блоку і <P>є елементом рівня блоку. З ( w3.org/TR/REC-html40/struct/text.html#edef-P ) "P елемент являє собою абзац. Він не може містити елементи рівня блоку (включаючи сам P)."

— Ян Бойд

1

@IanBoyd Ви маєте на увазі, що не можуть містити елементи рівня блоку незалежно від правил CSS?

— Pacerier

6

@Pacerier CSS ніяк не може впливати на DOM. Спочатку DOM розбирається, а потім відображає CSS. blockДисплей CSS - це зовсім інша річ від вмісту на рівні блоку HTML (просто буває, що більшість елементів рівня блоку HTML відображаються як блоки CSS за замовчуванням).

— Корнель

2

@ anton1980 Ні, це не те саме. Поводження з пропущеними необов'язковими тегами закриття чітко визначено і надійно працює у всіх сумісних браузерах. ОТО складений склад <t>не буде працювати <title>.

— Корнель

18

Я додаю сюди кілька посилань, щоб допомогти вам з історією 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, але продовжували обслуговувати його з текстовим / html-MIME типом.

Навіть сьогодні мільйони веб-сторінок претендують на 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 року була створена робоча група ЩО .

[T] він ЩО робоча група спокійно працювала і над кількома іншими речами. Однією з них була специфікація, яка спочатку отримала назву 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 року та не поновлювати її.

Перемагають ті, хто перевозять.

— Шрікар Додді
джерело

12

Я запитую причину тому, що ви просто знаєте, що це не обов'язково з міркувань сумісності; і вони зробили б їх (обов'язковими | забороненими), якби могли.

Це цікавий висновок. Моє читання з цього приводу полягає в тому, що приблизно в будь-який момент, коли тег може бути надійно зроблений, тег є необов'язковим. Дизайн говорить про те, що намір полягав у тому, щоб зробити його швидко і просто писати.

Що зробили HTML 1, 2, 3 щодо цих, тепер необов'язкових, закриваючих тегів.

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

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

Що робить HTML 5?

HTML 5 з самого початку був орієнтований на "мощення бруківки".

І що мені робити?

Ах, тепер це суб'єктивно і аргументативно :)

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

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

— Квентін
джерело

1

+1 я не думав над поняттям "надійно зробити висновок". Тож це відстоює думку про те, що так чи інакше не було наміру. Я припускав, що специфікація намагається бути максимально сумісною з існуючим вмістом HTML та специфікаціями HTML.

— Ян Бойд

Вибачте, Дейв, я віддав його в аслу йому потрібен представник :) Але ви маєте таку ж ідею, з більш пов’язаним і цитованим змістом. Але приємна відповідь.

— Ян Бойд

8

Що робить HTML 5?

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

І що мені робити?

Це питання стилю. Я намагаюся ніколи не опускати кінцеві теги, тому що це допомагає мені бути суворим і не опускати теги, які необхідні.

— ghoppe
джерело

+1 для посилання на проект специфікації HTML 5 та відповідного розділу. Але html 5 не говорить так чи інакше.

— Ян Бойд

6

Якщо вона зайва, залиште її.

Якщо вона служить цілі (навіть, здавалося б, тривіальної мети, наприклад, приємного посвідчення особи чи привабливості очей), залиште це.

У чітко визначеній специфікації рідко можна побачити додаткові предмети, які не впливають на поведінку. За винятком "коментарів", звичайно. Але специфікація HTML - це менше специфікації дизайну, а більше документа про стан поточних основних реалізацій. Отже, коли елемент необов’язковий у HTML і, здається, він не виконує жодної мети, ми можемо здогадатися, що необов’язковий характер - це лише документація вигадки у певному браузері.

Переглядаючи розділ RFC-специфікації HTML-5, зв'язаний вище, ви бачите, що необов'язкові теги дивно пов'язані з наявністю коментарів! Це повинно вам сказати, що автори не носять дизайнерські шапки. Натомість вони грають у гру «документуйте диваки» у основних реалізаціях. Тому ми не можемо сприймати специфікацію надто серйозно в цьому відношенні.

Отже, рішення таке: не потійте його. Перейдіть до чогось, що насправді має значення. :)

— Джон
джерело

5

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

— Гейб
джерело

2

Річард: Коли у вас глибоко вкладені структури, вам набагато простіше знайти помилки, оскільки теги, що закриваються, дають більше інформації про наміри.

— Гейб

1

Я думаю, що "закриваючі теги дають більше інформації про наміри" - найкраща стисла відповідь на це питання. Аргументується вагомою зрозумілою причиною так чи інакше.

— squarecandy

4

Моя рекомендація полягає в тому, що ви опускаєте більшість необов’язкових закритих тегів та всіх необов’язкових атрибутів, до яких ви можете піти. Багато ідентифікаторів скаржаться, тому вам не вдасться уникнути пропуску деяких з них, але це, як правило, краще для меншого розміру файлів і менше безладу. Якщо у вас є генератори коду, ви обов'язково опускаєте кінцеві теги, тому що ви можете отримати гарне зменшення розміру від нього. Зазвичай це насправді не має значення так чи інакше.

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

З цікавості я виявив, що якщо я видаляю цитати навколо атрибутів, які їм не потрібні, я можу зекономити 20 КБ, але моєму IDE (Visual Studio) це не подобається. Я також був здивований, виявивши, що дійсно довгий ідентифікатор, який створює ASP.NET, становить 20% мого файлу.

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

— користувач1777246
джерело

Я навряд чи можу прийняти пропущення необов’язкових кінцевих тегів, але я вважаю досить поганою ідеєю опускати цитати на атрибути. Ви ризикуєте своїм сайтом зламати деякі браузери таким чином. Якщо у вас є 800kb html-файли, ви робите щось не так.

— Крістоф

2

@Christoph: Опускати необов'язкові кінцеві теги (як-от </p>або </li>) - це прекрасно відповідно до специфікацій HTML. Якщо браузер цього не розуміє, це проблема з браузером.

— Конрад Боровський

2

Особисто я прихильник XHTML і, як ghoppe, "я намагаюся ніколи не опускати кінцеві теги, тому що це допомагає мені бути суворим і не опускати необхідні теги".

але

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

— Річард JP Le Guen
джерело

2

Використання кінцевих тегів полегшує роботу з фрагментами, оскільки їх поведінка не залежить від елементів братів. Сама ця причина повинна бути досить переконливою. Хтось більше займається монолітними html-документами?

— CurtainDog
джерело

1

У деяких мовах фігурних дужок, таких як C #, ви можете опустити фігурні фігурні дужки навколо оператора if, якщо його довгі лише два рядки. наприклад...

якщо ([умова])
[код]

але ти не можеш цього зробити ...

якщо ([умова])
[код]
[код]

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

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

— МігельР
джерело

Чи можете ви навести приклад HTML, який настільки складний? На мій досвід, необов'язкові кінцеві теги не є настільки оманливими.

— Корнель

Я пам’ятаю, що мала проблему з IE7 кілька років тому, коли я знайшов відкриваючий тег li в окремому рядку з тексту, який він містив, не закриваючи li, IE7 ставився до всіх куль як до однієї великої кулі. розміщення тегу та тексту в одному рядку або закриття тегу вирішило б проблему. Зараз я, здається, не можу спростувати це питання, тому, ймовірно, це також мало щось спільне з програмою css. але я б не звинувачував вас у тому, що ви сприймаєте це як "я цілком маю подругу ... в Канаді!" історія.

— MiguelR

0

Якщо ви писали HTML-аналізатор, чи було б простіше розібрати HTML, який включав необов'язкові теги закриття, або HTML, який не відповідає? Я думаю, що наявні необов'язкові теги закриття полегшать цю роботу, оскільки мені не доведеться робити висновок про те, де повинен бути закриваючий тег.

З цієї причини я завжди включаю необов'язкові теги закриття - на теорію того, що моя сторінка може відображатися швидше, оскільки я створюю менше роботи для HTML-аналізатора браузера.

— Джоел Мюллер
джерело

1

Я не погоджуюсь; Поняття добре сформованості на відміну від дійсності є концепцією лише для XML і стає неактуальною, коли у вас є елементи, тісні теги яких заборонені .

— Річард JP Le Guen

1

Я розумію це, але відображений елемент DOM має і початок, і кінець, навіть якщо ваш тег HTML не відповідає. Якщо ви включите <li>тег із закритим тегом, у якийсь момент браузер повинен буде вирішити, де закінчується елемент, і діяти так, ніби ви поставили кінцевий тег у цій точці. Це може бути порівняно тривіальною кількістю логіки, але "деякі" все-таки більше, ніж "жодні", і я не думаю, що це нерозумно припустити, що вихід із необов'язкових кінцевих тегів робить більше роботи для браузера, ніж їх включення.

— Джоель Мюллер

Це цікавий момент, але я все ще не згоден; близькі теги НЕ є обов'язковими , оскільки вони будуть необхідні і , таким чином , неявними в відповідно до правил перевірки ... тому , коли аналізатор досягає точки , де повинні бути закриває тегом в відповідно до перевіркою, не могло це стверджувати , що завдання споживання закриваючий тег (якщо він присутній) просто уповільнить його?

— Річард JP Le Guen

@Richard - Я вважаю, що це залежить від фактичної реалізації певного браузера, але мені важко зараховувати ідею, що пояснення того, де ви хочете, щоб елемент закінчився, буде гіршим для продуктивності, ніж казати браузеру розібратися в цьому ти.

— Джоель Мюллер

@RichardJPLeGuen Я думаю, все залежить від того, як саме виглядають правила. Коли ви закриваєте a, </table>а ваш стек містить <table><tbody><tr><td>, ви можете просто закрити все, доки не будете відповідати <table>. Аналогічно для відкриття <p>в не-годинному контексті. Але можуть бути набагато важчі випадки, я не знаю.

— maaartinus

-1

Робіть все, що вам здається, робить код більш читабельним і доступним для оновлення.

Особисто я завжди був би схильний до закриття <td>і <tr>, але ніколи б не заважав <li>.

— Меттью Вілсон
джерело

1

Я сподівався на деякі вказівки щодо оригінального дизайнерського рішення, і що вони зробили б х, якби могли.

— Ян Бойд

У чому різниця між цим <td>і <li>змушує вас не турбуватися <li>? Для мене різниця незначна.

— ghoppe

Технічної різниці немає, це суто суб’єктивно. Я відчуваю, що я можу краще прочитати HTML, якщо закрити td і tr. Але я ніколи не відчував потреби з лі.

— Меттью Вілсон

-2

Для заборонених типів закриття використовуйте синтаксис типу: <img />З, />щоб закрити тег, прийнятий у xml

— Дани
джерело

1

Він не працює в HTML4 (він відповідає незрозумілому синтаксису SGML, який робить дещо інше). У HTML5 це дозволено, але безглуздо.

— Корнель