Entwurfsentscheidung - warum <p> ohne </ p> generieren?


14

tl; dr

Einige weit verbreitete Programme, die HTML generieren, generieren nur öffnende Absatzmarken und keine schließenden, vorausgesetzt, der Browser schließt Absätze ordnungsgemäß.

Auf den ersten Blick scheint mir die Annahme, dass Browser Absätze ordnungsgemäß schließen, nicht korrekt zu sein. Ist meine Interpretation korrekt? Welche Kompromisse sind generell mit dieser Art von Entscheidung verbunden?


Beim Durchsuchen des moinmoin-Quellcodes ist mir folgende Codezeile aufgefallen:

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

( Quelle )

Nachdem ich den Rest der Implementierung durchgelesen habe, habe ich mich davon überzeugt, dass moinmoin, wenn es HTML-Code für eine seiner Seiten generiert, gegebenenfalls Absatz-Open-Tags korrekt generiert, während gleichzeitig gezielt Folgendes vermieden wird Tags schließen den Absatz (obwohl dies trivial möglich ist).

Für meinen speziellen, eher ungewöhnlichen Anwendungsfall ist dieses Verhalten nicht korrekt. Ich bin versucht, einen Fehlerbericht einzureichen und / oder das Verhalten zu ändern. Es sieht jedoch so aus, als ob diese Designentscheidung sorgfältig getroffen wurde. Ich bin nicht gut genug mit den Feinheiten des HTML-Standards oder den verschiedenen Browser-Implementierungen vertraut, um feststellen zu können, ob dies im Allgemeinen das richtige Verhalten ist, und ich habe das Gefühl, dass mein Instinkt, dieses Verhalten zu korrigieren / zu ändern, dies sein könnte fehlgeleitet.

Entspricht dieser Code einer gültigen Annahme für Browserimplementierungen? Ist der generierte HTML-Code gültig? Welche Kompromisse könnte ich hier allgemein vermissen?


2
Ungeachtet der aktuellen Antworten sieht dies wie ein schwachsinniges Design aus. "Sei liberal in dem, was du akzeptierst und konservativ in dem, was du sendest" und all das. Es ist auch völlig unnötig. Ich würde Moinmoin auf jeden Fall einen (stark formulierten) Fehlerbericht übermitteln. Zumindest sollten sie dieses nicht intuitive Verhalten klar dokumentieren und kommentieren.
Konrad Rudolph

Antworten:


33

End-Tags für pElemente waren in HTML optional und nur in XHTML erforderlich. Der HTML5-Entwurf führt jedoch eine Reihe von Bedingungen ein, wenn das pEnd-Tag tatsächlich optional ist:

Das End-Tag eines p-Elements kann weggelassen werden, wenn dem p-Element unmittelbar eine Adresse, ein Artikel, eine Blockquote, ein Verzeichnis, ein Div, ein Dl, eine Feldmenge, eine Fußzeile, eine Form, ein h1, ein h2, ein h3, ein h4, ein h5, ein h6, eine Kopfzeile folgt , hgroup, hr, menu, nav, ol, p, pre, section, table oder ul, element, oder wenn das übergeordnete Element keinen Inhalt mehr enthält und das übergeordnete Element kein Element ist.

Quelle: HTML5-Spezifikation

Das einzige Argument, das ich jemals gehört habe, um die End-Tags für pElemente wegzulassen, ist die Dokumentgröße. Es liegt ganz bei Ihnen zu entscheiden, ob dies für Ihr Dokument sinnvoll ist oder nicht. Persönlich neige ich dazu, alle optionalen End-Tags einzuschließen, nur für den Fall, dass ich die Anforderungen nicht erfülle, wenn das End-Tag optional ist.


5
Großartige Köpfe denken wohl gleich. :)
Robert Harvey

@RobertHarvey Du gewinnst diese Runde um 12 Sekunden ...
yannis

2
Ein weiteres Argument für das Weglassen von End-Tags: Sie gehen aus der Dokumentenstruktur hervor und können bei Missbrauch auch falsche Leerzeichen einführen.
Jon Purdy

1
Das Weglassen von End-Tags war ausdrücklich ein Design-Feature von SGML, auf dem HTML basierte. Es war auch ausdrücklich KEINE Funktion von XML, auf der XHTML basiert.
Alan Shutko

4
Ein Argument, das ich oft sehe, ist, dass es sauberer aussieht. Insbesondere bei <li>Tags verhalten sich die Tags eher wie Aufzählungspunkte.
DisgruntledGoat

16

In der W3C-Spezifikation für HTML5 heißt es insbesondere:

Das End-Tag eines p-Elements kann weggelassen werden, wenn dem p-Element unmittelbar eine Adresse, ein Artikel, eine Blockquote, ein Verzeichnis, ein Div, ein Dl, eine Feldmenge, eine Fußzeile, eine Form, ein h1, ein h2, ein h3, ein h4, ein h5, ein h6, eine Kopfzeile folgt , hr, menu, nav, ol, p, pre, section, table oder ul-Element, oder wenn das übergeordnete Element keinen Inhalt mehr enthält und das übergeordnete Element kein Element ist.

Im Grunde hat die Spezifikation viele Möglichkeiten bereitgestellt, mit denen die Komplexität (groß oder klein) des Schließens des Tags vermieden werden kann. Jede konforme Browser-Implementierung müsste diese Ausnahmen berücksichtigen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.