maettig.com

XHTML 2.0 am Horizont

Blick auf XHTML 2.0 (basierend auf dem Entwurf vom 6. Mai 2003) im Kontext von design-freien, endanwender-orientierten Auszeichnungssprachen für Weblogs, Gästebücher etc. Empfehlungen für die möglichst zukunftssichere Handhabung heutiger (HTML 4.01- und XHTML 1.0-) Dokumente. Strategien für einen möglichst leichten Umstieg.

Aus den hier gesammelten Überlegungen entstand unmittelbar der Simple (X)HTML-Prototyp.

Vorüberlegungen

Grundsätzlich gilt, dass Content- oder Dokumenten-Managementsysteme auf normalem, etabliertem (X)HTML aufbauen sollten. Eine Speizialsytnax wie zum Beispiel UBB-Codes fällt von vornherein weg. Des weiteren darf der Redakteur oder Anwender lediglich die logische Struktur bzw. das Layout seines Textes beschreiben. Das Problem dabei ist natürlich, dass der visuell orientierte Mensch intuitiv sein <b>-Tag verwenden möchte. Darauf wird im Folgenden u.a. eingegangen.

Betrachtung der (X)HTML-Tags

Folgende Sprachelemente stehen zur Diskussion.

<a>

Der Einsatz als Link (anchor) ist klar.

Empfehlung: Dem Redakteur sollten auch verkürzte Formen wie <a href=example.com> erlaubt sein. Dies wird auf Skriptebene mit Hilfe regulärer Ausdrücke (Regex, pattern matching) komplettiert (<a href="http://example.com">). Des weiteren sollten URLs/URIs, die nicht innerhalb eines <a> eingeschlossen sind, ebenfalls vollautomatisch formatiert werden (example.com wird zu <a href="http://example.com">example.com</a>). Diese Lösung bleibt auch mit XHTML 2.0 unverändert.

<acronym>/<abbr>

Abkürzungen und Akronyme. Achtung, in XHTML 2.0 gibt es kein <acronym> mehr (das W3C hat den Versuch aufgegeben, zwischen beidem zu unterscheiden). Dies ist im Grunde kein Problem, da <acronym> ohnehin nur skriptgesteuert in den Text eingesetzt werden sollte.

Empfehlung: Jetzt <acronym> verwenden (aufgrund von Browserproblemen mit <abbr>). Später auf <abbr> umstellen (dank der Skriptbasierung gibt es im Idealfall nur eine einzige Stelle, an der das zu ändern ist).

<b>/<strong>

<b> ist mit XHTML 2.0 tot. Es gibt nur noch <strong> für starke Hervorhebungen.

Empfehlung: Dem Redakteur sollte auch das u.a. von UBB gewohnte <b> erlaubt sein, dies aber skriptgesteuert durch <strong> ersetzt werden. Diese Umwandlung kann ungefragt geschehen, da beides die selbe Wirkung hat. Der Redakteur sollte dennoch schon jetzt dazu angehalten sein, nur noch <strong> zu verwenden (im Hilfetext nur dieses darstellen). Diese Lösung bleibt auch mit XHTML 2.0 unverändert.

<blockquote>

Eingerückter Zitatblock. Mit XHTML 2.0 unverändert.

Empfehlung: Dabei bleiben, wenn benötigt. Alternativ <q> verwenden, um den Redakteur mit möglichst wenigen Sprachelementen zu konfrontieren.

<br>/<l>

<br> ist mit XHTML 2.0 wahrscheinlich tot. Lösungen mit <l> sind noch unklar.

Empfehlung: <br> wird vom Redakteur niemals so eingegeben, da er ja echte Zeilenumbrüche hat, die umgewandelt werden können. Doppelte (und mehrfache) Zeilenumbrüche werden durch <p> ersetzt, da die Wirkung in aktuellen Browsern prinzipiell identisch ist. Einfache Zeilenumbrüche werden weiterhin zu <br>. Allgemein sollte jedoch auf eine sehr sparsame Verwendung von <br> geachtet werden, um Umstellungsprobleme zu minimieren. Die spätere Umsetzung in XHTML 2.0 ist noch unklar.

<cite>

Quellenangabe eines Zitates, z.B. der Titel eines Buches oder der Name des Autors, der zitiert wird. Sollte i.d.R. in Kombination mit einem <q> (in XHTML 2.0: <quote>) verwendet werden.

Empfehlung: Verwenden, wenn benötigt (selten). In der Regel braucht der Redakteur das aber nie.

<code>/<kbd>/<samp>/<tt>/<var>

<tt> ist tot und sollte schon heute niemals verwendet werden. <code> steht für Quellcode innerhalb des Fließtextes. Außerdem gibt es <kbd> für Text, den der Anwender eintippen muss (Code muss man auch eintippen, also ist das kaum ein Unterschied). <samp> für Text, den Programme ausspucken. <var> für Variablen und Argumente. Das ist unübersichtlich.

Empfehlung: Einfach alles als <code> ansehen (Ein- und Ausgaben von Programmen werden ohnehin immer als Bildschirmfoto dargestellt, und Variablen sind auch irgendwie Code). Falls der Redakteur <tt> eintippt, dieses ungefragt durch <code> ersetzen. Im Hilfetext nur <code> erwähnen. Diese Lösung bleibt auch mit XHTML 2.0 unverändert.

<del>/<ins>

Gibt es in XHTML 2.0 nicht mehr. Statt dessen gibt es ein Attribut edit="inserted|deleted|changed|moved".

Empfehlung: Nach wie vor <del> etc. verwenden, wenn benötigt (selten). Das läßt sich später höchstwahrscheinlich vollautomatisch umwandeln (mit <span> o.ä.).

<h1>/<h2>/…/<h>

<h1> etc. verschwindet eventuell aus XHTML 2.0 (noch unklar) und wird durch <h> in Verbindung mit <section> ersetzt.

Empfehlung: Erst einmal bei <h1> etc. bleiben.

<hr>

Verschwindet evtl. (noch unklar).

Empfehlung: Schon heute nie verwenden. CSS bietet bessere Möglichkeiten.

<i>/<em>

<i> ist mit XHTML 2.0 tot. Es gibt nur noch <em> für einfache Hervorhebung (in der Regel dann kursiv dargestellt).

Empfehlung: Dem Redakteur <i> erlauben und es einfach in <em> umwandeln (genau wie bei <b> und <strong>). Er sollte dennoch dazu angehalten sein, nur noch <em> zu verwenden (im Hilfetext nur dieses darstellen).

<img>/<object>

<img> entfällt in XHTML 2.0 vollständig und wird durch <object> ersetzt.

Empfehlung: <img> nach wie vor verwenden, da es noch zu viele Browserprobleme mit Bildobjekten gibt. Später ist eine vollautomatische Übersetzung in <object> möglich.

<p>/<section>

Die Verwendung von <p> als Textabsatz (mit sichtbarem Leerraum/Leerzeile) ist klar.

Empfehlung: Mehrfache Leerzeilen bzw. mehrfache <br> zu einem <p> machen. Dies bleibt dann mit XHTML 2.0 unverändert (einzelne Zeilenumbrüche jedoch nicht). Auf das schließende </p> achten!

<pre>/<blockcode>

<pre> soll in XHTML 2.0 durch <blockcode> abgelöst werden. Trotzdem gibt es <pre> auch weiterhin (was nicht völlig nachvollziehbar ist).

Empfehlung: Bei <pre> bleiben, wenn benötigt. Alternativ <code> mit passendem CSS verwenden (verhält sich dann genau wie <pre>), um den Redakteur mit möglichst wenigen Sprachelementen zu konfrontieren.

<q>/<quote>

<q> wird mit XHTML 2.0 in <quote> umbenannt. Beides funktioniert völlig gleich, sofern das zugehörige CSS korrekt verwendet wird. Das CSS wiederum ist für beide völlig gleich. Die Umbenennung ist somit eigentlich grundlos.

Empfehlung: Jetzt <q> verwenden. Anführungszeichen manuell eingeben (korrekt ist "<q>Zitat</q>", die Zeichen gehören also nicht zum Zitat) und die von manchen Browsern eingefügten Auto-Quotezeichen durch CSS unterdrücken (mit q{quotes:'' '' '' '';}). Später einfach jedes <q> in <quote> übersetzen.

<table>/…

Unverändert in XHTML 2.0, aber leider ganz allgemein sehr kritisch im Rahmen eines Redaktions- oder Kommentarsystemes.

Empfehlung: Auf Formulare oder WYSIWYG-Editoren ausweichen (XML, "Authentic" o.ä.), wenn es tatsächlich benötigt wird.

<u>/<s>/<strike>

Empfehlung: Niemals verwenden, da diese Auszeichnungen schon längst tot sind. Statt <s> besser <ins> verwenden (allerdings entfällt das in XHTML 2.0 ebenfalls). Ausnahme: <u> könnte automatisch in <span class="underline"> o.ä. übersetzt werden, wenn so etwas benötigt wird.

Fazit

Der empfohlene, kleinstmögliche Sprachumfang für einen Redakteur, der mit möglichst wenig Syntax konfrontiert werden soll, kann wie folgt aussehen.

  • <a href=…>…</a>
  • <code>…</code>
  • <em>…</em>
  • <h1>…</h1> etc.
  • <img src=…>
  • <q>…</q>
  • <strong>…</strong>
Weiterführende Elemente, die abhängig vom Einsatzzweck unter Umständen benötigt werden, könnten u.a. die folgenden sein.
  • <blockquote>…</blockquote>
  • <del>…</del> etc.
  • <pre>…</pre>
  • <table>…</table>
  • <ul>…</ul> etc.
Für Kommentare im Rahmen eines Weblogs empfiehlt sich ein äußerst minimaler Sprachumfang.
  • <a href=…>…</a>
  • <code>…</code>
  • <em>…</em>
  • <q>…</q>
Dem Redakteur sollten unabhängig von diesen Empfehlungen auch alle anderen ihm bekannten Sprachelemente erlaubt sein. Für Kommentare in Weblogs etc. empfiehlt es sich dagegen, alle nicht ausdrücklich erlaubten Elemente so darzustellen, wie sie eingegeben wurden. Will der Kommentator <a> als Teil des Textes und nicht als Link eingeben, muss er &lt;a> eintippen (trifft auf die ihm erlaubten Elemente zu, nicht jedoch auf alle anderen).

Mögliche, sehr einfache und nicht perfekte Strategie dafür:

  1. Die Eingabe des Besuchers:
    Source for <a href=http://example.com>this</a>
    is &lt;a href=http://example.com>that</a>.
  2. Nach htmlspecialchars():
    Source for &lt;a href=http://example.com&gt;this&lt;/a&gt;
    is &amp;lt;a href=http://example.com&gt;that&lt;/a&gt;.
  3. Regex für die erlaubten Tags anwenden (einfachster Fall):
    $text = preg_replace('{&lt;(a href=.+)&gt;(.+)&lt;/a&gt;}iU',
    '<\1>\2</a>', $text);
  4. Eventuell maskierte (escapete) erlaubte Tags säubern:
    $text = preg_replace('{&amp;(lt;a href=.+&gt;.+&lt;/a&gt;)}iU',
    '&\1', $text);
  5. Ansicht in der endgültigen Ausgabe:
    Source for this
    is <a href=http://example.com>that</a>.
Problem: Es gibt immer einen Sonderfall, den der Anwender aufgrund obiger Ersetzungen nicht in seiner Ausgabe erzeugen kann. Hier wäre das konkret der Text &lt;a href=…>…</a>. (Auf diese Gedanken basierend entstand seinerzeit übrigens der UBB-Code.) Durch Kaskadierung (z.B. &amp;lt;a href=…>…</a>) kann das jedoch ausgeweitet werden. Weiterhin muss eine strikte Regel beim Maskieren (Escapen) eingehalten werden (&lt;a href=…>…&lt;/a> funktioniert beispielsweise nicht und wird fälschlicherweise genau so ausgegeben).

Weiterführende Links: