Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/flow/tag
WikiSyntaxTextMod → Syntaxpolitur → Schritt 2
In einem zweiten Schritt der Syntaxpolitur erfolgt die Standardisierung der tags, also der <tag>
.
Geltungsbereich
Das gebräuchliche, einheitliche Erscheinungsbild von tags wird hergestellt. Zum einen sollen menschliche Autoren nicht verwirrt werden, zum anderen wird Bots und Skripten das Identifizieren von Strukturen erleichtert, teils erstmalig ermöglicht.
Es werden nur die bekannten Elemente verarbeitet:
a applet area audio b base bdi big blockquote body br button center code command dfn div em embed font form frame frameset gallery graph h1 h2 h3 h4 h5 h6 head hiddentext hiero hr html i iframe imagemap img includeonly input inputbox isindex kbd layer link map math meta noinclude nowiki object onlyinclude option pages poem pre rb rbc ref references rp rt rtc ruby s samp score script section select small source span strike strong style sub sup syntaxhighlight templatedata textarea timeline title tt u wbr xml
Hinzu kommen Kommentare.
Alle unbekannten tags werden ignoriert.
Formatierung
Für die Formatierung gilt:
- Ein mit
<
begonnenes bekanntes Tag muss auch mit>
geschlossen werden; dazwischen sind keine<
(oder auch>
) erlaubt. - Nach und vor den begrenzenden
< >
stehen keine Leerzeichen. - Alle bekannten (oben aufgezählten) Bezeichner von Tags werden in standardisierte Kleinschreibung überführt.
- Wird unmittelbar nach
<
oder vor>
ein umgekehrter Schrägstrich angetroffen, so wird ein händischer Fehler unterstellt und in regulären Schrägstrich umgewandelt. - Ein endtag wird in kompakter Form geschrieben:
</sup>
. - Ein unary tag (wie
<references />
) wird mit genau einem Leerzeichen zwischen Name (bzw. Attributen) und Schrägstrich geschrieben. - Bei jedem Auftreten der in HTML nur unary möglichen Elemente
br
,hr
undwbr
wird ein unary tag erzwungen; egal ob und wo welcher Schrägstrich steht. - Leere Elemente (das sind
<nowiki></nowiki>
und<references></references>
) werden in ein unary tag umgewandelt.- Das gilt auch, wenn dazwischen nur Whitespace steht, also Leerzeichen oder Zeilenumbruch. – Zwar würde
<pre>
\n</pre>
einen optisch wahrnehmbaren Unterschied ausmachen; als Wikitext ist eine solche Leerzeile jedoch sinnfrei und das ganze Konstrukt wäre zu löschen oder mit Leben zu füllen. Lediglich zur Unterstützung der Programmiersprache Whitespace wird dies nicht auf<syntaxhighlight>
angewendet. - Dies gilt auch nicht für
<div></div>
.
- Das gilt auch, wenn dazwischen nur Whitespace steht, also Leerzeichen oder Zeilenumbruch. – Zwar würde
- Alle Bezeichner von Attributen werden in Kleinschreibung überführt.
- Jedes Attribut darf nur einmal vorkommen; wiederholtes Auftreten führt zu einer Fehlermeldung.
- Attribut-Zuweisungen werden in die kompakte Form
attr="Val"
überführt.- Leerzeichen um das Gleichheitszeichen werden entfernt.
- Der Wert wird in Anführungszeichen
"
eingeschlossen, sofern das noch nicht der Fall war. - Sollte innerhalb des Wertes ein Anführungszeichen
"
identifiziert werden, wird Apostroph'
verwendet bzw. wird beibehalten. - Die Situation, dass in einem Wert sowohl Anführungszeichen wie auch Apostroph vorkommen sollen, kann in einem Wikitext nicht auftreten und es wird ein Syntaxfehler (fehlendes Zeichen) unterstellt und eine Fehlermeldung gezeigt.
- Von Anführungszeichen eingeschlossene
<
und>
werden nicht akzeptiert. - Führende und schließende Leerzeichen um den von Anführungszeichen eingeschlossenen Wert werden entfernt.
- Leere Wertzuweisungen sind unzulässig und führen zu einer Fehlermeldung (gilt nicht für gelegentliche Einzel-Attribute mit Default-Wert ohne Gleichheitszeichen, die jedoch verpönt sind).
- Vor und zwischen Attribut-Zuweisungen steht genau ein Leerzeichen.
- Bei mehrzeiligen tags mit Attributen werden die Zeilenumbrüche in Ruhe gelassen und die Attribute müssen von den Benutzern selbst layoutet werden. Sie sollten jedoch vermieden werden; ich kann sie identifizieren, aber Skripte haben womöglich keine allzu ausgefeilte Syntax.
Insbesondere der gefürchtete Zeilenumbruch <BR>
wird also in jeder Form identifiziert und in <br />
umgewandelt.
Verschachtelung
Einander zugehörige öffnende und schließende Tags werden identifiziert.
Es wird auf korrekte Verschachtelung (‘nesting’) geachtet; in der entsprechenden Hierarchiestufe fehlende endtags führen zu einer Fehlermeldung.
Einige Elemente werden auch sofort vom öffnenden bis schließenden Tag verarbeitet.
Inhaltliche Analyse
nowiki
-Bereiche und einzelne (unary) Elemente werden sofort nach den auskommentierten Abschnitten geschützt.syntaxhighlight
-Bereiche werden gleich danach komplett geschützt.- Sofern möglich (Schlüsselwort „syntaxhighlight“ nicht im Bereich enthalten) wird das veraltete
source
insyntaxhighlight
umgewandelt.
- Sofern möglich (Schlüsselwort „syntaxhighlight“ nicht im Bereich enthalten) wird das veraltete
strike
wird ins
umgewandelt, da die verkürzte Form auch durch manuelle Eingabe weitaus verbreiteter ist und eine einheitliche Notation für gleichbedeutende Syntax angestrebt ist.- Aus Sicherheitsgründen werden HTML-Elemente, die URL-Verweise außerhalb der Wiki-Projekte enthalten (etwa
<a href=
oder<img src=
) in der generierten HTML-Seite blockiert. Im Wikitext werden sie bereits durch Umwandlung des führenden<
in<
deaktiviert, was zur gleichen optischen Darstellung führt. - Werden typografische Tags unary angetroffen, die nur als binary sinnvoll sind (wie <b />, <em />, <i />, <span /> etc.), so wird eine gelegentliche Unsitte angenommen und in
<nowiki />
umgewandelt. Parameter wären wirkungslos und werden dabei entfernt. - Bei Aktivitäten in
<br />
, die mit der CSS-Aktivitätstyle="clear:
… einhergehen oder das nicht standardisierteclear=
… enthalten, ist nur das Block-Element<div />
möglich und dasbr
wird entsprechend umgewandelt. Nicht standardmäßige Formen im<div />
werden in der erkennbaren Absicht entsprechendesstyle="clear:both"
usw. umgesetzt.- Um korrektes HTML sicherzustellen, wird
<div … />
ausnahmsweise als<div …></div>
formatiert.[1]
- Um korrektes HTML sicherzustellen, wird
- Wo Attribut-Zuweisungen zwingend notwendig sind oder wo sie unerlaubt sind, wird dies als Fehler gemeldet.
- Bei den Elementen
gallery ref references syntaxhighlight
sind nur die bekannten Parameter zulässig.[2]
- Bei den Elementen
- CSS-Zuweisungen mittels
style=
werden analysiert und einheitlich formatiert.style="background-color:#ABCDEF"
ist gleichwertig mitstyle="background:#ABCDEF"
und wird verkürzt.- Bei
text-align: vertical-align:
wird die Gültigkeit der Zuweisung überprüft, sonst eine Fehlermeldung ausgegeben.
- Veraltete HTML-Attribute (
bgcolor color valign
) werden instyle=
überführt. - Mehrfache Zuweisungen
class=
oderstyle=
werden kombiniert. - Wo aus dem Element weitere spezifische Verarbeitungsschritte, Whitespace-Formatierungen, Syntaxanalyse oder möglicher Schutz des Inhalts folgen, wird dies veranlasst oder vorgemerkt.
Kommentare
- Zu einem Kommentar-Beginn
<!--
wird das zugehörige Ende-->
gesucht. Ist das Ende nicht zu finden oder wird ein Leerzeichen in einem Kommentar-Beginn angetroffen, erfolgt eine Fehlermeldung. - Ein Kommentar wird einer möglichen benutzerdefinierten Kommentar-Änderung unterzogen.
- Alle Kommentare werden gegen alle weiteren Suchvorgänge und Ersetzungen geschützt.
Anmerkungen
- ↑ Die inneren Tags der Wikisyntax verbleiben nicht im HTML-Dokument und können als unary XML notiert werden.
- ↑
Bei einem unary
<ref />
ist die Angabe vonname=
zwingend erforderlich. Dies wird innerhalb der HTML-Seite bereits als EN-Fehler angezeigt; WSTM sollte dies jedoch bereits in den Fehlermeldungen am Seitenanfang verdeutlichen.