Semantischer Irrsinn

[Tim Tepaße]

Hallo Def,

Einen Augenblick jedoch packte mich der semantische Irrsinn.

Hehe. Ich war schon mal bei etwas ähnlichem diese hier ...

~~~html <table id="foo" class="quellcode">
  <caption>foo.txt</caption>
  <tr id="foo-line-1">
    <th scope="row">1</th>
    <td class="code"><code class="line">Quelltext <code class="keyword">Zeile</code> <code class="integer">1</code></code></td>
    <td class="notes">Notizen...</td>
  </tr>
  <tr id="foo-line-2">
    <th scope="row">2</th>
    <td class="code"><code class="line">Quelltext <code class="keyword">Zeile</code> <code class="integer">2</code></td>
  </tr>
  ...
  </table>

  
... und hatte auch tolle Styles dafür. Als Rechtfertigung: Je mehr man auszeichnen, verlinken und stylen will, desto mehr Elemente braucht man nunmal. Das hat eben auch praktische Gründe.  
  
• Wenn man in einem Quelltext-Listing einzelne Zeilen verlinkbar machen möchte, braucht man nunmal ein Element für eine einzelne Zeile. Eine sortierte Liste liegt also nahe.  
• Wenn man Syntax-Highlighting will, braucht man verschachtelte code-Elemente.  
• (Nicht ganz so relevant) Wenn man verschiedene Happen einer Datei mit verschiedenen Zeilennummern in einem Listing unterbringen will, muss man mit dem start-Attribut arbeiten. Fanatiker haben dabei ein schlechtes Gewissen, weil das W3C das start-Attribut nicht mag und Listennummerierung gefälligst mit CSS zu erfolgen hat.  
• Wenn man für Zeilen Metadaten wie Notizen unterbringen will, landet man schlussendlich bei einer Tabelle und kann das sogar noch mit Phantasie semantisch begründen. („Ein Dateilisting mit Annotationen ist eine Zuordnung von Zeilennummern zu Zeileninhalt und Annotationen“).  
  
Und plötzlich landet man bei Extrembeispielen wie da oben, die man nicht schreiben, sondern per Programm erzeugen lassen will.  
  
  

> Ich dachte mir nämlich: <pre> ist ja eigentlich keine semantische Auszeichnung, sondern legt nur die Darstellung fest: "Schreib das Folgende so hin, wie es in der Datei steht!" (Oder irre ich mich hier?)  
  
Nein, das stimmt schon so.  
  
  

> Aber mal abgesehen davon, dass ich so spontan gar nicht wüsste, wie man mit CSS eine <pre>-Formatierung erreichen könnte ...  
  
  [white-space](http://de.selfhtml.org/css/eigenschaften/ausrichtung.htm#white_space):pre  
  
In CSS 2.1 gibt es auch den Wert pre-wrap, experimentell wird der von Browsern schon länger [implementiert](http://myy.helia.fi/~karte/pre-wrap-css3-mozilla-opera-ie.html).  
  

> Geht mit XHMTL die Entwicklung in die von mir skizzierte strengere, puristische Richtung?  
  
Das kommt drauf an, welches XHTML Du meinst. Weiterentwicklung des HTML-Sprachschatzes findet derzeit in zwei unterschiedliche Richtungen statt, einmal in dem abwärtskompatiblen XHTML 2, zu anderen in dem abwärtskompatiblen „(X)HTML 5“. Bitte keine Fragen warum, und wieso die komische Namensbenennung, das führt a) zu weit, ist b) noch nicht entschieden und c) für das derzeitige Web noch nicht relevant.  
  
In XHTML 2 gibt es das Element <blockcode>, dass sich zu <code> so verhält wie derzeit <blockquote> zu <q>:  
  
  ~~~xml
<blockcode>Quelltext ...  
  Quelltext ...  
  </blockcode>[/code>]  
  
Man kann es auch mit den neuen Element <l> (kleines L wie in Line für Zeile) kombinieren:  
  
  [code lang=xml]<blockcode>  
  <l>Quelltext ...</l>  
  <l>Quelltext ...</l>  
  </blockcode>[/code>]  
  
(Siehe obiges Problem des Adressierens.)  
  
(X)HTML 5 (alias Web Applications 1) hat nichts ähnliches, sieht sein Ziel aber auch nicht darin, ein Vokabular für Computer- und Wissensschaftsthemen behandelnde Dokumente anzubieten, sondern geht langsam von dem Dokument-Paradigma weg. Dazu kommt, dass (X)HTML 5 in extremen, von Tag zu Tag stattfindenden Umschwung stattfindet, man kann also keine wirklich endgültigen Aussagen treffen. Der Begriff Brainstorming beschreibt es im derzeitigen Zustand eher.  
  
  

> Oder stimmt ihr zu, dass die in SelfHTML angegebene Auszeichnung völlig angemessen ist? Geht es Euch manchmal auch so, dass Ihr Euch in semantischen Grundsatzüberlegungen verliert und womöglich sogar völlig übertriebenen und unnötigen Aufwand treibt, um eine saubere Trennung von Inhalt und Darstellung zu erhalten? Macht Ihr was dagegen, und wenn ja, was? Wo ist für Euch die Grenze des Purismus, wo beginnt die Praktikabilität bei Euch?  
  
Man betreibt Semantik ja nicht als blossen Scherz, sondern immer aus einem Zweck: Struktur, die der Mensch intuitiv begreift, auch für Programme begreifbar und nutzbar zu machen, so das eine Anfrage wie „Gib mir alle Zitate auf dieser Seite“ in Code wie [code lang=javascript]document.getElementByTagName("q")
~~~ umsetzbar ist. Es gibt kein universelle Semantik für alles und jeden Kleinkram, HTML hat ein begrenztes Vokabular. Irgend wo muss man also Schluss machen. Nur wo?  
  
Ich bin da pragmatisch und entscheide da teilweise nach Bauchgefühl, teilweise danach, wie leicht oder schwer es die entstehende Struktur Programmen macht. Dabei ist eine nette Richtlinie, wie leicht oder wie schwer die Struktur es Programmen (Wie z.B. eigenen Javascript-Anwendungen) macht, das zu verarbeiten. Obiges Extrembeispiel ist zwar toll zu stylen, aber extrem hässlich in JS zu verarbeiten, wenn man nur das DOM zur Verfügung hat. Da landet man dann automatisch auf einem Mittelweg.  
  
Idealweise hat man für jedes zusätzliche Element, das man im Baum einfügt eine Begründung.  
  
  
Tim