semantisch gutes xhtml

[sebastian1992]

Hallo,

laut W3 soll man ja semantisch guten Code produzieren.

Jedoch schreibe ich jetzt ein HTML Kurs und bin an dem Punkt, das ich meine Beispiele mit entsprechenden Tags hervorheben möchte. Wie ich dies style ist ja nicht das Problem, aber für zum Beispiel ein Beispiel, wie es später aussehen wird, gibt es zum Beispiel nur samp, was aber inline ist und code macht auch Probleme, wenn man darin ein p Element hat. Wie soll man also semantisch richtigen Code produzieren, wenn wichtige Elemente nicht als block existieren.

Gibt es alternativen zu genannten Tags. Bisher habe ich nur http://www.webdesign-referenz.de/html_xhtml.shtml#4.4.2 gefunden, wo es keine alternativen gab.

Gruß Sebastian

[Snafu]

Hallo!
Ich muss ehrlich sagen, es war schwer dein Problem herauszusuchen.
Wenn du das samp-Element als Blockelement haben willst, dann setzt doch einfach mittels CSS display:block;. Wo liegt das Problem?

[sebastian1992]

Hallo!
Ich muss ehrlich sagen, es war schwer dein Problem herauszusuchen.
Wenn du das samp-Element als Blockelement haben willst, dann setzt doch einfach mittels CSS display:block;. Wo liegt das Problem?

Das Problem liegt darin, dass dies trotzdem Anzeiige Probleme gibt, Beispiel:

<samp style="display:block;"><p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit,  
sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat  
volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper  
suscipit lobortis nisl ut aliquip ex ea commodo consequat.</p>  
  
<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy  
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi  
enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis  
nisl ut aliquip ex ea commodo consequat.</p></samp>

Dies gibt einen Anzeigefehler, die p rutschen aus dem samp heraus.

[Thorsten Schleppi]

Hallo,

was spricht gegen diese Variante:

<p><samp>Lorem ipsum dolor sit amet, consectetuer adipiscing elit,  
sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat  
volutpat. Ut wisi enim ad minim veniam, quis nostrud exerci tation ullamcorper  
suscipit lobortis nisl ut aliquip ex ea commodo consequat.</samp></p>  
  
<p><samp>Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy  
nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat. Ut wisi  
enim ad minim veniam, quis nostrud exerci tation ullamcorper suscipit lobortis  
nisl ut aliquip ex ea commodo consequat.</samp></p>

Viele Grüße
Thorsten

[sebastian1992]

was spricht gegen diese Variante:

Wenn du zum Beispiel eine Codebox gestalltest, hättest ud so merhre Boxen für einen Code.

Dann werde ich wohl doch mit div und klassen arbeiten.

Gruß Sebastian

[Thorsten Schleppi]

Hallo,

Wenn du zum Beispiel eine Codebox gestalltest, hättest ud so merhre Boxen für einen Code.

Dann werde ich wohl doch mit div und klassen arbeiten.

Eine Box kannst du ja immernoch per div zusätzlich außenrum basteln.
Du würdest den Code jedoch immernoch logisch korrekt und in validem xhtml strict auszeichnen.

Viele Grüße
Thorsten

[EKKi]

Mahlzeit Thorsten Schleppi,

Eine Box kannst du ja immernoch per div zusätzlich außenrum basteln.

Das hat dann aber mit semantisch sauberen (X)HTML nichts mehr zu tun.

MfG,
EKKi

[Thorsten Schleppi]

Hallo!

Das hat dann aber mit semantisch sauberen (X)HTML nichts mehr zu tun.

Warum? Ein div teilt Elemente in einen <http://de.selfhtml.org/html/text/bereiche.htm#block@title=allgemeinen Block> ein.

Der Quellcode mag aufgebläht sein, aber imho ist er aus rein semantischer Sicht völlig in Ordnung. Er definiert einen Block, in welchem Textabsätze vorkommen, deren Inhalt Beispiele sind.
Und aus Validator-Sicht ist dieser Quellcode auch sauber.

Ich lass mich aber auch gerne von dir belehren, wenn ich irgendwas übersehen habe.

Viele Grüße
Thorsten

[suit]

Der Quellcode mag aufgebläht sein, aber imho ist er aus rein semantischer Sicht völlig in Ordnung. Er definiert einen Block, in welchem Textabsätze vorkommen, deren Inhalt Beispiele sind.

zusammengehörende textabsätze deren inhalte beispiele sind - das ist etwas anderes, als ein beispiel dessen inhalt textabsätze sind

zucker mit dem geschmack von erdbeeren ist auch nicht das selbe wie erdbeeren, die mit zucker gesüßt wurden ;)

[Thorsten Schleppi]

Hallo,

zusammengehörende textabsätze deren inhalte beispiele sind - das ist etwas anderes, als ein beispiel dessen inhalt textabsätze sind

zucker mit dem geschmack von erdbeeren ist auch nicht das selbe wie erdbeeren, die mit zucker gesüßt wurden ;)

Das sehe ich ja auch so. Das was sebastian1992 vor hatte erlauben die Regeln von XHTML nicht. Mein Vorschlag war eine Alternative hierzu.

Wir sind uns einig, dass es sowohl gezuckerte Erdbeeren als auch Zucker mit Erdbeergeschmack gibt, oder?
Das heißt doch beides an sich macht Sinn, so imho auch die von mir genannte Alternative.

Ich möchte da jetzt aber auch keine Endlosdiskussion anfangen. Ich hätte nur gerne eine Begründung, warum das nicht semantisch korrekt sein soll.

Wenn ich einen Textabschnitte habe, dessen kompletter Inhalt von der logischen Auszeichnung her stark betont sein soll ist es schließlich auch korrekt das ganze so zu schreiben:

<p><strong>Text</strong></p>

Das gleiche gilt doch dafür, wenn der Inhalt ein Beispiel ist, oder nicht?

Viele Grüße
Thorsten

[suit]

Das gleiche gilt doch dafür, wenn der Inhalt ein Beispiel ist, oder nicht?

ja schon, aber im dem fall wäre das "ich bin ein beispiel" das gruppierende element und dieses müsste dann durch ein ungünstigeres div-element getauscht werden

[Thorsten Schleppi]

Hallo!

Das gleiche gilt doch dafür, wenn der Inhalt ein Beispiel ist, oder nicht?

ja schon, aber im dem fall wäre das "ich bin ein beispiel" das gruppierende element und dieses müsste dann durch ein ungünstigeres div-element getauscht werden

Ja, genau. Aber sollte wie gesagt ja auch nur eine valide Alternative sein.
Es ist sicher sinnvoll die Textabsätze mit einem div zu gruppieren. Wobei es dadurch allein natürlich keine logische Auszeichnung für deren Inhalt gibt.

Viele Grüße
Thorsten

[suit]

Ja, genau. Aber sollte wie gesagt ja auch nur eine valide Alternative sein.
Es ist sicher sinnvoll die Textabsätze mit einem div zu gruppieren. Wobei es dadurch allein natürlich keine logische Auszeichnung für deren Inhalt gibt.

eben und leider gibts dafür kein passendes element so wie es bei q und blockquote ist ;) samp und blocksamp oder ähnliches wären praktisch

[Thorsten Schleppi]

Hallo!

eben und leider gibts dafür kein passendes element so wie es bei q und blockquote ist ;) samp und blocksamp oder ähnliches wären praktisch

Jap... Sagst du dem W3C bescheid? ;)

Viele Grüße
Thorsten

[suit]

Jap... Sagst du dem W3C bescheid? ;)

die hören eh auf keinen, die machen lieber stupid html 5 ;)

[Gunnar Bittersmann]

@@suit:

Jap... Sagst du dem W3C bescheid? ;)

Das wissen sie längst [XHTML2 §8.2] – jedenfalls die Guten[tm].

die hören eh auf keinen, die machen lieber stupid html 5 ;)

Das sind die Bösen[tm].

Live long and prosper,
Gunnar

[suit]

Jap... Sagst du dem W3C bescheid? ;)
Das wissen sie längst [XHTML2 §8.2] – jedenfalls die Guten[tm].

die frage ist allerdings noch, was der unterschied zwischen einem beispiel und einem codeschnipsel als beispiel ist - ein beispiel muss ja nicht unbedingt ein stück quellcode sein

kann ja auch so sein

<samp>z.B. du hast drei äpfel und zwei birnen, dann hast du in summe 5 stück obst</samp>

[Ingo Turski]

Hi,

die frage ist allerdings noch, was der unterschied zwischen einem beispiel und einem codeschnipsel als beispiel ist - ein beispiel muss ja nicht unbedingt ein stück quellcode sein

nicht nur das - ich finde die Idee mit <blockcode> Murks. Code ist nunmal Code und enthält nur Text. Absätze und Einrückungen können über white-space:pre erhalten werden und Syntax-Highlighting ggfls. über formatierte spans, Hervorhebungen über em und strong.

freundliche Grüße
Ingo

[suit]

nicht nur das - ich finde die Idee mit <blockcode> Murks. Code ist nunmal Code und enthält nur Text. Absätze und Einrückungen können über white-space:pre erhalten werden und Syntax-Highlighting ggfls. über formatierte spans, Hervorhebungen über em und strong.

stimmt auch wieder - an dieser stelle die frage: warum gibts die trennung zwischen block und inline-elementen überhaupt? wenn doch eine trennung von auszeichnung in gestaltung getrennt sein soll - hier sollte es doch keine rolle mehr spielen, ob etwas einen absatz erzeugt oder nicht

[at]

Hallo.

an dieser stelle die frage: warum gibts die trennung zwischen block und inline-elementen überhaupt? wenn doch eine trennung von auszeichnung in gestaltung getrennt sein soll - hier sollte es doch keine rolle mehr spielen, ob etwas einen absatz erzeugt oder nicht

Dann hätten wir Absätze, die keine Absätze erzeugen, und Überschriften, die nicht mehr über dem Text stünden. Daran erkennst du, dass das Bilden von Blöcken ein Stück weit zur Semantik der Elemente gehören kann. Dass das bei weitem nicht für alle Elemente gilt und ein sinnvolles Verschachteln häufig erschwert oder unmöglich macht, stimmt aber natürlich.
Generell wird so aber auch vermieden, dass man bei jedem einzelnen Element angeben muss, welches Element darin sinnvollerweise vorkommen darf. Dass man dann unter Umständen nur noch mit Hilfskonstruktionen ans Ziel gelangt, wird dabei in Kauf genommen.
Prinzipiell ist dein Ansatz also nicht uninteressant und wurde auch schon diskutiert, aber es überwogen wohl stets die Gegenargumente.
MfG, at

[suit]

Prinzipiell ist dein Ansatz also nicht uninteressant und wurde auch schon diskutiert, aber es überwogen wohl stets die Gegenargumente.

mir ist klar, dass eine überschrift einen absatz erzeugen soll - für diese aufgabe ist aber das default-stylesheet zuständig

wenn ich in meinem default-stylesheet "h1 { display: inline; }" reinpacke, bleibt h1 dennoch ein blockelement, welches halt als inline-element dargestellt wird

ich finde es von der seite her etwas unpraktisch, dass das aussehen quasi in der dtd festgelegt wird

was spricht gegen folgendes

<samp /> ist ein zustandsloses [1] element

<samp /> an einer beliebigen stelle ist im default-stylesheet per display: block; formatiert und erzeugt einen absatz

<samp /> als kind von <p />, <li /> oder sonstigen "klassischen" inline-elementen ist im default-stylesheet mit display: inline; formatiert

natürlich werden die default-stylesheets wesentlich komplexer, aber die komplexität verschwindet dafür an anderer stelle - einerseits durch einsparung von redundatem markup (2x das gleiche element, 1x als block und 1x inline) und andererseits in den vordefinierten eigeneschaften in den dtds

klein mäxchen stellt sich das so vor: es gibt nur noch inline-elemente die beliebige andere inline-elemente enthalten dürfen (mit einschränkungen, dass zb li nur ein kind von ul oder ol sein darf), die grundformatierung (ob absatzbildend oder nicht) wird übers default-stylesheet des browsers erledigt

bei tabellen hat das ja auch funktioniert - früher wurden tabellen vom browser ohne berücksichtigung von css mit einer eigenen routine dargestellt, jetzt ist dafür css verantwortlich - egal welche elemente mittels table, table-row und talbe-cell formatiert werden

[1] also keine klassifizierung nach block oder nicht block

[at]

Hallo.

Prinzipiell ist dein Ansatz also nicht uninteressant und wurde auch schon diskutiert, aber es überwogen wohl stets die Gegenargumente.

mir ist klar, dass eine überschrift einen absatz erzeugen soll - für diese aufgabe ist aber das default-stylesheet zuständig

Ich meine nicht die Darstellung, sondern die Semantik.

wenn ich in meinem default-stylesheet "h1 { display: inline; }" reinpacke, bleibt h1 dennoch ein blockelement, welches halt als inline-element dargestellt wird

ich finde es von der seite her etwas unpraktisch, dass das aussehen quasi in der dtd festgelegt wird

Wahrscheinlich ginge es dir schon besser, wenn sich die Begriffe unterschieden. Denn wenn es bei display: block; bliebe, aber <p> kein Block-, sondern ein Box-Element wäre oder das Inline-Element <samp> die Eigenschaft display: flow; hätte, könnte man die in der DTD definierten Eigenschaften der Elemente nicht mehr mittels CSS verändern. Damit wäre zumindest die Logik vordefinierter Elementgruppen und der Beeinflussung ihrer Darstellung durch die display-Eigenschaft voneinander getrennt.

was spricht gegen folgendes

<samp /> ist ein zustandsloses [1] element

<samp /> an einer beliebigen stelle ist im default-stylesheet per display: block; formatiert und erzeugt einen absatz

<samp /> als kind von <p />, <li /> oder sonstigen "klassischen" inline-elementen ist im default-stylesheet mit display: inline; formatiert

Dagegen spricht die Komplexität des Stylesheets. Denn wenn man deine -- an sich ja absolut nachvollziehbare -- Logik fortsetzt, stellt sich die Frage, was denn dann noch "klassische" Inline-Elemente sein sollen. Du stellst so doch letztlich jedes Element in die Abhängigkeit von seinem umgebenden Element. Oder du beschränkst das System auf eine Handvoll Elemente und schaffst so wieder Inkonsistenzen.

natürlich werden die default-stylesheets wesentlich komplexer, aber die komplexität verschwindet dafür an anderer stelle - einerseits durch einsparung von redundatem markup (2x das gleiche element, 1x als block und 1x inline) und andererseits in den vordefinierten eigeneschaften in den dtds

Aber immer das gleiche verhältnismäßig simple Stylesheet seriell auf alle möglichen Elemente eines Dokumentes anzuwenden, ist sehr viel einfacher und daher schneller als das Anwenden eines hochgradig komplexen Stylesheets auf ein nur geringfügig einfacheres Dokument. Sicher ist dieses Dokument dann semantisch sauberer oder enthält eine Handvoll umschließende Elemente weniger, aber das wiegt nach Ansicht der Verantwortlichen eben den Vorteil der einfacheren Verarbeitung bei weitem nicht auf. Aus dem gleichen Grund gibt es ja auch keine CSS-Selektoren für Elternelemente.

klein mäxchen stellt sich das so vor: es gibt nur noch inline-elemente die beliebige andere inline-elemente enthalten dürfen (mit einschränkungen, dass zb li nur ein kind von ul oder ol sein darf), die grundformatierung (ob absatzbildend oder nicht) wird übers default-stylesheet des browsers erledigt

Vegiss das Standard-Stylesheet besser. Wenn dort nicht für jedes einzelne Element in jeder erdenklichen Kombination sämtliche Eigenschaften bestimmt wird, wird es nicht zuverlässig funktionieren. Und die Hersteller zu einem gemeinsamen Standard zu bewegen, obwohl nicht einmal jeder von denen jede Eigenschaft für jedes Element unterstützt, ist utopisch.

bei tabellen hat das ja auch funktioniert - früher wurden tabellen vom browser ohne berücksichtigung von css mit einer eigenen routine dargestellt, jetzt ist dafür css verantwortlich - egal welche elemente mittels table, table-row und talbe-cell formatiert werden

Geschieht das tatsächlich? Vielleicht wird dort CSS überhaupt nur angewandt, wenn die Eigenschaften von denen in der DTD definierten abweichen -- auch wenn die DTD dazu nicht einmal ausgelesen wird. Ich weiß nicht, wie die einzelnen Browser das tatsächlich handhaben, aber du behauptest da etwas, von dem auch du vermutlich nicht mit Sicherheit sagen kannst, ob es überhaupt zutrifft.
MfG, at

[Der Martin]

Hallo Thorsten,

Warum? Ein div teilt Elemente in einen <http://de.selfhtml.org/html/text/bereiche.htm#block@title=allgemeinen Block> ein.

ich hätte es noch anders formuliert: Ein div-Element gruppiert andere Elemente. Es fasst also logisch zusammengehörende Elemente zu einem Block zusammen.
Und genau das ist doch hier auch gewünscht: Der OP möchte eine beliebige Kombination anderer Elemente zu einem Block mit der Bedeutung "Beispiel" zusammenfassen. Ich sehe das div-Element hier als prädestinierte Lösung, selbst auf die "Gefahr" hin, dass dieses div auch mal nur ein einziges Kindelement enthält, was ich normalerweise für Unsinn halte - hier würde ich das aber im Sinne einer einheitlichen Strukturierung billigen.

Der Quellcode mag aufgebläht sein

Ich finde es nicht mal aufgebläht, wenn ich ein paar p- oder sonstige Elemente mit einem div umschließe und dem eine Klasse gebe.

Und aus Validator-Sicht ist dieser Quellcode auch sauber.

Eben.

Schönes Wochenende,
 Martin

[Peter Pan]

Hi!

Wenn du zum Beispiel eine Codebox gestalltest,

Für Kühe und Pferde?

off:PP

[suit]

Wenn du zum Beispiel eine Codebox gestalltest,
Für Kühe und Pferde?

es geht in diesem thread um die eierlegende wollmilchsau :p

[Peter Pan]

Hi!

Wenn du zum Beispiel eine Codebox gestalltest,
Für Kühe und Pferde?

es geht in diesem thread um die eierlegende wollmilchsau :p

Mhm - vielleicht reicht ja auch ein Wolpertinger?
off:PP

[suit]

Mhm - vielleicht reicht ja auch ein Wolpertinger?
off:PP

das ist nicht artgerecht, die viecher gehören in den wald

[Peter Pan]

Hi!

Mhm - vielleicht reicht ja auch ein Wolpertinger?
off:PP

das ist nicht artgerecht, die viecher gehören in den wald

Du Öko-Geek! ;)

off:PP

[at]

Hallo.

die viecher gehören in den wald

Wenn man den vor lauter Dokumentenbäumen noch sieht.
MfG, at

[Cheatah]

Hi,

<samp style="display:block;"><p>[...]</p></samp>

das ist kein gutes Beispiel, da invalides HTML - egal, was Du per CSS vermittelst.

Dies gibt einen Anzeigefehler, die p rutschen aus dem samp heraus.

Führe einfach gar kein weiteres Element ein, sondern gib dem vorhandenen äußeren Container ein class="example" o.ä. Diesen Container hast Du ohnehin, und sei es nur um die Beispiel-Elemente zu gruppieren. Wenn Du sicherstellen willst, dass der als Beispiel ausgezeichnete Code trotz alledem unverändert bleibt, verwende ein <div class="example">.

Cheatah

[Harlequin]

Yerf!

Wo liegt das Problem?

Er will <samp> nicht als Blockelement haben, sodnern Blockelemente als Inhalt von <samp> und das auf HTML-Ebene. Genau das lassen aber die Regeln von HTML nicht zu.

Da bleibt wohl nur ein <div class="Beispiel">, oder hat jemand einen besseren Vorschlag?

Gruß,

Harlequin

[suit]

Da bleibt wohl nur ein <div class="Beispiel">, oder hat jemand einen besseren Vorschlag?

ich ich ich!

[Peter Pan]

Hi!

ich ich ich!

Seit wann stotterst du;)

off:PP

[suit]

Seit wann stotterst du;)

das war ein copy&paste-fehler :D

[Peter Pan]

Hi!

Seit wann stotterst du;)

das war ein copy&paste-fehler :D

Sowas dachte ich mir schon ;)

off:PP

[Der Martin]

Hallo,

Da bleibt wohl nur ein <div class="Beispiel">, oder hat jemand einen besseren Vorschlag?
ich ich ich!

wieso nur fällt mir jetzt der Esel aus "Shrek" ein ...?

Ciao,
 Martin

[Snafu]

Wenn ich andere Elemente effektiv drin haben will, z.B. p, dann ist es ja kein Beispielcode! Wenn das p-Element als Code drinstehen soll, dann kann ers ja einfach maskieren (&lt;p&gt;). Damit der Samplecode hübsch aussieht kann er ein pre-Element nehmen, wie suit gesagt hat.

[at]

Hallo.

Wenn ich andere Elemente effektiv drin haben will, z.B. p, dann ist es ja kein Beispielcode!

An diesem Satz irritiert ein wenig, dass du das der Negierung der Aussage dienende Ausrufezeichen an die Stelle setzt, an der normalerweise ein Satzzeichen die Aussage abschließt. Leichter lesbar wäre es, stattdessen auf das Wort "kein" zu verzichten.
MfG, at

[Thorsten Schleppi]

Hallo!

Wenn du das samp-Element als Blockelement haben willst, dann setzt doch einfach mittels CSS display:block;.

Und wenn der Validator meckert, ist ein p-Element außenrum semantisch durchaus sinnvoll. Oder eben ein semantisch fast unbedeutendes div.

Viele Grüße
Thorsten

[MudGuard]

Hi,

Hallo!
Ich muss ehrlich sagen, es war schwer dein Problem herauszusuchen.
Wenn du das samp-Element als Blockelement haben willst, dann setzt doch einfach mittels CSS display:block;. Wo liegt das Problem?

Dadurch, daß Du die Darstellung von inline auf block änderst, ändert sich nichts daran, daß auf HTML-Ebene das samp-Element ein inline-Element ist.
Und als solches darf es keine HTML-Block-Elemente enthalten.

cu,
Andreas

[EKKi]

Mahlzeit Snafu,

Ich muss ehrlich sagen, es war schwer dein Problem herauszusuchen.

Nein. Und gefunden hast Du es auch nicht ... :-)

Wenn du das samp-Element als Blockelement haben willst, dann setzt doch einfach mittels CSS display:block;. Wo liegt das Problem?

Das Problem ist, dass <http://de.selfhtml.org/html/referenz/elemente.htm#samp@title=<samp>> als Inline-Element keine Blockelemente wie <http://de.selfhtml.org/html/referenz/elemente.htm#p@title=<p>> enthalten darf - und die Darstellung per CSS spielt bei der Struktur überhaupt keine Rolle.

MfG,
EKKi

[suit]

Jedoch schreibe ich jetzt ein HTML Kurs und bin an dem Punkt, das ich meine Beispiele mit entsprechenden Tags hervorheben möchte. Wie ich dies style ist ja nicht das Problem, aber für zum Beispiel ein Beispiel, wie es später aussehen wird, gibt es zum Beispiel nur samp, was aber inline ist und code macht auch Probleme, wenn man darin ein p Element hat. Wie soll man also semantisch richtigen Code produzieren, wenn wichtige Elemente nicht als block existieren.

wenn du ein codebeispiel hast, nimm ein pre-element mit einem darinliegenden code-element und maskiere das p da drinnen, da du das beispiel ja anzeigen willst;

<pre><code>&lt;p&gt;</code></pre>

wenn jeder browser white-space: pre; richtig interpretierte, müsste man das eigentlich ungünstige <pre>-element nicht noch herumpacken

ob ein codebeispiel jetzt in ein code element, ein samp-element oder beides soll, ist eine streitfrage ;)

[at]

Hallo.

wenn du ein codebeispiel hast, nimm ein pre-element

Dem gegenüber hat ein <div> allerdings den Vorteil, dass es gar nicht erst versucht, eine Semantik vorzutäuschen.
MfG, at

[suit]

Dem gegenüber hat ein <div> allerdings den Vorteil, dass es gar nicht erst versucht, eine Semantik vorzutäuschen.

wenn du meinen post zuende liest, wirst du feststellen, dass ich das pre-element nicht als notwenig erachte - ein white-space: pre auf das code-element reicht auch aus

das pre-element drumherum hat aber den vorteil, dass der text auch mit default-stylesheet vorformatiert bleibt, bei einem div-element ist das nicht der fall

[at]

Hallo.

wenn du meinen post zuende liest, wirst du feststellen, dass ich das pre-element nicht als notwenig erachte - ein white-space: pre auf das code-element reicht auch aus

Ich habe den Beitrag bis zum Ende gelesen und du nimmst deine Empfehlung leider nirgends zurück. Auch einen Hinweis darauf, dass deine Lösung ein Scherz gewesen sein soll, finde ich dort nicht. Stattdessen empfiehlst du etwas, das du selbst in nicht näher spezifizierter Weise als eigentlich ungünstig bezeichnest. Und bei dieser Spezifizierung war ich gern behilflich.

das pre-element drumherum hat aber den vorteil, dass der text auch mit default-stylesheet vorformatiert bleibt, bei einem div-element ist das nicht der fall

Im Zusammenhang mit semantisch gutem XHTML, so der Titel jedes einzelnen Beitrags in diesem Thread, ist <pre> einfach nicht empfehlenswert. Und zur Verlässlichkeit von Standard-Stylesheets muss wohl auch nicht mehr viel gesagt werden.
MfG, at

[suit]

Ich habe den Beitrag bis zum Ende gelesen und du nimmst deine Empfehlung leider nirgends zurück. Auch einen Hinweis darauf, dass deine Lösung ein Scherz gewesen sein soll, finde ich dort nicht. Stattdessen empfiehlst du etwas, das du selbst in nicht näher spezifizierter Weise als eigentlich ungünstig bezeichnest. Und bei dieser Spezifizierung war ich gern behilflich.

damit hast du recht, nach nochmaligem durchlesen meines beitrags hab ich festgestellt, dass ich zu viel zwischen meinen eigenen zeilen lese ;)