ingeborg-bachmann.cc

Die Entwicklungszeit von tabellenbasierten Layouts ist einfach kürzer und effizienter. Außerdem sind sie sicherer, was Browserstabilität betrifft.

xhtml hat nichts damit zu tun, dass Layouts nicht tabellenbasiert sein dürfen. Auch wenn das w3c div-Layer als Layoutgerüst empfiehlt, ist meiner Ansicht nach bei kommerziellen Projekten in erster Linie der Kosten/Nutzen-Faktor für die geringere Entwicklungszeit bei Tabellenlayouts entscheidend.

Den momentanen Hype um CSS-Layouts kann ich nicht immer nachvollziehen. Obwohl ich selbst so weit wie möglich CSS einsetze, lege ich immer noch eine Tabelle als Grundgerüst an.

Ganz anders sieht es aus, wenn eine Site von vorneherein als barrierefrei geplant ist und umgesetzt werden soll. Dann muss man aber auch den Mehraufwand kalkulieren und auf mangelnde Abwärtskompatibiliät in den Browsern hinweisen! Es hat also alles seine Vor- und Nachteile und nicht alles, was momentan ein Hype ist, muss auch sinnvoll sein 😉

Was meinst du eigentlich mit den Absätzen in Tabelle? Die Texte im Content sind natürlich alle mit p-Tags umgeben und nicht in einzelnen Tabellenzellen.

Gruß, Jürgen

Kann mich der Stimmung nur anschließen, dass es eine tolle Seite ist.

Möchte das nicht trüben, sondern eher ein wenig motivieren: Wenn du nochmals so eine Seite machst, mit einem so tollen Layout, dann gestalte sie CSS-basiert. Deine vertikale Dreiteilung des Bildschirms wäre mit einer prozentualen Verteilung für unterschiedliche Fenstergrößen perfekt... Go ahead. 😃

Gruß,

Marcus Kunkel
KCPro

klettern6c schrieb

Wenn du nochmals so eine Seite machst, mit einem so tollen Layout, dann gestalte sie CSS-basiert. Deine vertikale Dreiteilung des Bildschirms wäre mit einer prozentualen Verteilung für unterschiedliche Fenstergrößen perfekt... Go ahead. 😃
KCPro

Vielen Dank erstmal, auch für die Tipps und Meinungen der anderen!

Die prozentuale Verteilung wollte ich bewusst nicht - ist ja auch nicht css-spezifisch, das ist auch mit HTML möglich. Gerade die fixe Positionierung und Breite macht für mich gestalterisch Sinn. Aber das ist sicherlich Geschmackssache 🙂

Jürgen_PXM schrieb

xhtml hat nichts damit zu tun, dass Layouts nicht tabellenbasiert sein dürfen. Auch wenn das w3c div-Layer als Layoutgerüst empfiehlt, ist meiner Ansicht nach bei kommerziellen Projekten in erster Linie der Kosten/Nutzen-Faktor für die geringere Entwicklungszeit bei Tabellenlayouts entscheidend.

Den momentanen Hype um CSS-Layouts kann ich nicht immer nachvollziehen. Obwohl ich selbst so weit wie möglich CSS einsetze, lege ich immer noch eine Tabelle als Grundgerüst an.

das stimmt schon, dass table based layouts auch mit xhtml erlaubt sind. der sinn von xhtml bzw. der gesamten standardisierungs- idee ist aber nicht, einfach eine neue syntax einzufuehren, sondern einen standard fuer die sinnvolle auszeichnung von online content einzufuehren (trennung von content und layout, keine ueberfluessigen elemente wie bspw. die tables und leer gifs in table based layouts). die daraus entstehenden vorteile sind nicht nur kleinere seiten und somit (teilweise dramatisch) weniger traffic sondern einfachere wartbarkeit (der quelltext sieht fuer voellig verschiedene layouts immer gleich aus, siehe www.csszengarden.com), wiederverwendbarkeit von content ohne grosse umformungen (meinen xml content kann ich ueber ein zugewiesenes css direkt im browser anzeigen oder auch per xsl transformation in ein pdf umwandeln) usw. usf.
ich mache auch nicht alles was ich mache nach diesen gesichtspunkten weil es in der tat deutlich laenger dauert (zumindest bis man sich umgestellt hat) und mit netscape 4 & co. natuerlich absolut nicht funktioniert.
im grunde ist es aber wichtig, dass sich das moeglichst schnell durchsetzt. ich habe keine lust in 2-3 jahren noch webseiten zu machen wie es heute noch weit verbreitet ist mit x verschachtelten tabellen und leer gifs usw. usf.

marco

[​quote="marcoow"]

Jürgen_PXM schrieb

im grunde ist es aber wichtig, dass sich das moeglichst schnell durchsetzt. ich habe keine lust in 2-3 jahren noch webseiten zu machen wie es heute noch weit verbreitet ist mit x verschachtelten tabellen und leer gifs usw. usf.

Da bin ich absolut deiner Meinung! Ich habe auch nur noch eine umschließende Tabelle für das Grundlayout in meinen letzten Seiten herangezogen und den Rest über CSS-Formatierungen gemacht. Netscape 4 unterstütze ich nicht mehr, wenn der Kunde einverstanden ist (und das ist das entscheidende!).
Ein anderer Aspekt bei CSS-Umsetzung ist allerdings, dass meiner Erfahrung nach ein reines CSS-Layout ohne Browserhacks nicht möglich ist. So mancher Workaround, den man für ein Containerlayout einsetzen muss, erinnert mich nicht zufällig an die DHTML-Browserweichen von seinerzeit! Und daher halte ich derzeit noch ein Hybridlayout Tabelle/CSS für sinnvoller. Jeffrey Zeldmans Buch "Designing with web standards" beschreibt das Problem recht gut, auch wenn die obige Schlussfolgerung meine eigene Interpretation des Buches ist 😃.

Du hast natürlich recht mit der Trennung Content/Layout und ich versuche das auch so weit wie möglich zu trennen. Aus dem angesprochenen Grund der Hacks bin ich aber noch skeptisch, ob die Zeit wirklich reif ist. Die Orientierung an der derzeitigen Browserlandschaft und nicht an der Technik um ihrer selbst willen ist hier für mich im Moment noch der richtigere Weg. Toll finde ich, dass man mit Typo3 nun wirklich sauberen Code produzieren kann, was bei vielen CMS kaum oder nur mit sehr hohem Aufwand möglich ist. Bei 3.5 bzw. dem noch unfertigen css_styled_content war das ja mit vertretbarem Aufwand auch kaum möglich.

Manchmal wundere ich mich schon sehr über die weltfremden Ansichten so manches CSS-Freaks, wenn da auf die Frage hin, warum der Code in IE6 nicht läuft, die Antwort kommt: "Na und? In den guten Browsern läufts ja". Dummerweise werden aber die vermeintlich "guten" Browser nur von 5 - 15 Prozent der Besucher verwendet
:o. Das ist jetzt natürlich nicht auf dich bezogen - soll nur verdeutlichen, dass man die Seiten nicht um des schönen Codes willen macht, sondern für den Kunden und dessen Interessenten bzw. Websitebesuchern.

Im Grunde bin ich also voll und ganz deiner Meinung - nur noch aus den beschriebenen Gründen ein wenig zurückhaltend 😉.

Gruß, Jürgen

ja, ist schon noch die frage, ob die zeit jetzt schon reif ist, das ist schon richtig. man kann aber eine menge schon mit der beschriebenen trennung hinkriegen das dann in allen browsern ab ie5, nn6 funktioniert- zugegebenermassen mit hilfe der einschlaegigen css hacks. prinzipiell aber lieber ein hack im css als im xml. wir haben es in einigen der letzten projekte uebrigens dann so gemacht, dass eine seite, die im netscape4 (ist ja mehr oder wenigr der einzige browser, der gemessen an heutigen massstaeben im grunde gar nichts kann) genau so aussieht wie in anderen browsern einfach teurer ist. der aufwand den man in diesen #$%##$$-browser steckt ist manchmal auch nicht grossartig kleiner als der aufwand den ich fuer eine moderne xml/css seite brauche.

Sicher richtig - ich würde auch einen Mehrpreis für eine NN4-Kompatibilität verrechnen, falls das von mir jemand fordern sollte. Bin aber im Grunde genommen froh, wenn mich niemand darauf anspricht 😃.

Die Weiterverarbeitung der Daten in xml ist natürlich ein gutes Argument für ein CSS-Layout und in dem Fall wird die Arbeitszeit an der Quelle auf jeden Fall besser investiert sein als hinterher bei der Ausgabe bzw. Weiterverarbeitung, keine Frage. Solche Projekte haben allerdings dann meist auch einen größeren Budgetrahmen, bei dem man mehr Spielraum hat.

Super Site!

was ich gefunden habe, ist auch mein Problem 😃
http://ingeborg-bachmann.cc/kontakt.html nicht XHTML valid

Grund Parameter "virtual" in TEXTAREA-tag.

Hat einer eine Idee, wie man dies umgehen kann?

Ah - danke für den Tipp, das ist mir gar nicht aufgefallen. Ich werde mal sehen, wo man das ändern kann.

Ich habe das Problem mit dem wrap="virtual" im textarea-Tag jetzt einmal nachvollzogen. Das Attribut ist zwar mit dem auf die Zeilenanzahl folgenden Parameter innerhalb des Feldes für die Formularkonfiguration z. B. auf "off" folgendermaßen änderbar:

Nachricht: | nachricht=textarea,40,5,OFF |

... was in dem Fall keinen Sinn machen würde, aber ganz weg bringt man ihn nicht, wie es der xhtml-Standard verlangen würde, wenn ich das richtig sehe.

Hardcoded in der Datei /typo3/sysext/cms/class.tslib_content.php ist folgende Zeile (1619):

$wrap=trim($fParts[3]) ? ' wrap="'. trim($fParts[3]).'"' : ' wrap="virtual"';

mit der entweder der Wert aus dem Feld oder (wenn nicht vorhanden) eben "virtual" eingesetzt wird.

D. h. ohne der Änderung im PHP-Quellcode dürfte da nach meinem Verständnis nichts machbar sein 🙁.

Gruß,
Jürgen

Hi,

ich möchte nicht PHP-Code in Core selber ändern. Damit habe ich kein Problem, aber Version-Update bringt wieder das gleiche. Man vergisst schnell, was man geändert hat. 😃 Und ich mache Updates sehr gern. Arbeite immer mit last Version.

Wäre das nicht besser Kasper zu melden, damit er diese Änderung als To-Do in eigene Liste aufnimmt?

Damit haben wir dann selber keine Probleme mehr.