[Nimroy]

weil dann die paddings und margins wieder greifen würde und die Zwischenüberschriften arg verloren im Raum stehen würden.

Probier morgen mal das vom Datenkind. Es sei denn, jemand macht nen anderen Vorschlag um ZWischenüberschriften in einem Fließtext valide zu realisieren.

[Doppelplusgut]

Wie wäre denn die Verwendung von <span> für die Zwischenüberschriften?

[rob]

span für die "zwischenüberschriften" verwenden ist IMHO ganz großer murks.
html ist eine auszeichnungssprache. das ist eigentlich mal dafür entwickelt worden, um text logisch auszuzeichnen.
weil es keine andere möglichkeit gab, mußte man html dann auch für designzwecke mißbrauchen (z.b. tabellen für nicht-tabellarischen inhalt -> layouttabellen, u.a.).

jetzt kann man aber den inhalt und das layout voneinander trennen und sooo laaangsam sollten auch die letzten mal dazu übergehen, sauberen und logisch ausgezeichneten code zu schreiben.
guter semantisch ausgezeichneter code läßt sich dann auch für alle möglichen medientypen stylen, problemlos in andere formate tranformieren, maschinell auslesen und problemlos weiterverarbeiten, und so weiter und so fort.

der code muß dazu aber halt korrekt und logisch ausgezeichnet sein, sprich für überschriften sollten auch die entsprechenden tags genutzt werden.
überschriften höchster wichtigkeit bekommen einen h1, die folgenden dann einen h2 und so weiter.
das hat dann aber noch nichts mit dem aussehen zu tun, weil man ja per css hier z.b. auch die schriftgrößen festlegen kann.

nunja, jedenfalls macht es keinen sinn, eine überschrift als span zu kennzeichnen. das geht dann wieder am sinn der semantischen auszeichnung vorbei.
außerdem können die robots der suchmaschinen das dann schon nicht mehr so werten, wie es sein sollte (->SEO).
und außerdem ist ein span ein inline-element, während ein h1 (h2, h3, ...) ein blocklevel-element ist und eine box erzeugt (falls gewünscht wird, daß ein h1 keine box erzeugt, dann sollte man display auf inline setzen, aber halt kein span verwenden).

tja und im übrigen ist es überhaupt kein problem, ein div in einen div zu packen. das kann natürlich zu einem problem werden, wenn man falsch vorgeht. ab und zu sieht man es mal, daß leute ein tabellenlayout auf css umstellen wollen, aber nicht so recht wissen, was sie tun sollen. dann findet man ab und zu mal websites, wo der code aus unmengen von grauenvoll ineinander verschachtelten divs besteht...
aber wie gesagt: prinzipiell überhaupt kein problem; nur übertreiben sollte man es nicht. oftmals habe ich im body ein <div id="navi"> und dann ein großes <div id="content">, daß alles andere umfasst. da sind dann vielleicht noch weitere divs drin, weil ich mein layout in mehreren spalten präsentieren will...

ich weiß ja jetzt nicht, wie das layout nachher aussehen soll, aber vermutlich würde ich das in etwa so machen:

[Account gelöscht]

Da hat der Rob mal wieder ganz recht, wenn es sich auch ziemlich
wirr anhört, was er da schreibt. Stell dich mal nicht dümmer, als
du bist; "wat valid is" (o-ton beeviz und rest) heißt im Grunde einfach
nur, dass dein SGML/XML Quelltext "valide", d.h. nach einer entspr.
SGML/XML-DTD bzw. Schema o.Ä. "gültig" ist. In einer DTD ist bspw.
festgelegt, welche Elemente in welchem Kontext (Verschachtelung)
vorkommen können/dürfen/müssen. Dies sagt allerdings in den wenigsten
Fällen etwas darüber aus, ob das Ganze denn auch "semantisch korrekt"
ist (dazu muss die DTD *etwas* ausgefeilter sein als ne HTML-DTD,
und dennoch kann der Anwender - ist der Dokumenttyp komplex genug -
selbst immer noch genug Fehler einbauen) und NIE sagt es etwas darüber
aus, ob es sich bei dem betr. Tag nun um ein Inline- oder um ein Block-
element (oder um eines, welches ganz anderen Zwecken genügt) handelt.

Wenn Rob schreibt "guter semantisch ausgezeichneter code läßt sich
dann auch für alle möglichen medientypen stylen, problemlos in andere
formate tranformieren, maschinell auslesen und problemlos weiterver-
arbeiten, und so weiter und so fort.", hat er auch durchaus recht damit.
Leider ist gerade HTML in dem Sinne noch mit einem unheimlichen Nach-
teil behaftet, nämlich dem, dass es einerseits den Anspruch einer reinen
Auszeichnungssprache hat, andererseits allerdings (grundsätzliche) Mittel
einer Seitenbeschreibungssprache mitbringen MUSS. Dies ist ein ziemlich
hässlicher Charakterzug, kann doch bspw. die spaltenweise Aufteilung
deiner Internetseite plötzlich die Reihenfolge jeder Semantik total durch-
einanderwerfen. Oder der andere Fall: Interessiert es den Browser, in
welcher Reihenfolge du deine (h1...h2... etc strukturierten) Kapitel im
Code niederschreibst, wenn du alle in einzelnen <div>-Elementen ver-
ankerst und absolut aufm Screen positionierst?

Wie auch immer, schau datte alle Elemente im erlaubten Rahmen plat-
zierst, dann sollte schon alles ok sein. Jeder "Validator" im I-Net
kann dir bei der Prüfung behilflich sein. Aber versteif dich nicht in dem
ganzen schrottig/quasi-religiösem Geseiere vom "semantischen Code" etc.,
die Leute, die diese (durchaus löbliche) Designphilosophie mit dem jetzigen
HTML- und Browserstand zusammen in den Himmel loben, würde ich gerne
mal hauen, aber kräfig.

///
Übersetzt in eine (meiner Meinung nach) sinnvolle Struktur, lautete der
oben gepostete Code:

[Raumwurm]

[Nimroy]

Okay, gleich mal zwei der Ansätze hier ausprobiert. Danke für die Antworten.

Schinken, deinen Beitrag merk ich mir. Aber für ne Web-Site halte ich es für zu aufwendig.