Почему лишний закрывающий тег

создает пустой абзац?

По-видимому, если у вас есть конечный тег

без соответствующего начального тега в элементе body, большинство, если не все браузеры, создадут вместо него пустой абзац :

. Даже если вокруг закрывающего тега существует какой-либо текст, он не становится частью этого элемента p— он всегда будет пустым, а текстовые узлы всегда будут существовать сами по себе :

some text
more text

. Если указанное выше содержимое bodyзаключить в теги

и

... Я оставлю вас догадываться, что произойдет:

some text
more text

Интересно, что если тегу

не предшествует тег или , все браузеры, кроме IE9 и старше, не будут генерировать пустой абзац (IE ≤ 9, с другой стороны. всегда будет создавать один, в то время как IE10 и более поздние версии ведут себя так же, как и все другие браузеры):

Я не могу найти никаких ссылок, оговаривающих, что конечный тег без соответствующего начального тега должен генерировать пустой элемент, но это не должно вызывать удивления, учитывая, что это вообще недействительный HTML. Действительно, я обнаружил, что браузеры делают это только с элементом p(и, в некоторой степени, с элементом br! ), но никаких объяснений почему.

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

На самом деле, я нашел этот комментарий к ответу на несколько родственный вопрос , который в основном подтверждает его:

The reason why

tags are valid unclosed is that originally

was defined as a "new paragraph" marker, rather than p being a container element. Equivalent to
being a "new line" marker. You can see so defined in this document from 1992:http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html and this one from 1993: http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt Because there were web pages pre-dating the change and browser parsers have always been as backward compatible as possible with existing web content, it's always stayed possible to use

that way.

Но это не совсем объясняет, почему синтаксические анализаторы рассматривают явный

конечный тег (с косой чертой )как просто... тег,и сгенерировать пустой элемент в DOM. Является ли это частью какого-то соглашения об обработке ошибок синтаксического анализатора, принятого еще в те далекие времена, когда синтаксис не был так строго определен, как раньше moreнедавно что ли? Если да, то документировано ли это где-нибудь вообще?