Benutzer:PerfektesChaos/js/WikiSyntaxTextMod/flow/tag

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

WikiSyntaxTextModSyntaxpolitur → Schritt 2

Tags

In einem zweiten Schritt der Syntaxpolitur erfolgt die Standardisierung der tags, also der <tag>.

Geltungsbereich[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

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 und wbr 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>.
  • 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[Bearbeiten | Quelltext bearbeiten]

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[Bearbeiten | Quelltext bearbeiten]

  • 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 in syntaxhighlight umgewandelt.
  • strike wird in s 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 &lt; 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ät style="clear:… einhergehen oder das nicht standardisierte clear=… enthalten, ist nur das Block-Element <div /> möglich und das br wird entsprechend umgewandelt. Nicht standardmäßige Formen im <div /> werden in der erkennbaren Absicht entsprechendes style="clear:both" usw. umgesetzt.
    • Um korrektes HTML sicherzustellen, wird <div … /> ausnahmsweise als <div …></div> formatiert.[1]
  • 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]
  • CSS-Zuweisungen mittels style= werden analysiert und einheitlich formatiert.
    • style="background-color:#ABCDEF" ist gleichwertig mit style="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 in style= überführt.
  • Mehrfache Zuweisungen class= oder style= 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[Bearbeiten | Quelltext bearbeiten]

  • 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[Bearbeiten | Quelltext bearbeiten]

  1. Die inneren Tags der Wikisyntax verbleiben nicht im HTML-Dokument und können als unary XML notiert werden.
  2. Bei einem unary <ref /> ist die Angabe von name= zwingend erforderlich. Dies wird innerhalb der HTML-Seite bereits als EN-Fehler angezeigt; WSTM sollte dies jedoch bereits in den Fehlermeldungen am Seitenanfang verdeutlichen.