Semantischer Irrsinn

[Def]

Hallo allerseits!

Ich arbeite gerade an einer technischen Dokumentation in HTML 4.01. Darin kommt auch Quelltext in einer Programmiersprache vor. In SelfHTML finde ich nun den - vernünftigen - Vorschlag, diesen Quelltext so auszuzeichnen:

<pre><code>
<!-- Quelltext -->
</code></pre>

Einen Augenblick jedoch packte mich der semantische Irrsinn. 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?)
Und im Geiste habe ich schon durchgespielt, wie es jetzt weitergeht: Alle <pre>-Elemente rausschmeißen und mittels CSS die <code>-Elemente entsprechend formatieren.
Aber mal abgesehen davon, dass ich so spontan gar nicht wüsste, wie man mit CSS eine <pre>-Formatierung erreichen könnte (ich wüsste nur, wie ich die Formatierung des <pre>-Elements hinkriegen könnte), fiel mir zum Glück rechtzeitig ein, dass es nur ein Anflug semantischen Irrsinns war. Wozu sich mehr Arbeit machen als nötig? Wenn schon im relativ puristischen SelfHTML die o.g. Auszeichnung ausdrücklich angegeben wird, kann das so schlimm nicht sein.
Was denkt Ihr darüber? Wäre es trotzdem besser, die <pre>-Formatierung mit CSS vorzunehmen? Wenn ja, wie? Geht mit XHMTL die Entwicklung in die von mir skizzierte strengere, puristische Richtung? 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?

Ich danke für Eure Erfahrungen, Ideen und Gedanken.

Schöne Grüße
Def

[Xarden]

Hi Def,

Wenn ic mich nich irre dann darf das <code>-Element gar nicht aleine vorkommen. Ich wüsste keinen Grund der gegen die Vorgestellte Lösung sprechen sollte.
Auch wenn <pre> wie von die gesagt keine Logische Auszeichnung enthält ist das nicht Schlimm das macht ja <code>. Auch von der Kompatibilität her zu sehen ist <pre> besser da wenige Browser den CSS-Ersatzt("white-space") unterstützt.
Noch ne Frage: Warum erstellst du eigentliche eine HTML-Dokumentation. Meines Wissen ist SelfHTML (fast) perfekt.

Mfg Xarden

[Wilhelm Turtschan]

habe d'ehre Xarden

Noch ne Frage: Warum erstellst du eigentliche eine HTML-Dokumentation. Meines Wissen ist SelfHTML (fast) perfekt.

Wo liest Du das raus?
Ich arbeite gerade an einer technischen Dokumentation in HTML 4.01

Vielleicht beschreibt er die Stückliste eines Rasierapparates für Ersatzteilbeschaffung via HTML.

man liest sich
Wilhelm

[Xarden]

Hi Willhelm,

Noch ne Frage: Warum erstellst du eigentliche eine HTML-Dokumentation. Meines Wissen ist SelfHTML (fast) perfekt.

Wo liest Du das raus?
Ich arbeite gerade an einer technischen Dokumentation in HTML 4.01

Peinlich, Peinlich. Hab ich woll en bissl zu schnell gelesen.

Mfg Xarden

[Wilhelm Turtschan]

habe d'ehre Xarden

Noch ne Frage: Warum erstellst du eigentliche eine HTML-Dokumentation. Meines Wissen ist SelfHTML (fast) perfekt.
Wo liest Du das raus?
Ich arbeite gerade an einer technischen Dokumentation in HTML 4.01
Peinlich, Peinlich. Hab ich woll en bissl zu schnell gelesen.

da heute der letzte vorm letzten dieser Woche ist zeigen wir uns großzügig.
sieben Rutenhiebe auf nur die linke A-Backe. Die acht restlichen auf die andere seien dir erlassen. Zukünftig immer am ersten missverstehen, kommt einfacher und humaner. :-)

man liest sich
Wilhelm

[Xarden]

Moinsen Willhelm,

da heute der letzte vorm letzten dieser Woche ist zeigen wir uns großzügig.
sieben Rutenhiebe auf nur die linke A-Backe. Die acht restlichen auf die andere seien dir erlassen. Zukünftig immer am ersten missverstehen, kommt einfacher und humaner. :-)

ihr seid ja so gnädig ...

Mfg Xarden

[Der Martin]

Hallo,

Noch ne Frage: Warum erstellst du eigentliche eine HTML-Dokumentation. Meines Wissen ist SelfHTML (fast) perfekt.

ich glaube, da hast du etwas missverstanden. Er wollte keine Dokumentation ÜBER HTML, sondern eine IN HTML geschriebene Dokumentation über irgendwas ganz anderes erstellen.

Ciao,
 Martin

[Def]

Hi Xarden,

Wenn ic mich nich irre dann darf das <code>-Element gar nicht aleine vorkommen.

hab gerade nachgesehen:

Darf innerhalb der folgenden HTML-Elemente vorkommen:
[Block-Elemente] | [Inline-Elemente] | body
(body nur bei Seite HTML Transitional)

Ich wüsste keinen Grund der gegen die Vorgestellte Lösung sprechen sollte.

Der einzige, der mir einfiele, wäre eine nicht perfekte Trennung von Inhalt und Darstellung.

Auch wenn <pre> wie von die gesagt keine Logische Auszeichnung enthält ist das nicht Schlimm das macht ja <code>. Auch von der Kompatibilität her zu sehen ist <pre> besser da wenige Browser den CSS-Ersatzt("white-space") unterstützt.

Stimmt, habe gerade nachgesehen. Erst ab IE6 bzw. NN6 geht's bei den beiden "großen" Browsern los.
Man könnte höchstens <pre> *und* "white-space" gleichzeitig einsetzen, aber das brächte überhaupt keinen Vorteil, nur Nachteile bei der Wartung der Dokumente. ;-)

Schöne Grüße
Def

[Daniel unreg]

Hallo,

Einen Augenblick jedoch packte mich der semantische Irrsinn. 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 ist schon ganz richtig so. Nun gibts aber z.B. Textbrowser, die Eigenschaften wie white-space (womit man Elemente pre-ähnlich formatieren kann) oder allgemein CSS nicht kennen. Von daher denke ich, dass es sogar notwendig ist, ein pre-Element zu besitzen.

Andererseits habe ich selbst <pre> noch nie verwendet, und kann daher nicht beweisen, dass es tatsächlich ein so wichtiges Element ist.

Gruß;

[Def]

Hallo Daniel,

Nein, das ist schon ganz richtig so. Nun gibts aber z.B. Textbrowser, die Eigenschaften wie white-space (womit man Elemente pre-ähnlich formatieren kann) oder allgemein CSS nicht kennen. Von daher denke ich, dass es sogar notwendig ist, ein pre-Element zu besitzen.

Andererseits habe ich selbst <pre> noch nie verwendet, und kann daher nicht beweisen, dass es tatsächlich ein so wichtiges Element ist.

<pre> bewirkt zum einen, dass eine Schriftart benutzt wird, bei der alle Zeichen gleich breit sind (ich glaube, das heißt "dicktengleich"). Ich habe aber gerade experimentiert und festgestellt, dass zumindest Mozilla schlau genug ist, dies auch dann zu tun, wenn nur <code> alleine auftaucht. (Was bei Quellcode i.A. ja auch sinnvoll ist.)
Zum anderen werden, wie Du mit white-space  ja schon angedeutet hattest, die Zeilenumbrüche so übernommen, wie sie in der Datei stehen. Man muss also nicht ständig <br> einbauen.
Von einer anderen lästigen Pflicht entbindet <pre> natürlich nicht, nämlich spitze Klammern durch &lt; bzw. &gt; und Anführungszeichen durch &quot; zu ersetzen.

Schöne Grüße
Def

[Xarden]

Hi Def,

Von einer anderen lästigen Pflicht entbindet <pre> natürlich nicht, nämlich spitze Klammern durch &lt; bzw. &gt; und Anführungszeichen durch &quot; zu ersetzen.

Davon entbindet ein CDATA-Bereich, also:
<pre><code><![CDATA[
    <element atrribut="wert">
        Inhalt
    </element>
]]></code></pre>

Mfg Xarden

[Def]

Hallo Xarden,

Von einer anderen lästigen Pflicht entbindet <pre> natürlich nicht, nämlich spitze Klammern durch &lt; bzw. &gt; und Anführungszeichen durch &quot; zu ersetzen.

Davon entbindet ein CDATA-Bereich, also:
<pre><code><![CDATA[
    <element atrribut="wert">
        Inhalt
    </element>
]]></code></pre>

danke für den Hinweis, das wusste ich tatsächlich nicht. Wenn ich SelfHTML an dieser Stelle richtig verstehe, dann geht das nur mit XML bzw. XHTML, aber nicht mit HTML, ist das richtig? Kommen aktuelle Browser damit problemlos klar?
Und heißt das, ich kann beliebige Zeichen außer der speziellen Endsequenz ]]> einbauen, ohne sonst irgendwas zu beachten?

Schöne Grüße
Def

[Xarden]

Hi Def,

danke für den Hinweis, das wusste ich tatsächlich nicht. Wenn ich SelfHTML an dieser Stelle richtig verstehe, dann geht das nur mit XML bzw. XHTML, aber nicht mit HTML, ist das richtig? Kommen aktuelle Browser damit problemlos klar?
Und heißt das, ich kann beliebige Zeichen außer der speziellen Endsequenz ]]> einbauen, ohne sonst irgendwas zu beachten?

Ja es geht offiziel nur in XML/XHTML manche Browser verstehen das aber auch in HTML. Ja du kannst beliebige Zeichen vor ]]> einbauen. Auch Kommentare werden hier angezeigt.

Mfg Xarden

[Def]

Hi Xarden,

Ja es geht offiziel nur in XML/XHTML manche Browser verstehen das aber auch in HTML. Ja du kannst beliebige Zeichen vor ]]> einbauen. Auch Kommentare werden hier angezeigt.

das wäre ja dann vielleicht mal ein echter Grund für mich, auf XHTML umzusteigen. ;-)
1000 Dank für Deinen Hinweis.

Schöne Grüße
Def

[D.R.]

Hallo,

Ja es geht offiziel nur in XML/XHTML manche Browser verstehen das aber auch in HTML. Ja du kannst beliebige Zeichen vor ]]> einbauen. Auch Kommentare werden hier angezeigt.

das wäre ja dann vielleicht mal ein echter Grund für mich, auf XHTML umzusteigen. ;-)

Naja, solange man den <ironie>allseits geliebten</ironie> IE noch mit text/html beliefern muss, kann man die ganzen Vorteile von XHTML leider nicht nutzen :-(

Bleibt also vorerst leider nur die Konvertierung von < und & in &lt; sowie &amp;.

mfg. Daniel

[Xarden]

Hi D.R.

Ja es geht offiziel nur in XML/XHTML manche Browser verstehen das aber auch in HTML. Ja du kannst beliebige Zeichen vor ]]> einbauen. Auch Kommentare werden hier angezeigt.

das wäre ja dann vielleicht mal ein echter Grund für mich, auf XHTML umzusteigen. ;-)

Naja, solange man den <ironie>allseits geliebten</ironie> IE noch mit text/html beliefern muss, kann man die ganzen Vorteile von XHTML leider nicht nutzen :-(

Bleibt also vorerst leider nur die Konvertierung von < und & in &lt; sowie &amp;.

Tu die auf keinen Fall, denn:
auch der IE liest XHTML wenn es mit dem MIME-Typ text/html übergeben wurde. um nun alle Browser ihrer Leistung zu beliefern benötigst du lediglich PHP oder Perl. Hier sie ein Workaround mit PHP beschrieben:

<?php  
    header("Content-Type: " + (in_array($_SEVER['HTTP_ACCEPT'], "application/xhtml+xml") ? "application/xhtml+xml" : "text/html"));  
    }  
?>

Mfg Xarden

[D.R.]

Hallo,

Bleibt also vorerst leider nur die Konvertierung von < und & in &lt; sowie &amp;.

Tu die auf keinen Fall, denn:
auch der IE liest XHTML wenn es mit dem MIME-Typ text/html übergeben wurde.

Was meinst du mir „liest XHTML“? Wenn man eine Ressource als text/html ausliefert, wird sie nach den Regeln von HTML verarbeitet (und gibt's weder <Element /> noch CDATA).

Das klappt natürlich nur dann ohne Probleme, wenn man die Regeln zur HTML-Kompatiblität beachtet und auch solche Sachen wie <![CDATA[…]]> möglichst verzichtet, und lediglich in <script>-Bereichen verwendet (wo man es jedoch auskommentieren sollte).

mfg. Daniel

[Xarden]

Hi Forum,

Was meinst du mir „liest XHTML“? Wenn man eine Ressource als text/html ausliefert, wird sie nach den Regeln von HTML verarbeitet (und gibt's weder <Element /> noch CDATA).

Ich meine damit parsen. Und das macht der IE auch bei HTML. Alle anderen (die standartkonformen) Browser bekomment ja XHTML und parsen auch korrekt

Mfg Xarden

[D.R.]

Hallo,

Ich meine damit parsen. Und das macht der IE auch bei HTML.

Ja, aber er kommt nicht mit den speziellen XHTML-Schreibweisen klar, weil er schlichtweg kein XHTML verarbeiten kann.

Alle anderen (die standartkonformen) Browser bekomment ja XHTML und parsen auch korrekt

Aber wenn die Ressource sowieso nicht korrekt als text/html parsbar ;-) ist, braucht man sie ja erst gar nicht als solches ausliefern.

Das mit der Content-Neogation kenne ich natürlich und wende es auch an. Aber wie gesagt: Dann muss man auch die Kompatiblitäts-Regeln beachten und hat somit (bis auch die bessere Lesbarkeit des Codes) leider keine Vorteile gegenüber HTML. Hoffentlich hält µ$oft sein Versprechen, application/xhtml+xml in den IE8 zu integrieren.

mfg. Daniel

[Xarden]

Hi Forum.

Ich meine damit parsen. Und das macht der IE auch bei HTML.

Ja, aber er kommt nicht mit den speziellen XHTML-Schreibweisen klar, weil er schlichtweg kein XHTML verarbeiten kann.

Meines Wissen kommt der IE mit XHTML klar. Er versteht z.B. "/>" und meines wissen auch "CDATA".

Alle anderen (die standartkonformen) Browser bekomment ja XHTML und parsen auch korrekt

Aber wenn die Ressource sowieso nicht korrekt als text/html parsbar ;-) ist, braucht man sie ja erst gar nicht als solches ausliefern.

Wenn der IE was korrekt parst dann fresse ich einen Bessen (sieht man schon daran das etwas wie * html funktioniert).

Mfg Xarden

[D.R.]

Hallo,

Meines Wissen kommt der IE mit XHTML klar. Er versteht z.B. "/>" und meines wissen auch "CDATA".

Meinst du?

Zum Vergleich noch mal als application/xhtml+xml (funzt natürlich nur in fähigen Browsern).

mfg. Daniel

[Def]

Hallo Xarden,

Tu die auf keinen Fall, denn:
auch der IE liest XHTML wenn es mit dem MIME-Typ text/html übergeben wurde.

also, die Dateien, die ich erstelle, sollen auch dann funktionieren, wenn jemand sie auf seiner Festplatte abspeichert, doppelklickt und in seinem Browser betrachtet. Meines Wissens gibt es da keine Möglichkeit, einen MIME-Typ anzugeben.

Schöne Grüße
Def

[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

[Def]

Hallo Tim,

über Syntax-Highlighting habe ich schon nachgedacht, bin aber noch in einem noch recht frühen Erstellungsstadium und hatte noch keine konkreten Ideen, wie dies zu realisieren wäre. Danke für Deine Anregungen, ebenso wie die für verlinkbare Codezeilen, das ist eine nette Idee. Da hätte ich mir sonst wohl die Zähne dran ausgebissen, und ein schlechtes Gewissen gehabt, wenn ich für jede Zeile ein eigenes Element eingebaut hätte. Damit hast Du mich vor vielen schlaflosen Nächten bewahrt.

Und plötzlich landet man bei Extrembeispielen wie da oben, die man nicht schreiben, sondern per Programm erzeugen lassen will.

Auch eine gute Idee. Mal sehen, wie komplex meine Codebeispiele werden, und welche Funktionalität wirklich nötig ist. Ich würde schon gerne auf softwaregenerierten Code verzichten. Menschenlesbarer und -editierbarer HTML-Code hat ja immer noch was für sich. So könnte auch jemand anders problemlos meine Dokumentation weiterführen, ohne viel Erklärung und Vorbereitung.

white-space:pre

In CSS 2.1 gibt es auch den Wert pre-wrap, experimentell wird der von Browsern schon länger implementiert.

Danke für den Hinweis.

[Erklärungen zu XHTML 2 und (X)HTML 5] Bitte keine Fragen warum, und wieso die komische Namensbenennung [...]

Keine Sorge, ich frage nicht, wenn ich schon vorgewarnt werde. ;-)

In XHTML 2 gibt es das Element <blockcode>, dass sich zu <code> so verhält wie derzeit <blockquote> zu <q>:

Also macht <blockcode> dasselbe wie <pre><code> ... </code></pre>?

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 [...]

Je mehr man dem Benutzer bieten will (Syntax-Highlighting, anklickbare Quellcodezeilen, Anmerkungen zu einzelnen Passagen, etc.), desto schwerer lesbar wird leider auch der Quellcode. Dagegen kann man halt nichts machen.

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.

Ich glaube, über diese Richtlinien lohnt es sich nachzudenken.

Vielen Dank und schöne Grüße
Def

[Def]

Hallo an alle,

ich habe aufgrund der erhaltenen Antworten nochmal über meine Frage nachgedacht und festgestellt, dass das Element <pre> eigentlich gar nicht viel macht.
Wenn man einfach mal unterstellt, dass die Browser schlau genug sind, <code> in dicktengleicher Schrift darzustellen (Mozilla 1.7.8 unter Linux tut dies jedenfalls), und man mit CSS dies auch nochmal sicherheitshalber zusätzlich festschreibt, dann bringt <pre> eigentlich nur bei den Zeilenumbrüchen etwas Erleichterung. Wenn man nun, da "white-space" ja noch nicht so toll unterstützt wird, die Zeilenumbrüche wie üblich mit <br> festlegt, hat man wieder eine recht sauber Trennung von Inhalt und Darstellung.
Und das "white-space"-Element zeigt mir wieder mal, dass es eine 100%ige Trennung sowieso nicht geben kann: (Fehlende) Zeilenumbrüche sind zunächst einmal eine Sache des Aussehens, aber natürlich können Sie auch den Sinn beeinflussen (zumindest bei Quelltext).

Schöne Grüße und nochmal danke für Eure Antworten
Def

[Gernot Back]

Hallo Def,

Wenn man nun, da "white-space" ja noch nicht so toll unterstützt wird, die Zeilenumbrüche wie üblich mit <br> festlegt, hat man wieder eine recht sauber Trennung von Inhalt und Darstellung.

Damit verunzierst du dir aber den Code, was hat HTML-Code innerhalb eines auf einer HTML-Seite präsentierten Script- oder Programmiersprachen-Codes verloren?

Wenn ich mir den im Browser markiere und in meinen Script- oder Programmier-Code einfüge, muss ich bei manchen Editoren schon höllisch aufpassen, dass er nicht auch diese <br>s mitnimmt.

Ich bin im Prinzip ganz deiner Meinung PRE ist kein Element der logischen Auszeichnung, - Die gemeinhin als solche angesehenen STRONG- und EM-Elemente allerdings auch nicht. Deshalb sollten sie in (X)HTML als "künftig wegfallend" (deprecated) betrachtet werden. Gestaltung ist die Domäne von CSS.

Aber die Diskussion hatten wir ja schon.

http://forum.de.selfhtml.org/archiv/2005/8/t113955/#m725058

Gruß Gernot

[Def]

Hallo Gernot,

Du schriebst bezüglich der <br>-Elemente in Quellcodes:

Damit verunzierst du dir aber den Code, was hat HTML-Code innerhalb eines auf einer HTML-Seite präsentierten Script- oder Programmiersprachen-Codes verloren?

Ich verstehe schon, dass das irgendwie "unschön" ist, aber so habe ich die Grundidee von HTML verstanden. Angenommen, ich hätte ein Gedicht, das ich auf einer HTML-Seite präsentieren wollte. Da fragt ja auch keiner, was da diese hässlichen <br>-Elemente mitten im Gedicht sollen.
Oder wenn ich ein paar Textabsätze habe: diese hässlichen <p>- und </p>-Tags stören beim Anblick des Quellcodes. Da würde ja auch keiner ernsthaft darauf kommen, alles mit <pre> zu umklammern und dann die Absätze durch zweimal "Enter"-Drücken zu schaffen.
Ich brauche Zeilenumbrüche in einem bestimmten Textabschnitt, also bekomme ich sie mit <br> - "white-space" wird ja leider von den Browsern noch nicht richtig unterstützt.

Wenn ich mir den im Browser markiere und in meinen Script- oder Programmier-Code einfüge, muss ich bei manchen Editoren schon höllisch aufpassen, dass er nicht auch diese <br>s mitnimmt.

Wieso kopierst Du sie aus dem HTML-Code und nicht aus der Seite, die der Browser anzeigt?

Ich bin im Prinzip ganz deiner Meinung PRE ist kein Element der logischen Auszeichnung, - Die gemeinhin als solche angesehenen STRONG- und EM-Elemente allerdings auch nicht. Deshalb sollten sie in (X)HTML als "künftig wegfallend" (deprecated) betrachtet werden. Gestaltung ist die Domäne von CSS.

Aber die Diskussion hatten wir ja schon.

http://forum.de.selfhtml.org/archiv/2005/8/t113955/#m725058

Gruß Gernot

Ich habe die von Dir verlinkte Diskussion nicht gelesen, aber aus meinen eigenen Überlegungen kann ich sagen, dass die Trennung von Inhalt und Aussehen, die gefühlsmäßig schnell einleuchtet, ebenso schnell zu verschwimmen beginnt, sobald man über Zweifelsfälle aus der Praxis nachdenkt.

Schöne Grüße
Def

[Jenny]

Diese Frage und all die millionen Fragen hier in dieser Art werden
vollkommen belanglos, wenn man begreift, daß die angeblichen
Nachteile von "Flash" sich bei NÄHERER Betrachtung gegen Null
bewegen.