Дизайнерське рішення - навіщо генерувати <p> без </p>?


14

тл; д-р

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

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


Переглядаючи вихідний код moinmoin, наступний рядок коду потрапив на мене:

# We only open those tags and let the browser auto-close them:
_auto_closing_tags = set(['p'])

( джерело )

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

Для мого конкретного, досить незвичного випадку використання, така поведінка є невірною. Мені спокуса подати звіт про помилку та / або змінити поведінку. Однак, схоже, таке дизайнерське рішення було продумано. Я недостатньо добре розбираюся в тонкощах стандарту html або різних реалізаціях браузера, щоб можна було сказати, чи правильно це поведінка в цілому, і я маю відчуття, що мій інстинкт виправити / змінити цю поведінку може бути неправильно керуватися.

Чи робить цей код обґрунтованим припущення про реалізацію браузера? Чи згенерований html дійсний? Загалом, які компроміси я можу тут пропустити?


2
Незважаючи на те, що відповіді нинішні, це виглядає як дивовижна конструкція. "Будьте ліберальні в тому, що приймаєте, і консервативні в тому, що ви надсилаєте", і все таке. Це також зовсім непотрібно. Я обов'язково надішлю (Monsmoin) звіт про помилки (з чіткими словами). Принаймні, вони повинні чітко документувати та коментувати цю неінтуїтивну поведінку.
Конрад Рудольф

Відповіді:


33

Кінцеві теги для pелементів необов’язкові в HTML і вимагалися лише в XHTML. Однак у проекті HTML5 вводиться набір умов, коли pкінцевий тег насправді є необов'язковим:

Кінцевий тег p елемента може бути опущений, якщо елемент p негайно супроводжується адресою, статтею, убік, blockquote, dir, div, dl, набором поля, колонтитулом, формою, h1, h2, h3, h4, h5, h6, заголовком , hgroup, hr, меню, nav, ol, p, pre, section, table, або ul, element, або якщо в батьківському елементі немає більше вмісту, і батьківський елемент не є елементом.

Джерело: Специфікація HTML5

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


5
Думаю, чудові розуми однаково. :)
Роберт Харві

@RobertHarvey Ви виграєте цей раунд, за 12 секунд ...
yannis

2
Ще один аргумент на користь пропускання кінцевих тегів: вони видно із структури документа, і при неправильному використанні вони також можуть ввести помилковий пробіл.
Джон Перді

1
Можливість опускати кінцеві теги явно була особливістю дизайну SGML, на основі якого був HTML. Це також явно НЕ була особливістю XML, на якій базується XHTML.
Алан Шутко

4
Один аргумент, який я багато бачу, - це те, що він виглядає чистіше. Зокрема, що стосується <li>тегів, теги діють більше, як точки кулі.
НезадоволенняGoat

16

У специфікації W3C для HTML5 конкретно зазначено, що:

Кінцевий тег p елемента може бути опущений, якщо елемент p негайно супроводжується адресою, статтею, убік, blockquote, dir, div, dl, набором поля, колонтитулом, формою, h1, h2, h3, h4, h5, h6, заголовком , hr, меню, nav, ol, p, pre, section, table, або ul element, або якщо в батьківському елементі немає більше вмісту, і батьківський елемент не є елементом.

Таким чином, специфікація запропонувала безліч способів, завдяки яким можна уникнути складності (великої чи малої, яка може бути) закриття тегу. Будь-яка відповідна версія браузера повинна відповідати цим виняткам.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.