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

14

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ąć?

Blueberryfields
źródło
2
Niezależnie od aktualnych odpowiedzi, wygląda to na kretyński projekt. „Bądź liberalny w tym, co akceptujesz, i konserwatywny w tym, co wysyłasz” i tak dalej. Jest to również całkowicie niepotrzebne. Chciałbym zdecydowanie przedkłada (silnie sformułowane) raport o błędzie do MoinMoin. Przynajmniej powinni jasno dokumentować i komentować to nieintuicyjne zachowanie.
Konrad Rudolph,

Odpowiedzi:

33

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.

Yannis
źródło
5
Sądzę, że wielkie umysły myślą podobnie. :)
Robert Harvey
@RobertHarvey Wygrywasz tę rundę o 12 sekund ...
yannis
2
Kolejny argument przemawiający za pominięciem znaczników końcowych: są one widoczne w strukturze dokumentu, a przy niewłaściwym użyciu mogą również wprowadzać fałszywe białe znaki.
Jon Purdy,
1
Możliwość pominięcia znaczników końcowych była jawną cechą projektową SGML, na której oparty był HTML. Nie była to również wyraźnie cecha XML, na której oparty jest XHTML.
Alan Shutko
4
Jednym z argumentów, który dużo widzę, jest to, że wygląda na czystsze. Zwłaszcza w przypadku <li>tagów tagi działają bardziej jak punktory.
DisgruntledGoat
16

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.

Robert Harvey
źródło