Element-Schreibregeln: Wann welcher Block verwendet wird

Jede Seite im SEO-Playbook beruht auf einer Unterscheidung: Ein Inhalt hat einen Zweck, während seine Überschriftsebene und sein visuelles Erscheinungsbild nur Präsentation sind. Diese Element-Schreibregeln machen diese Unterscheidung zu einem Produktionsvertrag. Befolgen Sie sie, bevor Sie eine Komponente anwenden, einen Artikel zwischen Publikationssystemen konvertieren oder ein Element ändern, das bereits auf veröffentlichten Seiten vorkommt.

Kurzer Überblick

• Prüfen Sie die Element-Bibliothek nach Zweck vor Name. Passt der Zweck eines Elements zur Aufgabe eines Abschnitts, ist dieses Element verpflichtend.
• Verwenden Sie reines Markdown erst, nachdem bestätigt wurde, dass kein typisiertes Element den Zweck der Passage repräsentiert. Freier Text ist ein Rückfall, kein Standard.
• Schreiben Sie den vollständigen Artikel zuerst als reinen Text. Wenden Sie Elemente in einem separaten, von oben nach unten verlaufenden Strukturdurchgang an, damit Komposition und Markup nicht um Aufmerksamkeit konkurrieren.
• Behandeln Sie die Markdown-Direktive als kanonischen erstellten Inhalt. Hugo- und WordPress-Renderer bilden dieselben Felder und den Text in plattformnative Ausgaben ab.
• Halten Sie bestehende veröffentlichte Seiten auf der Bedeutung, gegen die sie geprüft wurden. Eine bruchverursachende Definitionsänderung erzeugt eine neue Version und eine explizite Migration; sie interpretiert niemals stillschweigend alte Inhalte neu.

Die maßgebliche Prioritätsregel

Die Bibliothek muss danach geprüft werden, was eine Passage tut, nicht danach, wie der Autor sie zufällig genannt hat. Namen variieren: Ein Autor betitelt einen Abschnitt vielleicht „Was ist Churn?“, ein anderer „Churn erklärt“ und ein dritter „Eine Arbeitsdefinition“. Ihr Zweck ist identisch, daher bilden alle drei auf dasselbe Definitionselement ab.

Diese Priorität existiert, weil freier Text und ein typisiertes Element auf dem Bildschirm identisch aussehen können, sich aber im weiteren Verlauf völlig unterschiedlich verhalten. Eine gestaltete Überschrift, gefolgt von einem Absatz, mag im Browser wie eine Definitionsbox aussehen, trägt aber keine Komponentenidentität. Sie kann nicht zuverlässig die strukturierte Ausgabe der Definition erzeugen, ihre Felder für einen anderen Renderer bereitstellen, ihre Semantik während einer Migration bewahren oder von einer Qualitätsprüfung gefunden werden, die fragt, ob die Seite eine Definition enthält. Das typisierte Element bildet auf eine Komponente und eine bekannte Datenform ab; visuell ähnlicher freier Text bildet auf nichts ab.

Die Regel ist daher streng:

Bevor Sie eine Überschrift oder einen Inhaltsblock schreiben oder genehmigen, identifizieren Sie dessen Zweck. Wenn dieser Zweck mit einer Elementdefinition übereinstimmt, verwenden Sie das Element. Visuelle Ähnlichkeit, eine vorhandene H2 oder die Fähigkeit, dieselben Wörter in einem Absatz auszudrücken, machen freien Text nicht gleichwertig.

Die Priorität ist semantisch, nicht visuell. Eine Seite kann innerhalb oder um ein Element herum weiterhin normale Überschriften enthalten, wenn dessen Definition dies erlaubt, aber die Überschrift ersetzt niemals den Elementtyp.

Freier Text versus ein typisiertes Element

Nutzen Sie diesen Entscheidungsweg, bis das gemeinsame Diagramm verfügbar ist:

1. Formulieren Sie die Aufgabe der Passage in einem Verb. Beispiele sind definieren, warnen, zusammenfassen, vergleichen, beweisen, anleiten oder zum Handeln auffordern. Dies verhindert, dass der Überschriftentext den zugrundeliegenden Zweck verschleiert.
2. Durchsuchen Sie die Bibliothek nach diesem Zweck und seinen Synonymen. Ein Autor, der nur nach der wörtlichen Überschrift „Was ist X?“ sucht, könnte ein Definitionselement übersehen, dessen Seite „Definitionsbox“ heißt.
3. Verwenden Sie das passende Element, wenn eines existiert. Vergleichen Sie nicht das Erscheinungsbild oder fragen Sie, ob Markdown das Design nachahmen könnte; das registrierte Verhalten ist der entscheidende Faktor.
4. Verwenden Sie freien Text, wenn kein Zweck übereinstimmt. Dies ist korrekt für verbindende Erklärungen, Argumentation, Analyse, narrativen Kontext und Übergänge, die zum Hauptfluss des Artikels gehören und kein eigenständiges Komponentenverhalten erfordern.
5. Dokumentieren Sie eine wiederholte Lücke. Wenn derselbe nicht abgedeckte Zweck auf mehreren Seiten auftaucht, schlagen Sie ein Bibliothekselement vor, anstatt eine einmalige Direktive oder CSS-Behandlung in einem Artikel zu erfinden.

Reines Markdown ist tatsächlich korrekt, wenn die Worte die fortlaufende Argumentation des Artikels bilden und kein unabhängiges Etikett, keinen Datenvertrag, keine Interaktion und keinen Wiederverwendungspfad benötigen. Beispielsweise sind zwei Absätze, die erklären, warum eine Empfehlung aus den vorhergehenden Beweisen folgt, normale Prosa. Eine kompakte Zusammenstellung von Schlussfolgerungen am Anfang ist nicht allein deshalb normale Prosa, weil sie als Aufzählungspunkte geschrieben werden kann; sie hat den anerkannten Zweck eines Überblicks- oder Erkenntnis-Elements.

Häufige Verwechslungen, die zu falschem Markup führen

Diese Fälle werden explizit aufgeführt, weil sie eine visuelle Prüfung leicht bestehen. Der Fehler wird erst sichtbar, wenn ein anderer Renderer, Validator, Suchindex oder strukturierter Ausgabe-Konsument die Seite erhält.

Die Unterscheidung zwischen wichtigen Erkenntnissen und einem kurzen Überblick ist besonders wichtig. Verwenden Sie Erkenntnisse, wenn die Punkte Schlussfolgerungen sind, an die sich der Leser erinnern sollte, was bedeutet, dass sie oft erst geschrieben werden können, nachdem der Artikel existiert. Verwenden Sie einen Überblick, wenn die Punkte den Leser vor dem Lesen über Umfang oder Ablauf orientieren. Wählen Sie nach dieser redaktionellen Aufgabe, selbst wenn das aktuelle Theme beide Komponenten ähnlich aussehen lässt.

Direktiven- und Attributsyntax

Die kanonische Markdown-Form verwendet eine benannte Blockdirektive. Attribute folgen dem Direktivennamen innerhalb von geschweiften Klammern:

:::element-name{key=value key2="value with spaces" .class}
Body-Inhalt
:::

Attribute dienen dazu, kleine, stabile Eigenschaften zu transportieren, die die Bedeutung oder unterstützte Darstellung des Elements beeinflussen. Sie maschinenlesbar zu halten, verhindert, dass Autoren Konfiguration in Prosa verstecken. Verwenden Sie key=value für einen Wert ohne Leerzeichen und key2="value with spaces", wenn Leerzeichen vorhanden sind. Ein nicht in Anführungszeichen gesetzter Attributwert darf keine Leerzeichen enthalten. Ein führender Punkt fügt eine unterstützte Klasse hinzu, wie in .compact; er ist kein Ort, um seiten-spezifisches Styling zu erfinden.

Attributschlüssel werden in Kleinbuchstaben geschrieben und verwenden die genaue Schreibweise, die auf der Elementseite definiert ist. Boolesche und aufgezählte Werte folgen ebenfalls dem Vertrag dieser Seite. Erstellen Sie kein Attribut, nur weil ein Renderer es zufällig toleriert: Ein nicht deklariertes Attribut hat keine plattformübergreifende Garantie.

Schließende :::-Begrenzungen gehören zum äußeren Element. Halten Sie sie in eigenen Zeilen, damit ein Parser den Body vom nächsten Absatz unterscheiden kann. Codebeispiele, die Direktiven demonstrieren, müssen innerhalb von umrandeten Codeblöcken bleiben, wie auf dieser Seite, damit Hugo sie nicht als Inhalt interpretiert.

Standard-Body-Mapping

Die meisten Elemente benötigen einen kurzen Titel und einen längeren Body. Würde man Autoren verlangen, diese als Attribute zu wiederholen, wäre langer Text schwer zu bearbeiten und leicht falsch zu escapen, daher stellt der Body das Standard-Mapping bereit:

:::example
## Eine konkrete Überschrift

Der Rest des Bodys kann Absätze, Listen, Links und andere Inhalte enthalten, die die Elementdefinition erlaubt.
:::

Sofern eine Elementseite die Regel nicht explizit überschreibt, wird die erste Überschrift im Body auf title abgebildet, und alles nach dieser Überschrift auf content. Der Überschriftenmarker drückt die Quellhierarchie für Editoren aus; das abgebildete Feld ermöglicht es jeder Plattform, die entsprechende semantische Überschriftsebene im Kontext darzustellen.

Nur die erste Body-Überschrift erhält diese Sonderbehandlung. Spätere Überschriften bleiben Teil von content. Wenn der Body keine Überschrift hat, fehlt title; das ist nur gültig, wenn die Elementdefinition ihren Titel als optional kennzeichnet. Wenn ein Element benannte Slots oder ein anderes Mapping definiert, hat seine eigene Seite Vorrang vor dieser Voreinstellung, da der Renderer genau wissen muss, wohin jedes Fragment gehört.

Verschachtelte Elemente

Einige Elemente enthalten eine wiederholbare Liste, deren Einträge jeweils Attribute und einen Body benötigen, wie Schritte mit Kennungen, Karten mit Beschriftungen oder Checklistenelemente mit einem Anfangszustand. Diese Einträge in eine Markdown-Liste zu flatten, würde ihre individuellen Felder verlieren, daher verwenden verschachtelte Elemente eine explizite Item-Direktive:

:::parent-element{variant=compact}
::item{key=value}
### Erster Item-Titel

Die Erklärung des ersten Items.
::
::item{key2="value with spaces"}
### Zweiter Item-Titel

Die Erklärung des zweiten Items.
::
:::

Der Vertrag ist ::item{key=value} … ::: Zwei Doppelpunkte öffnen jedes Item, der Singularname ist item, und zwei Doppelpunkte schließen es. Das Elternelement behält seine schließende Begrenzung mit drei Doppelpunkten. Dieser visuelle Unterschied ist wichtig, weil er die Verschachtelung ohne Einrückung eindeutig macht, die leicht durch Kopieren und Einfügen beschädigt werden kann.

Jedes Item wendet dasselbe Standard-Body-Mapping an, sofern die Eltern-Elementseite nichts anderes sagt: Seine erste Überschrift wird zum title dieses Items, und der Rest wird zu seinem content. Setzen Sie Attribute auf das Item, wenn sie nur dieses Item beschreiben; setzen Sie sie auf das Elternelement, wenn sie die Sammlung als Ganzes betreffen.

Links, Bilder und Inline-Buttons

Portabler Quellcode benötigt vorhersagbare Pfade. Eine relative URL sollte relativ zum Site-Stammverzeichnis sein, nicht zur aktuellen Markdown-Datei, da dieselbe Quelle in Hugo in einer anderen Dateisystemtiefe gerendert oder in WordPress importiert werden kann.

• Interne Seitenlinks verwenden einen führenden und einen abschließenden Schrägstrich, wie der Link zur Element-Bibliothek . Verwenden Sie nicht ../, lassen Sie den führenden Schrägstrich nicht weg und hardcodieren Sie nicht die Produktionsdomain für eine interne Seite.
• Externe Links verwenden eine vollständige https://-URL. Das Schema ist Teil des Ziels und darf nicht von einem Renderer abgeleitet werden.
• Bildquellendateien liegen unterhalb von cdn-assets/seo-playbook/, und ihre öffentlichen Pfade beginnen mit /cdn-assets/seo-playbook/. Hängen Sie die genehmigte Gruppe und den Dateinamen erst an, wenn das Asset existiert.
• Alternativtext beschreibt die durch ein Bild vermittelte Information, nicht seinen Dateinamen oder sein dekoratives Erscheinungsbild. Ein dekoratives Bild verwendet einen leeren Alternativtext, aber die relevante Elementseite muss Dekoration explizit erlauben.
• Ein Inline-Call-to-Action verwendet :button[Sichtbares Label]{href="/target/"}. Der Text in Klammern ist das barrierefreie Label und href folgt denselben Regeln für interne oder externe Pfade. Verwenden Sie einen Button nur für eine echte nächste Aktion, nicht um einen gewöhnlichen Referenzlink hervorzuheben.

Ein Bild ist Inhalt, kein Workaround für nicht unterstütztes Layout. Wenn das Bild wesentliche Beschriftungen, Zahlen oder Anweisungen enthält, wiederholen Sie diese Informationen in barrierefreiem Text oder verwenden Sie ein strukturiertes Element, das sie bereitstellt. Screenshot-Erfassungsanfragen bleiben als HTML-Kommentare, bis das benannte Asset existiert; sie sind keine veröffentlichten Bildreferenzen und müssen screenshotsPending = true im Frontmatter setzen.

Frontmatter und Body-Elemente haben unterschiedliche Aufgaben

Frontmatter beschreibt das Dokument als Dokument. Body-Direktiven beschreiben sinnvolle Blöcke innerhalb des Leseerlebnisses. Die Trennung dieser Ebenen ermöglicht es Auflistungsseiten, Schemata, Routing und Publikationswerkzeugen, Metadaten zu lesen, ohne sichtbare Prosa zu parsen.

Metadatenelemente leben daher im Frontmatter: Seitentitel, Beschreibung, Schlüsselwörter, Veröffentlichungs- und Aktualisierungsdaten, kanonische Informationen oder Alias-Informationen, Eigentümerschaft, Taxonomie, Playbook-Verknüpfungen und alle schemaorientierten Sammlungen, die der Seitenvertrag dort platziert, wie FAQ-Einträge auf Akademieseiten. Diese Felder werden niemals als :::-Direktiven geschrieben. Ein sichtbarer Block, der einige Metadaten wiederholt, verschiebt das maßgebliche Feld nicht aus dem Frontmatter; er erhält nur dann ein eigenes Body-Element, wenn er einen separaten, leserorientierten Zweck hat.

Content-Elemente leben im Body: Definitionen, Warnungen, Tipps, Überblicke, Erkenntnisse, Checklisten, Vergleiche, Beweisblöcke, Beispiele, Schritte und Calls-to-Action. Sie sind Direktiven, weil ihre Position in der Erzählung wichtig ist. Das Verschieben einer Warnung ins Frontmatter würde sie von der Passage trennen, die sie qualifiziert; das Verstecken von Metadaten in einer Body-Direktive würde dokumentenweite Systeme daran hindern, sie zuverlässig zu finden.

Metadaten sind standardmäßig erforderlich

Metadaten steuern Routen, Vorschauen, Auffindbarkeit, Verknüpfungen und strukturierte Ausgaben, bevor jemand den Body liest. Ein weggelassenes Feld kann daher Konsumenten beeinträchtigen, die den Artikel nie rendern. Aus diesem Grund ist jedes Metadatenelement erforderlich, es sei denn, seine Elementseite gibt explizit an, dass es optional ist.

Erforderlich bedeutet mit einem gültigen Wert gefüllt, nicht lediglich als leerer String oder leere Sammlung vorhanden. Leiten Sie Optionalität nicht aus dem Fehlen auf einer anderen Seite ab und fügen Sie keine Platzhalterwerte ein, um die Validierung zu bestehen. Wenn ein erforderlicher Wert noch nicht bekannt ist, ist die Seite nicht zur Veröffentlichung bereit. Body-Elemente folgen den Anforderungsregeln des relevanten Beitragstyps und der Elementseiten, nicht dieser Metadaten-Standardregel.

Erst schreiben, dann Elemente anwenden

Die Elementauswahl ist eine Klassifizierungsaufgabe, während das Verfassen eine Denkaufgabe ist. Beides Satz für Satz ausführen zu wollen, bringt den Autor dazu, vorzeitig für Komponentengrenzen zu optimieren. Das übliche Ergebnis sind schwächere Übergänge, oberflächliche Erklärungen, die auf eine Box zugeschnitten sind, repetitive Überschriften, die erstellt wurden, um Markup zu erfüllen, und Direktiven, die aus Bequemlichkeit gewählt wurden, nicht weil ihr Zweck übereinstimmt.

Die Produktion erfolgt daher in zwei getrennten Durchgängen:

1. Schreiben Sie den gesamten Artikel als reinen Text. Vervollständigen Sie die Argumentation, Beispiele, Einschränkungen, Übergänge und Schlussfolgerung. In dieser Phase können Überschriften die Logik des Entwurfs beschreiben, aber sie legen den endgültigen Elementtyp nicht fest.
2. Wenden Sie Elemente in einem separaten, von oben nach unten verlaufenden Durchgang an. Formulieren Sie für jede Überschrift und jeden Block deren Zweck, prüfen Sie die Bibliothek, umschließen Sie passende Abschnitte, fügen Sie deklarierte Attribute hinzu und bestätigen Sie Body-Mapping und Verschachtelung.

Die Trennung verbessert beide Ergebnisse. Der Prosatext entwickelt sich nach den Fragen des Lesers statt nach den Boxgrößen des aktuellen Themes, während der Markup-Durchgang ähnliche Blöcke konsistent über das gesamte Dokument vergleichen kann. Er macht auch Auslassungen sichtbar: Ein Autor kann sehen, dass der Artikel eine Warnung oder Definition enthält, bevor er entscheidet, wie er sie codiert.

Lesen Sie die Seite nach dem Strukturdurchgang einmal, ohne auf die Direktivennamen zu achten. Elemente müssen einen kohärenten Artikel unterstützen, nicht in einen Stapel unverbundener Widgets verwandeln. Überprüfen Sie dann einmal die Quelle, ohne die Prosa zu beurteilen, und verifizieren Sie Begrenzungen, Attribute, verschachtelte Items, Pfade und erforderliche Metadaten.

Der Drei-Notationen-Vertrag

Ein Element wird einmal definiert durch seinen Zweck, kanonische Felder, zulässige Werte, Body-Mapping, Barrierefreiheitsverhalten, strukturiertes Ausgabeverhalten und Version. Diese Definition ist die Quelle der Wahrheit. Die drei Plattformnotationen sind Adapter dafür, keine drei unabhängigen Komponentendesigns.

Die repräsentativen Formen erklären das Mapping; die einzelne Elementseite veröffentlicht ihren genauen unterstützten Namen und ihre Felder. Autoren arbeiten in der Notation, die ihr Publishing-Workflow erfordert, aber sie benennen Felder nicht um, fügen keine plattformeigenen Bedeutungen hinzu oder imitieren manuell das HTML eines anderen Renderers.

Der Elementverantwortliche pflegt die kanonische Definition und entscheidet, ob eine vorgeschlagene Änderung kompatibel oder versioniert ist. Hugo- und WordPress-Verantwortliche besitzen ihre Adapter und testen sie gegen gemeinsame Testdaten: Derselbe Titel, Inhalt, Attribute, Items, Links und Barrierefreiheitserwartungen müssen alle drei Pfade überstehen. Redaktionsverantwortliche verifizieren Zweck und Beispiele. Kein Plattformverantwortlicher darf die redaktionelle Bedeutung lokal neu definieren; wenn eine Plattform den Vertrag nicht ausdrücken kann, ist das ein Adapterfehler oder ein vorgeschlagener Vertragswechsel.

Dieses Modell erlaubt es, dass die Darstellung dort unterschiedlich ist, wo Plattformen es erfordern, während die Semantik stabil bleibt. Hugo könnte serverseitiges HTML rendern und WordPress könnte einen Blockkommentar speichern, aber eine Warnung bleibt eine Warnung, ein Checklisten-Item bleibt ein Item, und dieselben erforderlichen Felder bleiben nachgelagert verfügbar.

Versionierung veröffentlichter Elemente

Veröffentlichte Inhalte wurden gegen die Elementbedeutung geprüft, die zum Zeitpunkt der Veröffentlichung bestand. Diese Bedeutung stillschweigend zu ändern, kann Warnungen, strukturierte Daten, Barrierefreiheit oder Importe verändern, ohne dass ein Redakteur die Seite berührt. Die Versionierung schützt diese redaktionelle Freigabe.

Verwenden Sie die folgende Änderungsrichtlinie:

• Kompatible Renderer-Änderung: Eine visuelle Verfeinerung, Leistungsverbesserung oder Fehlerbehebung, die Zweck, Felder, akzeptierte Werte, Body-Mapping und Ausgabebedeutung bewahrt, kann innerhalb der aktuellen Version ausgeliefert werden. Bestehende Seiten erhalten sie über den Renderer.
• Kompatible additive Änderung: Ein neues optionales Attribut darf sich der aktuellen Version nur anschließen, wenn sein Fehlen die bestehende Ausgabe bewahrt und jeder Adapter es sicher ignorieren oder unterstützen kann. Die Definition und die Plattformtests ändern sich gemeinsam.
• Bruchverursachende Änderung: Ein umbenanntes oder entferntes Feld, ein neues Pflichtfeld, geändertes Body-Mapping, geänderter Zweck, geänderter Standardwert mit semantischer Wirkung oder eine inkompatible verschachtelte Item-Struktur erzeugt eine neue Hauptversion des Elements.
• Deprecation: Die alte Version bleibt für veröffentlichte Seiten renderbar. Ihre Elementseite identifiziert den Ersatz und den Migrationspfad; neue Seiten verwenden die aktuelle Version.
• Migration: Eine Inhaltsmigration ist explizit, abgegrenzt, in Markdown, Hugo und WordPress vorgeprüft und redaktionell vor der Veröffentlichung validiert. Dokumentieren Sie, welche Seiten sich geändert haben und warum. Lassen Sie keinen Renderer raten, wie alte Quellen neu interpretiert werden sollen.

Wenn keine Version im Quelltext geschrieben ist, verwendet das Element die Basislinienversion, die bei Annahme dieses Vertrags definiert wurde. Diese implizite Basislinie muss stabil bleiben. Neue Hauptversionen identifizieren sich mit dem auf der Elementseite deklarierten Versionierungsmechanismus; sie zweckentfremden nicht die unversionierte Syntax.

Auch ein Rollback ist wichtig. Behalten Sie den vorherigen Renderer und die Quellendarstellung bei, bis migrierte Seiten strukturelle, visuelle, Barrierefreiheits- und strukturierte Ausgabe-Prüfungen bestehen. Wenn eine Migration fehlschlägt, stellen Sie die vorherige Versionsabbildung wieder her, anstatt das Element in freien Text zu flatten, was die Semantik verwerfen würde, die die Versionierung schützen soll.

Produktionsprüfliste

Verwenden Sie diese abschließende Prüfung nach dem Prosa-Durchgang und dem Element-Durchgang:

• Kann der Zweck jedes Nicht-Prosa-Blocks in einem Verb angegeben werden?
• Wurde die Bibliothek nach diesem Zweck und nahen Synonymen durchsucht?
• Verwendet jeder passende Zweck sein typisiertes Element, selbst wenn eine H2 und ein Absatz ähnlich aussehen würden?
• Ist jede verbleibende Freitext-Passage Teil der fortlaufenden Erklärung, Analyse, Erzählung oder des Übergangs des Artikels?
• Folgen Attribute dem Format {key=value key2="value with spaces" .class}, mit in Anführungszeichen gesetzten Leerzeichen und nur deklarierten Schlüsseln?
• Bildet die erste Body-Überschrift auf title und der Rest auf content ab, es sei denn, die Elementseite deklariert ein anderes Mapping?
• Verwenden wiederholbare Kinder ::item{key=value} … ::, mit Eltern- und Item-Attributen auf der richtigen Ebene?
• Sind interne Links stammverzeichnis-relativ mit führenden und abschließenden Schrägstrichen, externe Links absolut und Bildpfade innerhalb des genehmigten Bild-Stammverzeichnisses?
• Sind Metadatenfelder im Frontmatter, niemals als Body-Direktiven, und sind alle erforderlichen Metadatenwerte vollständig?
• Können dieselben kanonischen Felder verlustfrei auf Markdown, Hugo und WordPress abgebildet werden?
• Bewahrt jede Definitionsänderung alte Seiten oder führt eine explizite Version und Migration ein?

Diese Seite ist eine Voraussetzung für jede einzelne Elementseite. Jede Elementdefinition muss auf diese Basisregeln zurückverweisen und dann nur ihre zweckspezifischen Ausnahmen dokumentieren: unterstützte Attribute, erforderliche Felder, Body- oder Item-Mapping-Überschreibungen, erlaubte Verschachtelung, exakte Plattformnamen und Versionsgeschichte. Wenn eine Elementseite dazu schweigt, gelten die Standardeinstellungen dieser Seite.