CSS - Layout : Theoretischer Ansatz und praktische Anwendung

[Jan]

Hallo,

für alle CSS-Freaks hier zwei Fragen (Aufgaben?), um mal aus reiner Neugier die Meinungen Anderer einzuholen. Bitte nicht über den Sinn so eines Layouts streiten, es geht mir um den theoretischen Ansatz.

1. Für ein spezielles Design ist es notwendig, eine Anzahl Werte genau in einem bestimmten Muster zu organisieren. Das folgende Beispiel soll das Ganze etwas verdeutlichen. "1" stellt einen Wert (Text) dar, "-" einen gleichgrossen Leerbereich.

-------------------------
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-------------------------

Soweit ich das sehe, gibt es drei Möglichkeiten diesen Aufbau zu verwirklichen:
a) Tabellenlayout mit festen Zellangaben oder Blank-Gifs
b) Einfacher Text mit vielen, vielen  
c) DIV-Layout, allerdings mit 45 einzelnd positionierten DIVs

Mir persönlich gefällt vom Konzept her c) am besten, nur leider erzeugt das eine nicht zu rechtfertigende Codeflut. a) ist aus der Sicht am effektivsten, zwingt einen aber wieder in alte Layoutstrukturen und b) riecht nach ganz schlechten Coding-Stil.

2. Wenn ein Layout die Aufteilun von Formularfeldern auf mehrere positionierbare Bereiche erzwingt (Bezug auf das Netscape 4.7 Layer/DIV-Objektproblem), bevorzugt ihr welche Möglichkeit?
a) Auf Tabellenlayout zurückgreifen um Netscape 4.7 zu berücksichtigen.
b) Netscape 4.7 "vergessen".

Danke für eure Kommentare.

Jan

[Holger]

Hallo auch...

Wenn ich Dich richtig verstanden habe, stellt sich das "Problem" doch eigentlich gar nicht.

(...) eine Anzahl Werte genau in einem bestimmten Muster zu organisieren.(...)

---

-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-

Diese Art der Darstellung ist tabellarisch; und da sie dies ist ist meines Erachtens auch die Tabelle die einzig sinnvolle Darstellungsweise.

Gruß,

Holger

[Jan]

Hallo Holger,

Wenn ich Dich richtig verstanden habe, stellt sich das "Problem" doch eigentlich gar nicht.
Diese Art der Darstellung ist tabellarisch; und da sie dies ist ist meines Erachtens auch die Tabelle die einzig sinnvolle Darstellungsweise.

nicht ganz, die Daten selbst stehen nicht in einem tabellarischen Kontext. Können also vom Inhalt her nicht in Zeilen und Spalten sortiert werden. Dadurch und insbesondere durch die erzwungenen leeren Bereiche wäre die Tabelle nur ein Layouthilfsmittel. Zu verwirklichen ist es ja über alle drei Ansätze, es geht mir eher um die Grundsatzfrage, welches die eleganteste, bzw. vom Standpunkt der Validität beste Lösung ist.

Grüsse
Jan

[benji]

vom Standpunkt der Validität beste Lösung ist.

Ich denke, wir sind uns da ALLE einig, dass es nur Tabellen als einzige richtige Lösung gibt - man beachte nur-Text-Browser, etc. ....

benji

[Holger]

Ok, überzeugt.

Trotzdem würde ich persönlich in diesem Fall "zur Tabelle greifen" (und zur Not sogar zu transparenten Gifs). Und zwar einzig und allein aus Gründen der Bequemlichkeit. Wahrscheinlich werden sich ein paar Leute jetzt die Haare raufen.

Gruß,

Holger

[Chräcker Heller]

Hallo,

Dadurch und insbesondere durch die erzwungenen leeren Bereiche wäre
die Tabelle nur ein Layouthilfsmittel.

Tabellen sind immer nur ein Layoutmittel, ob die Datne nun in einen "textsinn-zahlensinnzusammenhang stehen" oder nur in einen rein optischen, leichter mit dem Auge abscanbaren, Zusammenhang stehen. table,tr und td tags dienen immer nur als Gerüste, um Daten angenehmbar aufnehmbar zu gestalten und darzustellen. Das Daten dann zueinander in einem Zusammenhang stehen gibt der "tabelarischen Anordnung" lediglich eine weitere Sinntiefe. Aber Tabellen dienen bei Hypertexten immer nur dem Layout.

Chräcker

[emu]

Hallo!

Tabellen sind immer nur ein Layoutmittel.

Das sehe ich ganz anders. Auch wenn Netscape bei der Erfindung der Tabellen eventuell an die Möglichkeiten zur Beeinflussung des Layouts gedacht haben mag und Tabellen lange Zeit so eingesetzt wurden, heißt das noch lange nicht, dass das für die Tabellenelemente in HTML zutrifft.

Meiner Meinung nach zeichnen diese Elemente tabellarische Daten aus. Das sind Werte, die in bestimmter Relation zueinander stehen (jedoch nicht in 1:1-Zuordnung, dafür sind Definitionslisten zuständig). Diese Werte müssen nicht einmal zwangsläufig so aussehen wie Tabellen im herkömmlichen Sinn, sondern können auch mit CSS das Aussehen eines ganz normalen Textes bekommen (die HTML-Spezifikation ist bei diesem Punkt etwas schwammig formuliert und argumentiert sogar mit dem Vorhandensein von Tabellen in Textverarbeitungsprogrammen, aber sie unterstützt weitgehend diese These.[1]).

Das klassische Einsatzgebiet für Tabellen, nämlich ein paar Spalten für Inhalt, Navigation und den ganzen Rest zu bieten, erfüllt nicht die Anforderungen an tabellarischen Inhalt. Selbstverständlich stehen die Daten in einer gewissen Relation zueinander (sie gehören zu dem selben Dokument), es findet jedoch keine Zuordnung zwischen den einzelnen Elementen der Tabelle statt. Deswegen kann die Verwendung von <table> für Layout semantisch gesehen nicht korrekt sein.

Du hast natürlich recht, dass man immer *irgendeine* Relation zwischen den Daten unterstellen kann, aber das legitimiert nicht die Verwendung von Tabellen für klassische Layoutaufgaben (Divs auch nicht, aber das ist eine andere Geschichte)

[1]»The HTML table model leaves most rendering information to associated style sheets. The model presented in this specification is designed to take advantage of such style sheets but not to require them.«
http://www.w3.org/TR/html4/appendix/notes.html#notes-tables

emu

[Chräcker Heller]

Hallo,

Du diferenzierst jetzt, treffend, in Daten, die einen "tabelarischen Charakter" haben (Bezug zueinander) und in Inhalte/Daten, die keinen tabelarischen charakter haben. Das ändert aber nichts an meiner Aussage:

Tabellen sind immer nur ein Layoutmittel.

Wenn ich Daten, die einen Bezug zueinander haben, so darstellen will, das man den bezug auch klar visuell erkennen kann, dann nehme ich Tabellen-Tags. Eben eine tabelle. Ich layoute also die Daten mittels der tabellenmöglichkeiten so, das man den Bezug leicht visuell nachvollziehen kann. Insofern nutze ich eine Tabelle zum Layout. Welche wichtige Funktion, außer zur visuellen darstellung von Tabellendaten (abgesehen von einer maschinenlesbarkeit....), hätte den der Einsatz sonst? Zum "layoten" von tabellendaten (bei Dir), zum layouten für "ist-mir-egal" vielleicht bei mir, aber immer zum "layouten"....

Chräcker

[emu]

Hallo!

Wenn ich Daten, die einen Bezug zueinander haben, so darstellen will, das man den bezug auch klar visuell erkennen kann, dann nehme ich Tabellen-Tags. Eben eine tabelle.

Du bist anscheinend der Meinung, die diesbezüglichen Elemente in HTML definierten eine Tabelle im herkömmlichen Sinn mit Kästchen und Strichen, also das Aussehen. Wenn dem so wäre, dann wären Tabellen längst deprected, weil sie ja das Aussehen definierten. In HTML kann man aber nur die Struktur von Daten definieren. Daher ist ein <table> keine Tabelle im layouttechnischen Sinn, sondern ein Container für tabellarische Daten.

Ich layoute also die Daten mittels der tabellenmöglichkeiten so, das man den Bezug leicht visuell nachvollziehen kann.

Das ist nicht unbedingt notwendig. Der Sinn von tabellarischen Daten kann durchaus gelegentlich ohne eine Tabelle im physischen Sinn besser erkannt werden (sagen wir als Liste mit durch Schrägstriche getrennten Werten oder als normale Zeile mit unterschiedlichen [visuellen] Hervorhebungen). Trotzdem müsste sie (theoretisch) als <table> gespeichert werden.

Welche wichtige Funktion, außer zur visuellen darstellung von Tabellendaten (abgesehen von einer maschinenlesbarkeit....), hätte den der Einsatz sonst?

Semantik (was indirekt dazu führt, dass Tabellen eben nicht nur visuelle Objekte sind, sondern zum Beispiel auch aural ausgegeben werden können). Abgesehen davon ist Maschinenlesbarkeit für mich schon ein hinreichender Grund.

emu

[stefan]

Hi emu,

Du bist anscheinend der Meinung, die diesbezüglichen Elemente in HTML definierten eine Tabelle im herkömmlichen Sinn mit Kästchen und Strichen, also das Aussehen. Wenn dem so wäre, dann wären Tabellen längst deprected, weil sie ja das Aussehen definierten. In HTML kann man aber nur die Struktur von Daten definieren. Daher ist ein <table> keine Tabelle im layouttechnischen Sinn, sondern ein Container für tabellarische Daten.

Sehr schön erklärt. Ich hab bei Cräckers Argumentation die ganze Zeit nach dem "Fehler" gesucht (nix für ungut). Aber klar: HTML ist nicht per sé visuell zu erfassen (vergess' ich bloss immer wieder). Im vorherigen Posting erwähntest Du <div>'s, die auch nicht allein zu Layout-zwecken (bzw. als neutrales blocklevel-element) gedacht seien. Das war mir neu. Wofür sind <div>s denn eigentlich gedacht? (für den Fall, dass Du grad nen Link oder ein nettes Beispiel parrat hast...)

schönen abend noch + schö
stefan

[Chräcker Heller]

Hallo,

Sehr schön erklärt.

stimmt, so habe ich es auch jetzt gesehen und verstanden. Ich denke, ein Mißverständnis, dem auch ich, wie aber auch manche andere der "Gegenseite" aufsitzen, rührt von den beiden "Ebenen": das, was hinter der optischen Ausgabe passiert (Tables zur Strukturierung von vergleichbaren daten in einer (html-)Datei zur Interpretation durch Maschienen zwecks individueller Weiterverarbeitung wie eben individuelles Ausgabegeräte) und in der tat das, was Tabellen (schon immer) für unser Auge machen, nämlich Inhalte so zu layouten, auf das wir sie besser wahrnehmen. Mir selber war maschienenlesbarkeit und "Strukturtreue" (oder wie man das immer nennen will) nicht so wichtig wie das, was letztendlich sich auf dem Weg zum Auge macht. (wenn der besucher eben sehend ist, da ist auch ein Knackpunkt, aber ich biete ja auch Nischenprodukte an....)

In dem Sinne gebe ich ja auch immer gerne zu, das ich nicht wirklich html-Seiten erstelle sondern html nur als vehikel, eben Klebemittel, für andere Dinge nutze. Aber wie dem auch sei, man muß dann doch bei der Aussage "Tabelle sind nur für dieses oder jenes da" unterscheiden, ob man Tabelle als Strukturmittel wie bei html meint oder das visuelle Layout-Mittel Tabelle, wie jeder früherer Buchhalter mit seinen Kontobüchern, Lineal und Bleistift sich welche erstellte... Da wir aber hier von html reden: habe ich jetzt verstanden ,-)

Chräcker

[emu]

Hallo!

Im vorherigen Posting erwähntest Du <div>'s, die auch nicht allein zu Layout-zwecken (bzw. als neutrales blocklevel-element) gedacht seien.

Laut Spezifikation ist es ein generisches Element, für Fälle, bei denen kein HTML-Element für die Auszeichnung geeignet wäre[1]. Es wird explizit auf die Verwendung zu Layoutzwecken hingewiesen und das wäre auch kein Problem, solange es tatsächlich den Inhalt strukturiert[2]. Einen Container mit der Navigation und einen Container mit dem Inhalt zu definieren ist zwar oft nicht unbedingt nötig, aber vielleicht sinnvoll. Es gibt aber viele Seiten (meine Blindtextseite zum Beispiel), die <div> nur dazu verwenden, um ihr Design zusammenzuhalten. Es gibt Seiten mit zehn und mehr leeren <div>, die nur für irgendwelche bunten Balken gedacht sind. Das hat mit Semantik nichts mehr zu tun.

Weitere sinnvolle Verwendungsmöglichkeiten wären beispielsweise ein Ersatz für <section>, das ja erst mit XHTML 2 eingeführt werden soll[3], oder als Container für einen Teil der Seite, deren Sprache von der übrige Seite abweicht.

[1] »The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.«
(http://www.w3.org/TR/html4/struct/global.html#h-7.5.4)

[2] »Suppose, for example, that we wanted to generate an HTML document based on a database of client information. Since HTML does not include elements that identify objects such as "client", "telephone number", "email address", etc., we use DIV and SPAN to achieve the desired structural and presentational effects.«
(ebd.)

[3] http://www.w3.org/TR/xhtml2/mod-text.html#sec_8.17.

emu

[benji]

Hallo Jan !

Mir persönlich gefällt vom Konzept her c) am besten, nur leider erzeugt das eine nicht zu rechtfertigende Codeflut. a) ist aus der Sicht am effektivsten, zwingt einen aber wieder in alte Layoutstrukturen und b) riecht nach ganz schlechten Coding-Stil.

Auf jeden Fall. Bei so vielen div's verliert wohl jeder die Üersicht, Downloadzeit ist viel größer und anders geht's auch (ich bevorzuge nun logischerweise die Tabelle - wer möchte wohl mit 100000000  's umgehen müssen ...)

2. Wenn ein Layout die Aufteilun von Formularfeldern auf mehrere positionierbare Bereiche erzwingt (Bezug auf das Netscape 4.7 Layer/DIV-Objektproblem), bevorzugt ihr welche Möglichkeit?
   a) Auf Tabellenlayout zurückgreifen um Netscape 4.7 zu berücksichtigen.
   b) Netscape 4.7 "vergessen".

Tja, ich selbst habe in meinen Bekanntschaften niemanden, der mit Netscape überhaupt surf (IE und eine mit Opera), dementsprechend würde ich 4.7 vergessen. Man schaue sich mal Statistiken an: Kaum einer surft mit dem 4.7er. Außerdem würde ich mein Layout wenn überhaupt für Netscape, dann (ab dem) 6er.

Falls ich jedoch überwiegend Uralt-Freaks mit 1992-er PC's haben würde (mein Vater macht mit solchen Leuten rum - die haben Homepages, die völlig auf den 4.7er Browser spezialisiert sind - grauenhaft), dann wäre natürlich eine Tabellendesign notwendig (oder ein JavaScript, der jenachdem eine Seite mit positionierten div's oder Layern ansteuern würde).

viel Spaß noch,

benji

[Cyx23]

Hallo benji,

Falls ich jedoch überwiegend Uralt-Freaks mit 1992-er PC's haben würde (mein Vater macht mit solchen Leuten rum - die haben Homepages, die völlig auf den 4.7er Browser spezialisiert sind - grauenhaft), dann wäre natürlich eine Tabellendesign notwendig (oder ein JavaScript, der jenachdem eine Seite mit positionierten div's oder Layern ansteuern würde).

das vorliegende Beispiel liesse sich vmtl. per span gleichermassen für Netscape 4 und andere Browser realisieren.

Auch wenn ich mich jetzt nicht sogleich in die Entwicklung des entspr. Code stürze, befürchte ich dass du dich mit Netscape 4.7 nicht besonders gut auskennst.
Sorry falls ich mich da beim konkreten Beispiel irren sollte, aber verzichte doch bitte auf Behauptungen wie "dann wäre natürlich eine Tabellendesign notwendig (oder ....".
Sicherlich ist die Tabelle _immer_ eine Option für _alle_ Browser. Hier wäre das Handwerkszeug aber nach den Vorgaben erstmal CSS, display, float, und width.
Dann bringst du offenbar ("1992") die Jahre etwas durcheinander, solltest du nochmal deinen Vater fragen, -oder du meinst Netscape 4.7 gäbe es nur unter Win3?- jedenfalls gibt es mit Netscape 7 erst seit ein paar Monaten einen Nachfolger des NC4, wenn man weiss dass es keinen NC5 gab und dass der NN6 eher eine Alphaversion Mozilla 0.8 o.ä. war.

Grüsse

Cyx23

[Fabian Transchel]

Hi Jan,

---

-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-
-1----11--1---11-----111-

wie wär's mit <pre>?

Guten Abend, Fabian

[Christian Seiler]

Hallo Jan,

2. Wenn ein Layout die Aufteilun von Formularfeldern auf mehrere positionierbare Bereiche erzwingt (Bezug auf das Netscape 4.7 Layer/DIV-Objektproblem), bevorzugt ihr welche Möglichkeit?

Wann sollte das notwendig sein? Jetzt mal den Realisierungskram beiseite - warum sollte ich ein Formular über größere Teile der Seite erstrecken wollen? Das gibt doch alleine schon wegen der Benutzerführung keinen Sinn - Formulare sollten doch sowieso »zusammen« bleiben. Mich würde mal ein Fall interessieren, wo so etwas notwendig sein sollte.

Viele Grüße,
Christian

[Jan]

2. Wenn ein Layout die Aufteilun von Formularfeldern auf mehrere positionierbare Bereiche erzwingt (Bezug auf das Netscape 4.7 Layer/DIV-Objektproblem), bevorzugt ihr welche Möglichkeit?
   Wann sollte das notwendig sein? Jetzt mal den Realisierungskram beiseite - warum sollte ich ein Formular über größere Teile der Seite erstrecken wollen? Das gibt doch alleine schon wegen der Benutzerführung keinen Sinn - Formulare sollten doch sowieso »zusammen« bleiben. Mich würde mal ein Fall interessieren, wo so etwas notwendig sein sollte.

Hallo Christian,

wie gesagt: "Bitte nicht über den Sinn so eines Layouts streiten, es geht mir um den theoretischen Ansatz."
Aber trotzdem zur Erklärung, eine Aufteilung kann notwendig sein, wenn das Design die Versetzung einzelner Formularelemente erfordert. Beispiel:

--------------------

• Input -          -
  --------- Textarea -
• Input -          -
  --------------------

Das würde sich ansonsten nur wieder über Tabellenlayout machen lassen.

Grüsse
Jan

[Christian Seiler]

Hallo Jan,

Beispiel:

---

• Input -          -
  --------- Textarea -
• Input -          -

---

Das würde sich ansonsten nur wieder über Tabellenlayout machen lassen.

Warum? Das geht doch auch wunderbar mit Netscape 4:

http://www.christian-seiler.de/temp/test-form-pos.html

Viele Grüße,
Christian

[Jan]

---

• Input -          -
  --------- Textarea -
• Input -          -

---

Das würde sich ansonsten nur wieder über Tabellenlayout machen lassen.

Warum? Das geht doch auch wunderbar mit Netscape 4:

http://www.christian-seiler.de/temp/test-form-pos.html

Hallo Christian,

stimmt, Netscape verkraftet ja nur keine absolut positionierten DIVs in Formularen. Danke, das hab ich völlig übersehen.

Grüsse
Jan

[Cyx23]

Hallo,

2. Wenn ein Layout die Aufteilun von Formularfeldern auf mehrere positionierbare Bereiche erzwingt (Bezug auf das Netscape 4.7 Layer/DIV-Objektproblem), bevorzugt ihr welche Möglichkeit?
   a) Auf Tabellenlayout zurückgreifen um Netscape 4.7 zu berücksichtigen.
   b) Netscape 4.7 "vergessen".

natürlich c), es für NC4.7 realisieren.

Auch bei Frage 1 vermute ich dass es weitere Lösungen oder Varianten von
c) gibt, div /span oder verschachtelt.

Grundsätzlich ist gegen Tabellen viel weniger einzuwenden als hier im Forum oft
zu lesen ist, es ist aber auch für Netscape 4 sehr viel mehr möglich als hier
immer behauptet wird. Tableless Layout für Netscape 4 geht nicht nur, es geht
sogar sehr gut!

Grüsse

Cyx23

[molily]

Hallo Cyx,

Grundsätzlich ist gegen Tabellen viel weniger einzuwenden als hier im Forum oft
zu lesen ist, es ist aber auch für Netscape 4 sehr viel mehr möglich als hier
immer behauptet wird. Tableless Layout für Netscape 4 geht nicht nur, es geht
sogar sehr gut!

Mit Verlaub, mehr als Behauptungen habe ich von deiner Seite leider nie gehört. Das hilft dem Fragenden jeweils wenig bis gar nichts.

Ich möchte Jan bitten, eine *konkrete* CSS-Umsetzung vorzustellen, sodass gemeinsam erarbeitet werden kann, wie es für Netscape 4 umgesetzt werden kann. Ich würde mich natürlich freuen, wenn du dich daran aktiv beteiligst.

Mathias

[Cyx23]

Hallo,

Grundsätzlich ist gegen Tabellen viel weniger einzuwenden als hier im Forum oft
zu lesen ist, es ist aber auch für Netscape 4 sehr viel mehr möglich als hier
immer behauptet wird. Tableless Layout für Netscape 4 geht nicht nur, es geht
sogar sehr gut!

Mit Verlaub, mehr als Behauptungen habe ich von deiner Seite leider nie gehört. Das hilft dem Fragenden jeweils wenig bis gar nichts.

ich habe hier im Forum schon öfters kleinere konkrete Beispiele gepostet,
auch zu solchen Fragen konkret geholfen, dann in letzter Zeit mehrfach auf eine
URI mit einem sehr ausführlichen Artikel dazu verwiesen.

Ich möchte Jan bitten, eine *konkrete* CSS-Umsetzung vorzustellen, sodass gemeinsam erarbeitet werden kann, wie es für Netscape 4 umgesetzt werden kann. Ich würde mich natürlich freuen, wenn du dich daran aktiv beteiligst.

Das Problem ist von mir bereits sehr umfassend erörtert worden, ich habe
ganz neue Lösungen entwickelt, und da bleiben m.E. wenig Wünsche offen.
*Konkret* umfasst das Projekt "CSS für alle Browser" auch rund 40 Beispieldateien,
davon viele zu tableless-layout!
http://www.lipfert-malik.de/webdesign/tutorial/css.html (170k)

Zugleich habe ich überlegt einen Featureartikel daraus zu erstellen, was aber
aus verschiedenen Gründen doch erstmal zu der zugängliche Präsentation unter
der genannten Adresse geführt hat.

Grüsse
Cyx23

[molily]

Hallo, Cyx,

Grundsätzlich ist gegen Tabellen viel weniger einzuwenden als hier im Forum oft zu lesen ist, es ist aber auch für Netscape 4 sehr viel mehr möglich als hier immer behauptet wird. Tableless Layout für Netscape 4 geht nicht nur, es geht sogar sehr gut!

Mit Verlaub, mehr als Behauptungen habe ich von deiner Seite leider nie gehört. Das hilft dem Fragenden jeweils wenig bis gar nichts.

ich habe hier im Forum schon öfters kleinere konkrete Beispiele gepostet, auch zu solchen Fragen konkret geholfen, dann in letzter Zeit mehrfach auf eine URI mit einem sehr ausführlichen Artikel dazu verwiesen.

Das wollte ich im Allgemeinen nicht kategorisch bezweifeln, mir ging es nur darum, dass dein Posting den Erfahrungen von Jan widersprach und du eben nicht mehr als das Gegenteil behauptet hast, was ich von dir des öfteren gelesen habe, ich wollte deshalb dieses Mal vor allem auf folgendes hinaus:

Ich möchte Jan bitten, eine *konkrete* CSS-Umsetzung vorzustellen, sodass gemeinsam erarbeitet werden kann, wie es für Netscape 4 umgesetzt werden kann. Ich würde mich natürlich freuen, wenn du dich daran aktiv beteiligst.

Das Problem ist von mir bereits sehr umfassend erörtert worden, ich habe ganz neue Lösungen entwickelt, und da bleiben m.E. wenig Wünsche offen. *Konkret* umfasst das Projekt "CSS für alle Browser" auch rund 40 Beispieldateien, davon viele zu tableless-layout!
http://www.lipfert-malik.de/webdesign/tutorial/css.html (170k)

Ja, das ist mir aufgefallen, dazu schreibe ich gerade ein umfangreiches Posting. Der Thread dazu ist leider schnell im Archiv gelandet, da ich nicht rechtzeitig fertig war; ich werde den Thread neu eröffnen, wenn die Zeit gekommen ist.
Woher soll ich wissen, dass und was du mit der Seite zu tun hast, bist du der (zumindest Co-)Autor der Seite? Du hast zwar schon öfters vorher eine solche Seite angekündigt und die Adresse auch oft verlinkt, kurz bevor und nachdem ein sich »Kris2f« nennendes Individuum die Seite hier vorgestellt hat, aber woher soll ich wissen, dass du eventuell »Kris2f« beziehungsweise Kristof Lipfert bist(*)? Hast du ein anderes Pseudonym benutzt, um die Seite vorzustellen? Da du meiner Erinnerung nach nie eine E-Mail-Adresse oder einen Realnamen beziehungsweise zumindest ein netzweit eindeutiges Pseudonym angegeben hast, verzeihe mir bitte meine Verwirrung.

Grüße,
Mathias
(*) Bitte jetzt keine Verweise auf meine Äußerungen im letzten Realname-/Identitäts-Thread zu den Problemen von »Ich bin [Name]« et cetera. ;-)

[Cyx23]

Hallo Mathias,

Woher soll ich wissen, dass und was du mit der Seite zu tun hast,

entschuldige bitte das Durcheinander, da ist natürlich ein Teil "hausgemacht".
Mir ist aber andererseits auch keine ideale Lösung für die Verbindung von Realnamen und Pseudonym eingefallen, und solange ich keinen offiziellen
Künstlernamen verwende, ist ja -erst- bei Veröffentlichung oder Impressum usw. eine solche Trennung bzw. das alter ego bedingt aufzuheben.

Falls es dir jetzt noch um *konkret* bzgl. Jans Posting ging, da sehe ich erstmal einfach den Einsatz von span, ggf. width, display, float, m.E. eigentlich zunächst kein NC4 typisches Problem, vielleicht unterschätze ich es auch, aber ich habe jetzt z.B. im genannten Artikel oder Tutorial bei dem neu hinzugekommenen Index mit <li><span>..</span><a >..</a></li> keine Tabelle für die -allerdings noch sehr einfache- Struktur eingesetzt, es ging doch um solch gleiche Abstände, also
im einfachsten Fall mit nur zwei Einträgen wäre sogar nur ein 'justify' als Beschreibung der Struktur möglich?

Grüsse

Kris2f

[goewe.com]

2. Wenn ein Layout die Aufteilun von Formularfeldern auf mehrere positionierbare Bereiche erzwingt (Bezug auf das Netscape 4.7 Layer/DIV-Objektproblem), bevorzugt ihr welche Möglichkeit?
   a) Auf Tabellenlayout zurückgreifen um Netscape 4.7 zu berücksichtigen.
   b) Netscape 4.7 "vergessen".

Danke für eure Kommentare.

Jan

NN4 und nicht-CSS-Browser braucht man nicht zu vergessen!

Also Moeglichkeit (c):

um NN4 nicht mit nebeneinander positionierten Elementen nicht zu verwirren, gibt es diverse hiding Methoden.

Beispiel einer Formular-Zeile:

<div id="pos">Titel: <input ...><span class="zero"> | </span></div>

Man muss nur noch, fuer die Browser die's verstehen, #pos entsprechend definieren
zB:
#pos { position: absolute; left:100px; top:50px; z-index:5;}

Als Trennsymbol in Text-browsern, die div nicht verstehen und vor allem fuer Sprachausgeben fuer Blinde wird " | " empfohlen.
Dieses Trennsymbol kann man (auch vor NN4) 'verstecken:
zB:
.zero { font-size:0px; }

[Jan]

Hallo,

danke für alle Kommentare und Anregungen.

So sind mir einige neue Möglichkeiten aufgefallen Problem Nr. 1 anzugehen. Die beste Lösung gibt es dort wahrscheinlich nicht, nur Pros und Contras für jede.

Problem Nr. 2 liess sich dank Christians relativ positionierten DIVs ziemlich einfach lösen.

Alles in allem bin ich zwar der Meinung, das es durchaus möglich ist (fast) jedes CSS-Layout auch für den NS4.7 umzuschreiben, werde mir aber für jedes Projekt in Zukunft vorher anhand der Zielgruppe die Frage stellen ob das noch notwendig ist. Nicht immer rechtfertigt ein Marktanteil von 1% (in bestimmten Zielgruppen) einen zusätzlichen Arbeitsaufwand von 20-40%.

Viele Grüsse
Jan