Decyzja projektowa - po co generować <p> bez </p>?

tl; dr

Niektóre powszechnie używane programy, które generują HTML, generują tylko otwierające znaczniki akapitów, a nie zamykające, zakładając, że przeglądarka prawidłowo zamyka akapity.

Na pierwszy rzut oka wydaje mi się, że założenie, że przeglądarki będą poprawnie zamykać akapity, jest nieprawidłowe. Czy moja interpretacja jest poprawna? Mówiąc bardziej ogólnie, jakie kompromisy wiążą się z tego rodzaju decyzją?

Przeglądając kod źródłowy moinmoin, mój wiersz przykuł moją uwagę:

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

( źródło )

Po przeczytaniu całej reszty implementacji przekonałem się, że tak, rzeczywiście, kiedy moinmoin generuje kod HTML dla jednej ze swoich stron, w razie potrzeby poprawnie wygeneruje otwarte akapity, a jednocześnie celowo uniknie akapity zamykają tagi (pomimo tego, że mogą to zrobić w trywialny sposób).

W moim konkretnym, raczej nietypowym przypadku użycia, takie zachowanie jest nieprawidłowe. Kusi mnie, aby przesłać raport o błędzie i / lub zmienić zachowanie. Wygląda jednak na to, że ta decyzja projektowa została starannie przemyślana. Nie jestem wystarczająco dobrze zaznajomiony z zawiłościami standardu HTML lub różnych implementacji przeglądarki, aby móc stwierdzić, czy ogólnie jest to prawidłowe zachowanie, i mam wrażenie, że mój instynkt do poprawienia / zmiany tego zachowania może być wprowadzony w błąd.

Czy ten kod stanowi prawidłowe założenie dotyczące implementacji przeglądarki? Czy wygenerowany HTML jest prawidłowy? Mówiąc bardziej ogólnie, jakich kompromisów mogę tutaj pominąć?

Tagi końcowe pelementów były opcjonalne w HTML i były wymagane tylko w XHTML. Jednak wersja robocza HTML5 wprowadza zestaw warunków, w których ptag końcowy jest w rzeczywistości opcjonalny:

Znacznik końcowy elementu p można pominąć, jeśli po elemencie p następuje bezpośrednio adres, artykuł, bok, cytat, dir, div, dl, zestaw pól, stopka, formularz, h1, h2, h3, h4, h5, h6, nagłówek , hgroup, hr, menu, nav, ol, p, pre, section, table lub ul, element, lub jeśli w elemencie nadrzędnym nie ma już treści, a element nadrzędny nie jest elementem.

_{Źródło: specyfikacja HTML5}

To powiedziawszy, jedynym argumentem, jaki słyszałem o pomijaniu znaczników końcowych pelementów, jest rozmiar dokumentu. To Ty decydujesz, czy ma to sens dla twojego dokumentu, czy nie. Osobiście zwykle dołączam wszystkie opcjonalne znaczniki końcowe, na wypadek, gdy nie spełniam wymagań, kiedy znacznik końcowy jest opcjonalny.

Specyfikacja W3C dla HTML5 wyraźnie stwierdza, że:

Znacznik końcowy elementu p można pominąć, jeśli po elemencie p następuje bezpośrednio adres, artykuł, bok, cytat, dir, div, dl, zestaw pól, stopka, formularz, h1, h2, h3, h4, h5, h6, nagłówek , hr, menu, nav, ol, p, pre, sekcja, tabela lub element ul, lub jeśli w elemencie nadrzędnym nie ma już treści, a element nadrzędny nie jest elementem.

Tak więc w zasadzie specyfikacja zapewnia wiele sposobów, dzięki którym można uniknąć złożoności (dużej lub małej) zamknięcia tagu. Każda zgodna implementacja przeglądarki musiałaby uwzględniać te wyjątki.