Nachteile Tabellenlayout

[Tim]

Hallo zusammen,

ich hatte gestern eine Diskussion mit einer Freundin, die der Meinung war, dass Tabellenlayout immer noch die beste Möglichkeit sei um eine vernünftige Anordnung der versch. Designelemente einer Homepage hinzubekommen.

Dieser Meinung bin ich nicht. Mir waren auch spontan folgende Argumente eingefallen:

• Einschränkungen bei Änderungen des Layouts (mit <div>s ist man da freier als mit Tabellen, da man sie z.B. einfacher woanders positionieren kann wenn sich mal das Layout ändert)

• Für mich aufwendiger zu 'programmieren'

• Die Ladezeit, bzw. die Zeit für die Darstellung im Browser soll angeblich höher sein, da der Browser zuerst die gesamte Tabelle lädt und dann alles auf einmal darstellt (wenn man z.B. die gesamte Seite in einer Tabelle hat).

FRAGE: verhält sich der Browser nicht analog wenn ich eine gesamte Seite in einen <div> packe?

Mich würde nun interessieren was denn Eure Meinung zu Tabellendesign ist.
Vielleicht habt Ihr noch ein paar schlagende Argumente gegen Tabellendesign damit ich meine Bekannte endgültig davon überzeugen kann es sein zu lassen.

Es grüsst Euch aus Stuttgart
Tim

[Elya]

Hallo Tim,

ich hatte gestern eine Diskussion mit einer Freundin, die der Meinung war, dass Tabellenlayout immer noch die beste Möglichkeit sei um eine vernünftige Anordnung der versch. Designelemente einer Homepage hinzubekommen.

komisch. Ich auch ;-)

• Einschränkungen bei Änderungen des Layouts (mit <div>s ist man da freier als mit Tabellen, da man sie z.B. einfacher woanders positionieren kann wenn sich mal das Layout ändert)

Zustimmung. Manche Dinge, die "man" gerne hätte oder die mit Tabellenlayout ganz einfach gehen, sind mit CSS jedoch nur auf Umwegen zu realisieren. Stichwort vertikale Zentrierung, Footer usw.

• Für mich aufwendiger zu 'programmieren'

Kann ich nicht behaupten. Bis ich alles browserübergreifend, ggf. mit sämtlichen Hacks für ältere Browser aufgebaut habe, brauche ich z.Zt. noch _mindestens_ so lange wie für ein traditionelles Tabellen- oder Frameslayout. Ich rede nicht von einem ganz neuen Design, wo Du das CSS und seine Möglichkeiten schon im Hinterkopf hast, sondern von der Umsetzung eines klassischen, komplexen "Framedesigns" in eine reine CSS-Lösung. Das macht Spaß ;-)

Vielleicht habt Ihr noch ein paar schlagende Argumente gegen Tabellendesign damit ich meine Bekannte endgültig davon überzeugen kann es sein zu lassen.

Außer dem Vorwurf des semantischen Mißbrauchs [1], der Suchmaschinenfeindlichkeit (aber auch Tabellenseiten sollen in Suchmaschinen schon gesichtet worden sein) und der Schwierigkeit, nachträglich etwas zu ändern oder einzupflegen ist es schwer, _dagegen_ zu argumentieren.

_Für_ einer sauber strukturierten (X)HTML-Seite mit purem CSS-Designs allerdings spricht einiges (was Du schon weißt). Ich erfreue mich schon allein an dem schlanken, übersichtlichen Code. Templates für CMS zu bauen, die aus verschiedenen Modulen bestehen, ist ein Kinderspiel geworden, auch der Programmierer hat Freude. Oh ja: da ist noch die Barrierefreiheit, und das ist wirklich ein schlagendes Argument. Und die medienübergreifende Produktion. Es ist sehr befriedigend, mit einem so schlanken Code komplexe Seiten aufzubauen. Aber: _einfacher_ ist es sicher nicht. Vielleicht in einiger Zeit, wenn Hacks minimiert werden können und ich mehr Routine habe.

Ich mache hier mal den Advocatus D. und bin gespannt auf weitere Meinungen.

Als amüsante Lektüre dazu noch etwas Jeffrey Z.: http://www.zeldman.com/daily/0304e.shtml sowie http://www.decloak.com/Dev/CSSTables/CSS_Tables_01.aspx

So, und jetzt habe ich schon wieder die Bahn um 8.02 Uhr verpaßt. Ich seh Euch im Büro.

Gruß aus Köln-Ehrenfeld,

Elya

[1]aber seien wir mal ganz ehrlich: das ist ein recht elitäres Argument, das im Alltag wenig Bedeutung hat.

[Tim]

Hallo Elya,

erstmal danke für Deine auführliche Antwort und sorry, dass Du nun wegen mir die Bahn verpasst hast. Du hast aber sicherlich Gleitzeit;-)
Du hast sehr interessante Sachen erwähnt worüber, wie Du durch meine weiteren Fragen sicherlich erkennen wirst, ich mehr wissen möchte.

komisch. Ich auch ;-)

Hm, ich glaube nicht dass ich mich mit Dir unterhalten habe;-)

Zustimmung. Manche Dinge, die "man" gerne hätte oder die mit Tabellenlayout ganz einfach gehen, sind mit CSS jedoch nur auf Umwegen zu realisieren. Stichwort vertikale Zentrierung, Footer usw.

Ja, das mit der Zentrierung stimmt. Aber was genau meinst Du mit Footer?

Kann ich nicht behaupten. Bis ich alles browserübergreifend, ggf. mit sämtlichen Hacks für ältere Browser aufgebaut habe, brauche ich z.Zt. noch _mindestens_ so lange wie für ein traditionelles Tabellen- oder Frameslayout. Ich rede nicht von einem ganz neuen Design, wo Du das CSS und seine Möglichkeiten schon im Hinterkopf hast, sondern von der Umsetzung eines klassischen, komplexen "Framedesigns" in eine reine CSS-Lösung. Das macht Spaß ;-)

OK, ich hab bisher noch nie richtig Tabellendesign eingesetzt. Deshalb fällt mir ein Design mit <div>s leichter.

Bei der Planung einer Site gehe ich folgendermassen vor: ich identifiziere einzelne "Bausteine", wie z.B. die Navigation, evtl. ein kleines Warenkorbfenster, Info-Fenster, Kopfzeile, Fusszeile...., und dann packe ich jeden dieser Bausteine in einen <div> mit einer bestimmten "id", den ich dann frei positionieren kann. Vorteil ist auch, dass ich durch die Vergabe der id nacher mittels CSS enorme Freiheiten habe was die gezielte Formatierung innerhalb einzelner Bereiche habe.

Außer dem Vorwurf des semantischen Mißbrauchs [1], der Suchmaschinenfeindlichkeit (aber auch Tabellenseiten sollen in Suchmaschinen schon gesichtet worden sein) und der Schwierigkeit, nachträglich etwas zu ändern oder einzupflegen ist es schwer, _dagegen_ zu argumentieren.

Das mit der Suchmaschinenfeindlichkeit wusste ich jetzt noch nicht. Kannst Du das näher erläutern?

_Für_ einer sauber strukturierten (X)HTML-Seite mit purem CSS-Designs allerdings spricht einiges (was Du schon weißt).

»»
Ich erstelle die Seiten eigentlich immer als "transitional" (natürlich valide);-). Da spricht ja eigentlich nichts dagegen, oder?

Ich erfreue mich schon allein an dem schlanken, übersichtlichen Code. Templates für CMS zu bauen, die aus verschiedenen Modulen bestehen, ist ein Kinderspiel geworden, auch der Programmierer hat Freude.

»»
CMS ist auch für mich eine interessante Sache. Leider habe ich noch nicht viel Ahnung darüber. Gibt es evtl. auch was kostenloses in dieser Richtung womit man ein wenig "spielen" kann?

Zum Schluss noch eine (persönliche) Frage (musst auch nicht darauf antworten wenn es Dir zu persönlich ist):
Arbeitest Du in der Webdesign Branche? Als was?

Gruss aus Stuttgart
Tim

[chlori]

Hi

OK, ich hab bisher noch nie richtig Tabellendesign eingesetzt.
Deshalb fällt mir ein Design mit <div>s leichter.

Es hört sich so an, als packst du alles in Divs... Stimmt das?
Warum?

[...] dann packe ich jeden dieser Bausteine in einen <div>

Tatsächlich.... Warum?

Das mit der Suchmaschinenfeindlichkeit wusste ich jetzt
noch nicht. Kannst Du das näher erläutern?

Mit Tabellen hast du viel mehr HTML-Code. Suchmaschinen
werten u.a. nach Relevanz. Wenn auf einer Tennis-Seite 10%
der Wörter "Tennis" sind, dann ist der Begriff "Tennis"
relevanter als wenn das Wort nur 1% des Textes (Codes) ist.
Weniger Code => Höhere Relevanz des Textes

Auch kannst du mit CSS die Reihenfolge frei wählen: Das
oberste auf der angezeigten Seite ist nicht zwingend das
oberste im Quelltext. Suchmaschinen werten vorallem die
Inhalte, die zuerst "gelesen" werden, ignorieren aber dein
CSS.

Ich erstelle die Seiten eigentlich immer als "transitional"

Schon mal von strict gehört?

Gruss
chlori

[dey]

Moin moin Chlori,

Auch kannst du mit CSS die Reihenfolge frei wählen: Das
oberste auf der angezeigten Seite ist nicht zwingend das
oberste im Quelltext. Suchmaschinen werten vorallem die
Inhalte, die zuerst "gelesen" werden, ignorieren aber dein
CSS.

Wie du vielleicht gesehen beschäftige ich mich weiter oben in einem Thread mit genau dem Thema wie ich von Table-Design weg hin zu Div-Desugn komme und da habe ich zu dem angefügten Text 2 Fragen:

1.
Was bestimmt die Reihenfolge

2.
Wie verhalten sich verschachtelte Divs a'la

<div id="1">
  <div id="2">
  </div>
</div>

in Bezug auf Position relativ und absolut

bydey

[chlori]

Hi

Wie du vielleicht gesehen beschäftige ich mich weiter
oben in einem Thread mit genau dem Thema wie ich von
Table-Design weg hin zu Div-Desugn komme

Vergiss das mit dem Div-Design. Du suchst nach CSS-Layout.
Divs sind *nicht* der Ersatz für Tabellen!

Was bestimmt die Reihenfolge

Reihenfolge: Von oben nach unten in deinem HTML.

Wie verhalten sich verschachtelte Divs a'la

<div id="1">
  <div id="2">
  </div>
</div>

in Bezug auf Position relativ und absolut

Wie erwartet. Lies über relative und absolute nach.
Ist sehr einfach zu verstehen.

Aber denke an die Antwort oben wegen CSS-Layout statt
Div-Design:
Verwende nur ein Div wenn du eines brauchst. Du kannst andere
Tags auch positionieren. zB Bilder kannst du direkt positionieren:
<img src="" style="position:absolute; left:0; top:0;" [...]>

Gruss
chlori

[Tim]

Vergiss das mit dem Div-Design. Du suchst nach CSS-Layout.
Divs sind *nicht* der Ersatz für Tabellen!

Nein, bloss nicht vergessen...das ist wichtig.
divs sind natürlich kein Ersatz für Tabellen. Es hilft aber die Tabellen nicht zu mißbrauchen.

Aber denke an die Antwort oben wegen CSS-Layout statt
Div-Design:

Das eine hat mit dem anderen doch gar nichts zu tun.
Divs verwendet man doch um Bereiche zu strukturieren.

Verwende nur ein Div wenn du eines brauchst. Du kannst andere
Tags auch positionieren. zB Bilder kannst du direkt positionieren:
<img src="" style="position:absolute; left:0; top:0;" [...]>

Jetz stell Dir mal vor, Du hast z.B. eine Überschrift zu einem Bereich (z.B. Infobox), ein bild und dazu noch einige Absätze Text (<p>s) die alle zusammen zu einer Einheit gehören, z.B. zur Infobox. Möchtest Du dann jedes einzelne Element absolut positionieren?
Ganz sicher nicht. Man umschließt die Elemente mit einem <div> und positioniert diesen dann.
 Tim

[chlori]

Hi

Vergiss das mit dem Div-Design. Du suchst nach CSS-Layout.
Divs sind *nicht* der Ersatz für Tabellen!

Nein, bloss nicht vergessen...das ist wichtig.
divs sind natürlich kein Ersatz für Tabellen. Es hilft aber
die Tabellen nicht zu mißbrauchen.

Natürlich. Ich bin neu bei SelfHTML, aber irgendwie habe
ich das Gefühl, dass jemand in Deutschland das Div-Design
predigt. Klar braucht man auch Divs, aber man braucht viel
mehr <p>s, warum nicht <p>-Design nennen?

Viele Seiten, die ich gesehen habe von SelfHTML-Lesern haben
alles mögliche in Divs gepackt ohne sichtbaren Grund....

Verwende nur ein Div wenn du eines brauchst.

Jetz stell Dir mal vor [bla bla]. Möchtest Du dann jedes
einzelne Element absolut positionieren?

Verwende nur ein Div wenn du eines brauchst.

Gruss
chlori

[Tim]

Hi

Natürlich. Ich bin neu bei SelfHTML, aber irgendwie habe
ich das Gefühl, dass jemand in Deutschland das Div-Design
predigt. Klar braucht man auch Divs, aber man braucht viel
mehr <p>s, warum nicht <p>-Design nennen?

Das hat nichts mit predigen zu tun. Es geht nur darum die Tags dafür zu verwenden wofür sie bestimmt sind. Tabellen sind nun mal nicht dafür bestimmt Seitenelemente anzuordnen (Seiten zu designen) und <p>-Tags (p wie paragraph - Absatz) sind nun mal Textcontainer. In einer <td>kann mann genauso gut <p> verwenden. Ebenso kann ich ein <p> Tag innerhalb eines divs weglassen (mach ich aber nicht).
<div>s verwendet man halt wie gesagt zur Gruppierung.

Viele Seiten, die ich gesehen habe von SelfHTML-Lesern haben
alles mögliche in Divs gepackt ohne sichtbaren Grund....

Das kann sein, kann ich nicht beurteilen, da ichs nicht gesehen habe. Man kann sicherlich auch mit <divs> unfug treiben.

Verwende nur ein Div wenn du eines brauchst.

Das sowieso.
Gruss
Tim

[chlori]

Hi

Tabellen sind nun mal nicht dafür bestimmt Seitenelemente
anzuordnen (Seiten zu designen)

Aha, das sind News! :)

Viele Seiten, die ich gesehen habe von SelfHTML-Lesern haben
alles mögliche in Divs gepackt ohne sichtbaren Grund....

Das kann sein, kann ich nicht beurteilen, da ichs nicht
gesehen habe. Man kann sicherlich auch mit <divs> unfug
treiben.

Wenn man sagt "Ersetze dein Tabellen-Layout durch Div-Layout"
dann denken die Leute genau gleich weiter und versuchen genau
den gleichen Effekt mit Divs zu erreichen wie 1996 mit Tabellen-
Zellen. Und verstehen das Web nie.

Wieso nicht das ganze CSS-Layout nennen, wie es der Rest der
Welt macht?

Gruss
chlori

[Tim]

Hi

Tabellen sind nun mal nicht dafür bestimmt Seitenelemente
anzuordnen (Seiten zu designen)

Aha, das sind News! :)

für mich nicht. Mir war schon immer klar, dass man eine ganze Seite nicht in eine Tabelle packt, in die man dann noch ne Tabelle einbaut wo dann die Navigation reinkommt, und daneben noch ne tabelle wo dann der Content steht.

Wenn man sagt "Ersetze dein Tabellen-Layout durch Div-Layout"
dann denken die Leute genau gleich weiter und versuchen genau
den gleichen Effekt mit Divs zu erreichen wie 1996 mit Tabellen-
Zellen. Und verstehen das Web nie.

Es ist doch wohl klar, dass man nicht alle Tabellen ersetzen soll. Inhalte wie z.B. irgendwelche Produktübersichten sollten weiterhin in Tabellen angezeigt werden.

Wieso nicht das ganze CSS-Layout nennen, wie es der Rest der
Welt macht?

CSS ist Layout. Es heisst doch, man solle Layout (Farben, Position, Schriften...) von der Struktur trennen.
Wer es ausprobiert wird sehen, dass die gesamte Page viel flexibler bzgl. Veränderungen im Design und viel wartungsfreundlicher wird.
Ich gebe zu, dass es ein gewisser Einlernaufwand benötigt wenn man bisher nur mit Tabellen designt hat. Aber es lohnt sich.

TIM

[chlori]

Hi

Aha, das sind News! :)

für mich nicht. Mir war schon immer klar, dass man eine
ganze Seite nicht in eine Tabelle packt

Was hast du 1998 gemacht bei der lausigen CSS-Unterstützung?
Damals habe ich Tabellen benutzt für Layout, aber seit
langem nicht mehr.

CSS ist Layout.

Genau! Tabellen werden aber immernoch für das Layout missbraucht.
Mit CSS wäre es richtig: Deshalb CSS-Layout.

Gruss
chlori

[Tim]

Hi

Was hast du 1998 gemacht bei der lausigen CSS-Unterstützung?
Damals habe ich Tabellen benutzt für Layout, aber seit
langem nicht mehr.

Damals hab ich mit Webdesign noch nichts gemacht. Zu der Zeit war es sicherlich auch legitim.

CSS ist Layout.

Genau! Tabellen werden aber immernoch für das Layout missbraucht.
Mit CSS wäre es richtig: Deshalb CSS-Layout.

Genau.
Also sind wir doch der gleichen Meinung wie bereits oben erwähnt. Wir haben lediglich aneinander vorgei geredet.

Gruss
Tim

[Tim]

Hallo

OK, ich hab bisher noch nie richtig Tabellendesign eingesetzt.
Deshalb fällt mir ein Design mit <div>s leichter.

Es hört sich so an, als packst du alles in Divs... Stimmt das?
Warum?

weil ich dadurch flexibler bin. wenn mir mal einfällt, dass ich den Warenkorb nicht links oben, sondern rechts oben haben will, ändere ich das an einer Stelle. Im CSS.

Mit Tabellen hast du viel mehr HTML-Code. Suchmaschinen
werten u.a. nach Relevanz. Wenn auf einer Tennis-Seite 10%
der Wörter "Tennis" sind, dann ist der Begriff "Tennis"
relevanter als wenn das Wort nur 1% des Textes (Codes) ist.
Weniger Code => Höhere Relevanz des Textes

Das leuchtet ein. Guter Punkt.

Ich erstelle die Seiten eigentlich immer als "transitional"

Schon mal von strict gehört?

Höre ich da einen ironischen Unterton heraus?;-)
Habe ich schon. Ich habe auch schon von XHTML gehört.
Warum sollte ich sie aber als "strict" erstellen wenn es mit "transitional" auch tut?

Gruss

TIm

[Struppi]

weil ich dadurch flexibler bin. wenn mir mal einfällt, dass ich den Warenkorb nicht links oben, sondern rechts oben haben will, ändere ich das an einer Stelle. Im CSS.

Dazu brauchst du aber kein DIV

<img id="warenkorb" src="wk.gif">

läßt sich genauso einfach positionieren.
#warenkorb{
position:absolute;

}

Höre ich da einen ironischen Unterton heraus?;-)
Habe ich schon. Ich habe auch schon von XHTML gehört.
Warum sollte ich sie aber als "strict" erstellen wenn es mit "transitional" auch tut?

Naja, das macht gerade auf dem IE einen riesigen Unterschied, such mal nach "boxmodel Bug".

Struppi.

[Tim]

weil ich dadurch flexibler bin. wenn mir mal einfällt, dass ich den Warenkorb nicht links oben, sondern rechts oben haben will, ändere ich das an einer Stelle. Im CSS.

Dazu brauchst du aber kein DIV

<img id="warenkorb" src="wk.gif">

läßt sich genauso einfach positionieren.

Und wo bleibt die Überschrift "Warenkorb" und die Anzahl der Artikel sowie die Gesamtsumme die noch angezeigt werden soll?
Da umschließe ich das ganze lieber mit einem <div> und positioniere diesen.

Naja, das macht gerade auf dem IE einen riesigen Unterschied, such mal nach "boxmodel Bug".

kann man umgehen.

Tim

[at]

Hallo.

Warum sollte ich sie aber als "strict" erstellen wenn es mit "transitional" auch tut?

Naja, das macht gerade auf dem IE einen riesigen Unterschied, such mal nach "boxmodel Bug".

Das halte ich für ein Gerücht.
MfG, at

[Struppi]

Naja, das macht gerade auf dem IE einen riesigen Unterschied, such mal nach "boxmodel Bug".

Das halte ich für ein Gerücht.

Strict Mode: http://home.arcor.de/struebig/js/test/strict.htm
Quirks Mode:  [http://home.arcor.de/struebig/js/test/quirks.htm]

Struppi.

[at]

Hallo.

Strict Mode: http://home.arcor.de/struebig/js/test/strict.htm
Quirks Mode:  [http://home.arcor.de/struebig/js/test/quirks.htm]

Du verwechselst Grundsätzliches:
"Strict" ist der Gegenpart zu "Transtitional"; "Quirks" der zu "Compliant".
MfG, at

[Struppi]

Hallo at

Hallo.

Strict Mode: http://home.arcor.de/struebig/js/test/strict.htm
Quirks Mode:  http://home.arcor.de/struebig/js/test/quirks.htm

Du verwechselst Grundsätzliches:
"Strict" ist der Gegenpart zu "Transtitional"; "Quirks" der zu "Compliant".

ok, dein Punkt, aber die Frage war:

Warum sollte ich sie aber als "strict" erstellen wenn es mit "transitional" auch tut?

Und die beiden Seiten zeigen den Unterschied zwischen transitional und strict im IE

Struppi.

[at]

Hallo.

ok, dein Punkt, aber die Frage war:

Warum sollte ich sie aber als "strict" erstellen wenn es mit "transitional" auch tut?

Und die beiden Seiten zeigen den Unterschied zwischen transitional und strict im IE

Tun sie das denn auch im Compliant-Mode?
MfG, at

[Struppi]

Hallo at

Hallo.

ok, dein Punkt, aber die Frage war:

Warum sollte ich sie aber als "strict" erstellen wenn es mit "transitional" auch tut?

Und die beiden Seiten zeigen den Unterschied zwischen transitional und strict im IE

Tun sie das denn auch im Compliant-Mode?

nein.
du hast recht.

Struppi.

[Alain]

Hallo.

Und die beiden Seiten zeigen den Unterschied zwischen transitional und strict im IE

ich seh keinen unterschied im IE5.5
gruss
Alain

[Struppi]

Und die beiden Seiten zeigen den Unterschied zwischen transitional und strict im IE

ich seh keinen unterschied im IE5.5

In http://home.arcor.de/struebig/js/test/strict.htm ist die Box 20px tiefer als in
http://home.arcor.de/struebig/js/test/quirks.htm wegen dem Boxmodell bug, der aber nur Transtitional mode Auftritt und nicht im Compliant.

D.h. wenn im Quirks code am Anfang:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">

steht, sind beide wieder gleich.

Struppi.

[Wilhelm Turtschan]

habe d'ehre

Mit Tabellen hast du viel mehr HTML-Code.

Interessante Aussage, die ich aber leider nicht nachvollziehen kann.

Eine Artikelpreisliste habe ich heute auf eine Darstellung ohne Tabellen geaendert, da die einzelnen Position nicht in Google gefunden werden, obwohl sonst jeder Schmonz der Seite in der SM auftaucht..

Bisherige Tabellenzeile:

<tr>
<td>Primepower PW250N</td>
<td>2 x CPU 1,1GHz 2GB Hauptspeicher</td>
<td>Preis a.A.</td>
<tr>

Neue Definition mit float:left fuer den <h3> und float:right fuer die Klasse "aprs"

<div class="artikelsatz">
<h3>Primepower PW250N</h3>
<p class="aprs">Preis a.A.</p>
<p class="afco">2 x CPU 1,1GHz 2GB Hauptspeicher</p>
</div>

Ich sehe eindeutig mehr Code in der "Baeehh-Tabellen sind boese"-Version. Falls Du jetzt noch die <table></table> ins Spiel bringen willst, fuer die Div-Version brauchst Du natuerlich auch die Styledefinitionen.

Fazit: Nicht immer ist das Althergebrachte schlecht, nur weil es nicht mehr State-of-Art ist. Natuerlich wuerde ich heute nie mehr Raender mit verschachtelten Tabellen machen. Wenn Du alledings zweispaltige Texte mit skalierbaren Breiten willst, stoesst Du mit float und einer vorgeschriebenen Breite fuer das float-Element schnell an die Grenzen der grauen Theorie, von der Rumpfriemelei fuer diverse Browser mal abgesehen.

man liest sich
Wilhelm

[Struppi]

Eine Artikelpreisliste habe ich heute auf eine Darstellung ohne Tabellen geaendert, da die einzelnen Position nicht in Google gefunden werden, obwohl sonst jeder Schmonz der Seite in der SM auftaucht..

Ich vermute mal, das es eine Tabelle von Produkten ist. Dann musst du auch eine Tabelle verwenden.

Bisherige Tabellenzeile:

<tr>
<td>Primepower PW250N</td>
<td>2 x CPU 1,1GHz 2GB Hauptspeicher</td>
<td>Preis a.A.</td>
<tr>

Neue Definition mit float:left fuer den <h3> und float:right fuer die Klasse "aprs"

<div class="artikelsatz">
<h3>Primepower PW250N</h3>
<p class="aprs">Preis a.A.</p>
<p class="afco">2 x CPU 1,1GHz 2GB Hauptspeicher</p>
</div>

Das ist der Versuch eine Tabelle nachzubauen, das kann nicht gut gehen.

Fazit: Nicht immer ist das Althergebrachte schlecht, nur weil es nicht mehr State-of-Art ist. Natuerlich wuerde ich heute nie mehr Raender mit verschachtelten Tabellen machen. Wenn Du alledings zweispaltige Texte mit skalierbaren Breiten willst, stoesst Du mit float und einer vorgeschriebenen Breite fuer das float-Element schnell an die Grenzen der grauen Theorie, von der Rumpfriemelei fuer diverse Browser mal abgesehen.

Du willst eine Tabelle, dann benutze eine. Eine Tabelle ist ja nichts althergebrachtes, sondern durchaus State of Art, aber eben für Tabellendaten und nicht um Objekte anzuordnen.

Struppi.

[Wilhelm Turtschan]

habe d'ehre

Ich vermute mal, das es eine Tabelle von Produkten ist.

Jein, plus Konfigurationsbeschreibungen etc.
Um das "Inwort" Semantik zu bemuehen: Man koennte die Informationen auch blockweise darstellen.

Dann musst du auch eine Tabelle verwenden.

Nein, muessen muss ich nur sterben. :-)

Du willst eine Tabelle, dann benutze eine. Eine Tabelle ist ja nichts althergebrachtes, sondern durchaus State of Art, aber eben für Tabellendaten und nicht um Objekte anzuordnen.

Ist ja nur ein Versuch Google zu ueberzeugen, da der Kunde ein bisschen rummosert. :-)
Mal davon abgesehen steht in der Spalte fuer die Beschreibung schon noch etliches mehr.

Mal abwarten, es ist durch Umbennung von zwei Scripten in 30 Sekunden wieder auf Tabelle umgestellt.

man liest sich
Wilhelm

[Swen Wacker]

Moin,

Nein, muessen muss ich nur sterben. :-)

Ich muss manchmal auch aufs Klo :-)

Viele Grüße

Swen

[Wilhelm Turtschan]

habe d'ehre

Nein, muessen muss ich nur sterben. :-)
Ich muss manchmal auch aufs Klo :-)

Du musst nicht, es ist alleine Deine freie Entscheidung was Du Deinen Mitmenschen zumuten willst. *g*

man liest sich
Wilhelm

[Tim]

Für Produktlisten sind Tabellen ja auch in Ordnung und vorgesehen.
Es ist ja nicht verboten Tabellen einzusetzen.

Ich finde, dass sich Tabellen bei Produktlisten eigentlich schon anbieten. In diesem Fall kein Mißbrauch.

Gruss
Tim

[Wilhelm Turtschan]

habe d'ehre

Der Kern war

Mit Tabellen hast du viel mehr HTML-Code

und nicht ob ich meine Daten jetzt so oder so darstelle. ansonsten [pref:t=81349&m=473481]

man liest sich
Wilhelm

[Struppi]

Der Kern war

Mit Tabellen hast du viel mehr HTML-Code

Was ja auch stimmt, solange man nicht versucht mit CSS eine Tabelle nachzubauen.

Struppi.

[Ingo Turski]

Hi,

bei diesem Beispiel macht die Umsetzung ja auch keinen Sinn - nichtmal für Google.
Warum nicht
            <th>Primepower PW250N</th>
oder
            <td><h3>Primepower PW250N</h3></td>
?

freundliche Grüße
Ingo

[Wilhelm Turtschan]

habe d'ehre

<td><h3>Primepower PW250N</h3></td>

Exakt so hatte ich es und werde es auch wieder so schalten. Kunden koennen halt nervig sein, wenn sie um 8.00h an Google haengen, ihre Produkte suchen und nichts finden und dann um 8:30h bei mir anbimmeln und meckern. Der Einwand, dass Verlinkungen bei Partnern rankingmaessig was bringen verhallt leider ungehoert.

man liest sich
Wilhelm

[chlori]

Hi

Mit Tabellen hast du viel mehr HTML-Code.

Interessante Aussage, die ich aber leider nicht
nachvollziehen kann.

Ok, deutlicher:
Mit gut gecodeten Tabellen für Layout hast du viel
mehr HTML-Code wie mit gut eingesetztem CSS.

Eine Artikelpreisliste habe ich heute auf eine Darstellung
ohne Tabellen geaendert,

Tabellen sind für tabellarische Daten gedacht. Dafür sind
sie auch geeignet und sollten auch verwendet werden.

fuer die Div-Version brauchst Du natuerlich auch die
Styledefinitionen.

Die sind im externen Stylesheet und werden gecached, also
einmal geladen. Auch stört dieser Code (CSS) die Suchmaschinen
nicht.

Fazit: Nicht immer ist das Althergebrachte schlecht,
nur weil es nicht mehr State-of-Art ist.

Nein, Fazit: CSS muss sinnvoll eingesetzt werden um deutlich
besser zu sein als Tabellen für Layout sein können.

Gruss
chlori

[Tim]

Na also,

Deinem Post nach zu urteilen reden sind wir doch einer Meinung, wir reden wahrscheinlich nur aneinander vorbei;-)

[Struppi]

Deinem Post nach zu urteilen reden sind wir doch einer Meinung, wir reden wahrscheinlich nur aneinander vorbei;-)

Das würde ich aber auch so sehen.

Struppi.

[at]

Hallo.

<div class="artikelsatz">
<h3>Primepower PW250N</h3>
<p class="aprs">Preis a.A.</p>
<p class="afco">2 x CPU 1,1GHz 2GB Hauptspeicher</p>
</div>

Mit einer <dl> geht es auch kürzer. Bei mehreren Artikeln auch kürzer als mit einer Tabelle.
Wenn jedoch die angegebenen Daten verglichen werden sollen, ist ja gegen <table> nichts einzuwenden. -- Ich weiß, das war nicht der Punkt, auf den du hinaus wolltest ...
MfG, at

[molily]

Hallo,

Mit Tabellen hast du viel mehr HTML-Code. Suchmaschinen
werten u.a. nach Relevanz. Wenn auf einer Tennis-Seite 10%
der Wörter "Tennis" sind, dann ist der Begriff "Tennis"
relevanter als wenn das Wort nur 1% des Textes (Codes) ist.
Weniger Code => Höhere Relevanz des Textes

Sind das Vermutungen, die auf zufälligen Erfahrungen basieren, die man mit dieser Theorie erklären könnte, ohne andere Erklärungen falsifiziert zu haben, oder gibt es diesbezüglich Untersuchungen, die mit halbwegs wissenschaftlichen Methoden arbeiten und die für die Sinnhaftigkeit einer solchen Erklärung sprechen? Solange ersteres zutrifft, ist eine solche Aussage strenggenommen nicht mehr als ein Mythos.

Mathias

[Ingo Turski]

Hi,

ist eine solche Aussage strenggenommen nicht mehr als ein Mythos.

und vermutlich ein zu widerlegender.
So habe ich gerade mal nach ein paar HTML-Tags und -Attributen gegoogled und (wie zu erwarten) festgestellt, daß nur Treffer ausgegeben werden, in denen diese Keywords auch als Text von einem Browser angezeigt werden. Gebe ich hingegen ein paar im Text befindliche Wörter einer Seite zusammen mit einem hier enthaltenen HTML-Tag ein, wird die Seite nicht gelistet.
Interessant fand ich übrigens folgenden Treffer: http://www.rechtliches.de/winkelschreiber/blog.pl
Diese Seite ist kein HTML und wird vermutlich auch nicht als solches ausgeliefert. Daher werden der enthaltene HTML-Code vom Browser angezeigt und auch von Google als Textinhalt berücksichtigt.
Ich unterstelle Google daher einmal soviel intelligente Programmierung, daß "echte" HTML-Formatierungen vor einer Aufbereitung für den Index herausgefiltert werden und somit keine Rolle mehr spielen.

freundliche Grüße
Ingo

[molily]

Hallo,

ist eine solche Aussage strenggenommen nicht mehr als ein Mythos.
und vermutlich ein zu widerlegender.
So habe ich gerade mal nach ein paar HTML-Tags und -Attributen gegoogled und (wie zu erwarten) festgestellt, daß nur Treffer ausgegeben werden, in denen diese Keywords auch als Text von einem Browser angezeigt werden. Gebe ich hingegen ein paar im Text befindliche Wörter einer Seite zusammen mit einem hier enthaltenen HTML-Tag ein, wird die Seite nicht gelistet.

Kann es sein, dass du etwas völlig anderes ansprichst? Natürlich bezieht Google das Markup eines HTML-Dokument selbst nicht in die Suche im dem Sinne ein, als der Code über die Suche findbar ist, sondern nur den Text des Dokuments. Wenn man z.B. <html lang="de"> in einem HTML-Dokument notiert, ist das Dokument freilich noch längst nicht unter den Suchbegriffen »html lang de« zu finden.

Die Frage ist, ob der Divisor bei der Errechnung der Keyword-Dichte die Länge des jeweiligen gesamten HTML-Codes, nicht die Länge des jeweiligen natürlichsprachigen Gesamttextes ist. Sprich, die Frage ist, ob das Verhältnis zwischen Markup (Rechnersprache) und natürlicher Sprache (und die ist suchrelevant) in einem Dokument Auswirkungen darauf hat.
Ein Beispiel: Bei schlechter CSS-Nutzung und entsprechendem nicht rationalisiertem Markup (hunderte font-Tags, für jede Kleinigkeit verschachtelte Tabellen usw.) kommt auf vergleichsweise wenig natürlichsprachigen Text vergleichsweise viel HTML-Markup (z.B. <p><font color="black"><font face="Arial,sans-serif">wort suchbegriff wort</font></font></p>). Bei CSS-Nutzung muss nicht soviel Markup im Dokument untergebracht werden, weil dieselben Formatierungen über zentrale Styleregeln gelöst werden (z.B. <p>bla suchbegriff bla</p>). Dementsprechend schlank ist das Dokument im Vergleich zu einem Dokument, dass denselben Inhalt enthält, zudem aber wie beschrieben viele font-Tags usw.

chlori hat nun behauptet, dass Google nicht den reinen Nettotext zur Berechnung der Keyword-Dichte verwendet - in beiden Beispielfällen »bla suchbegriff bla«, also ganz simpel zur Veranschaulichung 11 Zeichen geteilt durch 19 gleich 58% - sondern von der Länge des gesamten HTML-Code ausgeht.
Das wäre dann bei <p>bla suchbegriff bla</p> Pi mal Daumen 11 / 26 = 42%. Und bei <p><font color="black"><font face="Arial,sans-serif">wort suchbegriff wort</font></font></p> nur 11 / 92 = 12%. chlori sagt, dass Google den Anteil des Gesamtcodes im Dokument im Verhältnis zum reinen suchrelevanten Text für diese statistischen Berechnungen einbezieht. Die These ist, dass von zwei Dokumenten, die exakt denselben Textinhalt haben mit exakt derselben semantischen Auszeichnung, das eine aber zusätzlich (semantisch nicht relevantes) Markup enthält, dasjenige Dokument von Google als wichtiger bewertet wird, welches den Inhalt mit möglichst (quantitativ) wenig HTML auszeichnet. Wenn diese Annahmen stimmten und die so berechnete Keyword-Dichte von Bedeutung für den Rang wäre, hätte ein Dokument mit <p><font color="black"><font face="Arial,sans-serif">wort suchbegriff wort</font></font></p> also schlechtere Karten bei einer Suche nach »suchbegriff« als ein Dokument mit <p>bla suchbegriff bla</p>, weil 12% gegen 42% Keyword-Dichte stünde (vereinfacht).

Ich unterstelle Google daher einmal soviel intelligente Programmierung, daß "echte" HTML-Formatierungen vor einer Aufbereitung für den Index herausgefiltert werden und somit keine Rolle mehr spielen.

Dass der Code selbst nicht durchsuchbar ist, ist unbestritten, die Frage ist eben, ob auch zur Berechnung der Keyword-Dichte der Code vorher entfernt wird oder ob in die Berechnung einfließt, wieviel der HTML-Code selbst vom Dokument ausmacht. Meine Meinung ist dazu, dass diese Vorstellung widersinnig ist. Ich kenne weder Untersuchungen, die eine solche Annahme rechtfertigen, noch Gründe, wieso eine Suchmaschine so vorgehen sollte.

Mathias

[Ingo Turski]

Hi,

Kann es sein, dass du etwas völlig anderes ansprichst?

Ja und nein...

Die Frage ist, ob der Divisor bei der Errechnung der Keyword-Dichte die Länge des jeweiligen gesamten HTML-Codes, nicht die Länge des jeweiligen natürlichsprachigen Gesamttextes ist.

Gerade der von mir angesprochene Treffer: http://www.rechtliches.de/winkelschreiber/blog.pl läßt mich vermuten, daß Google einen sehr intelligenten Algorythmus verwendet, der nicht bloß die HTML-Tags entfernt, sondern ein Dokument auf den _sichtbaren_ Inhalt reduziert. Programmtechnisch halte ich es für wenig sinnvoll, dann noch mit dem Originaldokument weiter zu arbeiten und ich unterstelle den Programmierern von Google schon, daß sie den auf eben diesen sichtbaren Inhalt reduzierten Text - ggfls. mit Markierungen für die semantische Bedeutung wie Hx - auswerten und das Originaldokument nicht weiter verwenden - auch nicht dessen Dateigröße.

Abgesehen davon: wenn doch das MarkUp bei der späteren Suche ignoriert wird, sollte es auch keinen sonstigen Einfluß haben; dazu kommt noch, daß eine Einbeziehung weitere unnötige Rechnerkapazitäten erfordern würde. Und die rene Dateigröße bei der Berechnung der Keyworddichte heranzuziehen, wäre auch völlig unsinnig, da dann ja auch Quelltext-Einrückungen gewichtet würden.

freundliche Grüße
Ingo

[at]

Hallo.

Die These ist, dass von zwei Dokumenten, die exakt denselben Textinhalt haben mit exakt derselben semantischen Auszeichnung, das eine aber zusätzlich (semantisch nicht relevantes) Markup enthält, dasjenige Dokument von Google als wichtiger bewertet wird, welches den Inhalt mit möglichst (quantitativ) wenig HTML auszeichnet.

Aber sind Tabellen nicht -- korrekt angewandt -- semantisch relevant? Und wie findet Google oder eine andere Suchmaschine heraus, ob die vorgefundenen Elemente korrekt angewandt worden sind? Und kann eine Suchmaschine überhaupt die Semantik einer Seite bewerten? Oder schaffen sie gar eine eigene, indem sie den Autoren dazu veranlassen, bestimmte Elemente besonders häufig, andere hingegen gar nicht zu verwenden?
MfG, at

[chlori]

Hi

Mit Tabellen hast du viel mehr HTML-Code. Suchmaschinen
werten u.a. nach Relevanz. Wenn auf einer Tennis-Seite 10%
der Wörter "Tennis" sind, dann ist der Begriff "Tennis"
relevanter als wenn das Wort nur 1% des Textes (Codes) ist.
Weniger Code => Höhere Relevanz des Textes

Sind das Vermutungen, die auf zufälligen Erfahrungen basieren,
die man mit dieser Theorie erklären könnte, ohne andere
Erklärungen falsifiziert zu haben, oder gibt es diesbezüglich
Untersuchungen, die mit halbwegs wissenschaftlichen Methoden
arbeiten und die für die Sinnhaftigkeit einer solchen
Erklärung sprechen?

Suchmaschinen haben (laut Berichten) "zugegeben", dass den
ersten etwa 3kb (80-100 Zeilen (Hab nicht nachgerechnet!))
eines HTML-Files (grosse) Beachtung geschenkt wird. Dies
im Zusammenhang mit dem Abraten tausende von Keywords in
ein Meta-Tag zu verpacken und lange Javascript-Codes für
Menüs etc. zu verwenden. Und mit Erwähnung des Vorteils
wenn der Content *vor* der Navigation im Source- Code
steht. Was für mich nachvollziehbar und glaubwürdig tönt.

Glaubt man dies, dann glaubt man auch, wenn ich wie oben
behaupte (oder von mir aus glaube), dass dichter Content
im HTML-Code zu höherer Relevanz der vorkommenden
Keywords und -phrases führt.

Ob das PageRanking Einfluss auf die Gründlichkeit (Tiefe)
des n"Crawlens" auf einer Website hat, wäre sicher
wichtig und interessant. Vielleicht weiss das jemand?

Solange ersteres zutrifft, ist eine
solche Aussage strenggenommen nicht mehr als ein Mythos.

Wie bei vielem, das man hört und liest, ein klärender
Beweis ist schwer zu finden.

Gruss
chlori

[molily]

Hallo,

Suchmaschinen haben (laut Berichten) "zugegeben"

Das beantwortet meine Frage nicht. Wo sind diese Berichte und sind sie vertrauenswürdig? Es wird sehr viel über die Methoden der Suchmaschinen berichtet. Das Meiste davon ist nicht fundiert.

dass den ersten etwa 3kb (80-100 Zeilen (Hab nicht nachgerechnet!)) eines HTML-Files (grosse) Beachtung geschenkt wird.

Wurde ausdrücklich gesagt, dass es sich um die Codezeilen und nicht die ersten drei Kilobyte des Nettotextes handelt?

Dies im Zusammenhang mit dem Abraten tausende von Keywords in ein Meta-Tag zu verpacken und lange Javascript-Codes für Menüs etc. zu verwenden.

Das ist gelinde gesagt eine unvernünftige Strategie, da es Dokumente vernachlässigt, die sinnvolle Metadaten angeben. Auch ohne »tausenden« von Keywords und Inline-JavaScript oder -CSS im head kann ein Dokument, ohne dass es nach landläufiger Auffassung etwas konzeptionell falsch macht, locker auf 2000 Zeichen im head kommen.

Solange ersteres zutrifft, ist eine solche Aussage strenggenommen nicht mehr als ein Mythos.

Wie bei vielem, das man hört und liest, ein klärender Beweis ist schwer zu finden.

Dann ist es nicht sinnvoll, ja sogar in einer vernünftigen Diskussion unzulässig, entsprechendes auszusagen, ohne nicht gleichzeitig ausdrücklich auf den spekulativen Charakter hinzuweisen. Solche schwammigen Argumente gegen Tabellenlayout anzuführen, halte ich für unüberlegt.

Mathias

[Ingo Turski]

Hi,

Suchmaschinen haben (laut Berichten) "zugegeben", dass den
ersten etwa 3kb (80-100 Zeilen (Hab nicht nachgerechnet!))
eines HTML-Files (grosse) Beachtung geschenkt wird.

Dies ist nicht nur sehr schwammig, wie molily auch schon angemerkt hat, sondern impliziert noch längst keinen Zusammenhang mit der Keyworddichte. Das einzige, was ich hier nachvollziehen kann, ist die tatsächlich häufig anzutreffende Theorie, daß einem Text am Anfang höheres Gewicht beigemessen wird als einem später im Quelltext auftretendem Text. Denn das macht auch durchaus Sinn: zum einen ist es üblich, die wesentlichen Inhalte (worum es bei der Seite überhaupt geht) bereits in der Enführung anzusprechen und zum anderen ist es für den Suchenden weniger hilfreich, wenn das gesuchte Keyword erst nach mehreren Bildschirmseiten auftaucht.
Suchmaschinen versuchen schließlich, dem Suchenden Seiten anzubieten, in denen der gesuchte Inhalt leicht zu finden ist und auch zum Thema der Seite gehört. Gerade deshalb haben z.B. auch die Texte von Backlinks eine besondere Bedeutung.

freundliche Grüße
Ingo

[Elya]

Hallo Tim,

erstmal danke für Deine auführliche Antwort und sorry, dass Du nun wegen mir die Bahn verpasst hast. Du hast aber sicherlich Gleitzeit;-)

und noch immer ein Auto, das mir in solchen Fällen aushilft, obwohl ich es längst hätte verkaufen sollen...

Ja, das mit der Zentrierung stimmt. Aber was genau meinst Du mit Footer?

Sowas zum Beispiel: http://www.alistapart.com/articles/footers. Sieht im Beispiel noch übersichtlich aus, bei komplexeren Konstruktionen macht die Aufgabenstellung jedoch Kopfschmerzen, z.B. im Safari (von wegen "degrace gracefully"...)

OK, ich hab bisher noch nie richtig Tabellendesign eingesetzt. Deshalb fällt mir ein Design mit <div>s leichter.

Das ist bei den meisten sicher das Problem: Wir haben alle seit Jahren die Routine im Verschachteln dieser ver***ten Tabellen, aber eben noch nicht im floaten von Block-Elementen.

Das mit der Suchmaschinenfeindlichkeit wusste ich jetzt noch nicht. Kannst Du das näher erläutern?

Hat Dir chlori schon was zu geschrieben. Dazu kommt manchmal (muß aber nicht) eine Konstruktion wie <td class="headline">wichtiges Stichwort</td>, bei der eine Suchmaschine leider nicht erkennt, daß es ein wichtiges Stichwort ist. Bei <h1>wichtiges Stichwort</h1> hingegen schon.

CMS ist auch für mich eine interessante Sache. Leider habe ich noch nicht viel Ahnung darüber. Gibt es evtl. auch was kostenloses in dieser Richtung womit man ein wenig "spielen" kann?

Jede Menge. Siehe </archiv> oder auch http://www.contentmanager.de, konkreter z.B. http://www.contenido.de.

Arbeitest Du in der Webdesign Branche?

ja.

Als was?

gute Frage, ich überlege noch, was auf meine Visitenkarte soll. Mädchen für alles, Troubleshooterin, Kollegen-den-Rücken-Freihalterin, CSS-Predigerin, Universaldilletantin, Azubiquälerin ... oder so ;)

Gruß aus Köln-Ehrenfeld,

Elya

[at]

Hallo.

Arbeitest Du in der Webdesign Branche?
ja.
Als was?
gute Frage, ich überlege noch, was auf meine Visitenkarte soll. Mädchen für alles, Troubleshooterin, Kollegen-den-Rücken-Freihalterin, CSS-Predigerin, Universaldilletantin, Azubiquälerin ... oder so ;)

Klingt nach "Halbgöttin" ;-)
MfG, at

[Chräcker Heller]

Hallo,

habe lange kein "finde ich auch" Posting abgesetzt, aber da ich zwar keine Bahn verpassen kann, aber gleich zu meinen Senioren surfen gehe, hänge ich mich einfach an Dein Posting dran:

Finde ich auch...

(Außerdem kann ich Dich auf diese Art und Weise mal wieder direkt "über den Fluß drüber" grüßen. Von einer "scheelen sick" zur anderen "scheelen sick" )

__

Ach ja, eins habe ich doch noch ,-)

[1]aber seien wir mal ganz ehrlich: das ist ein recht elitäres
Argument, das im Alltag wenig Bedeutung hat.

Stimmt. Aber ich habe die Erfahrung, auch hier im Laufe der Zeit, gemacht, das diese "elitären Gedankengebilde" letztendlich dann doch wieder postiven Einfluß haben, in unserer Sichtweise, wie Alltagsdinge gestaltet werden müssen. Auch wenn man versucht, das Pferd nicht von der Maschine aus aufzuzäumen, sondern an erster Stelle der Mensch steht, hilft es doch ungemein, auch solche elitären Dinge der Theorie immer mal wieder zu erwähnen und zumindest zu wissen. Nach dem motto: man sollte schon wissen, welches Werkzeug man "wie" zugunsten des Alltags verbiegt ;-) (Was bei Dir sicherlich eher auser Frage steht - fiel mir nur ein/auf)

Chräcker

[at]

Hallo.

[1]aber seien wir mal ganz ehrlich: das ist ein recht elitäres
Argument, das im Alltag wenig Bedeutung hat.

Stimmt. Aber ich habe die Erfahrung, auch hier im Laufe der Zeit, gemacht, das diese "elitären Gedankengebilde" letztendlich dann doch wieder postiven Einfluß haben, in unserer Sichtweise, wie Alltagsdinge gestaltet werden müssen.

Ich gehe in meiner Ansicht noch weiter: Wenn einen etwas jenseits der eigenen kleinen Welt der Tüfteleinen und Workarounds, nämlich konzeptionell weiterbringt, basiert es meist diesem Ansatz.
MfG, at

[chlori]

Hi

Mich würde nun interessieren was denn Eure Meinung zu
Tabellendesign ist.

1996 war's ok.

Gruss
chlori

[Struppi]

• Einschränkungen bei Änderungen des Layouts (mit <div>s ist man da freier als mit Tabellen, da man sie z.B. einfacher woanders positionieren kann wenn sich mal das Layout ändert)

• Für mich aufwendiger zu 'programmieren'

• Die Ladezeit, bzw. die Zeit für die Darstellung im Browser soll angeblich höher sein, da der Browser zuerst die gesamte Tabelle lädt und dann alles auf einmal darstellt (wenn man z.B. die gesamte Seite in einer Tabelle hat).

FRAGE: verhält sich der Browser nicht analog wenn ich eine gesamte Seite in einen <div> packe?

Mich würde nun interessieren was denn Eure Meinung zu Tabellendesign ist.
Vielleicht habt Ihr noch ein paar schlagende Argumente gegen Tabellendesign damit ich meine Bekannte endgültig davon überzeugen kann es sein zu lassen.

Wenn man in Tabellendesign denkt sind Tabellen die Wahl der Mittel. Was soll man sich rumplagen, wenn's hier nicht sitzt und da überschneidet. Letztlich hängt es an der "elitären" Semantik eines Dokumentes ob ein Layout mit CSS gelingt oder nicht. Designer fällt es offensichtlich schwer sich ein Dokument als Struktur vorzustellen und haben ein Bild im Kopf (das macht sie vermutlich zu Designern). Und um das umzusetzten, dazu sind die Mittel HTML/CSS halt wirklich nicht optimal.
(http://www.woodshed.de/werbeagenturen/index.html)

Das ist wie jemand, der mit einem Schraubenzieher nicht umgehen kann, der wird die Schraube halt mit einem Hammer in die Wand hauen - warum auch nicht, es geht doch.

Mit ein bisschen Übung und dem Willen zum umsetzten einer Struktur, ist es wesentlich einfacher mit CSS zu arbeiten als mit Tabellen, die schnell überhand nehmen können und sich irgendwann nicht mehr ohne Werkzeug bearbeiten lassen, da man ab einer 3. Tabellen in einer Tabelle nur schwer im Quelltext erkennen kann wo im Quellcode die HTML Paare zwischen dem Text stehen.

Wenn man den Quellcode von vielen Tabellenseiten betrachtet, wird man festellen das oft die Tabelle als Designhilfsmittel mißbraucht wird, nicht zur Strukturierung. Z.b. blinde Zeilen mit einem farbigen Hintergrund als Linien, den ich mit CSS mit einem einfachen border erzeugen kann. Oder um Abstände zu produzieren (margin) usw. usf. Das sind die Punkte die am Tabellenlayout völlig überflüssig sind und wirklich von Unkentniss zeugen. Eine Tabelle lediglich zu benutzten um z.b. ein 2 spaltiges Layout zu erzeugen halte ich noch nicht für verwerflich - auch wenn es ohne geht.

Struppi.

[at]

Hallo.

Designer fällt es offensichtlich schwer sich ein Dokument als Struktur vorzustellen und haben ein Bild im Kopf (das macht sie vermutlich zu Designern).

Laien fällt es offensichtlich schwer, sich einen Designer als intelligent vorzustellen und haben ein lückenhaftes Berufsbild im Kopf (das macht sie vermutlich zu Laien).
MfG, at

[Struppi]

Designer fällt es offensichtlich schwer sich ein Dokument als Struktur vorzustellen und haben ein Bild im Kopf (das macht sie vermutlich zu Designern).

Laien fällt es offensichtlich schwer, sich einen Designer als intelligent vorzustellen und haben ein lückenhaftes Berufsbild im Kopf (das macht sie vermutlich zu Laien).

Ich habe überhaupt kein Berufsbild von Designern im Kopf. aber ich verstehe nicht was du meinst. Habe ich jemanden Intelligenz abgesprochen?

Struppi.

[at]

Hallo.

Designer fällt es offensichtlich schwer sich ein Dokument als Struktur vorzustellen und haben ein Bild im Kopf (das macht sie vermutlich zu Designern).

Laien fällt es offensichtlich schwer, sich einen Designer als intelligent vorzustellen und haben ein lückenhaftes Berufsbild im Kopf (das macht sie vermutlich zu Laien).

Ich habe überhaupt kein Berufsbild von Designern im Kopf. aber ich verstehe nicht was du meinst. Habe ich jemanden Intelligenz abgesprochen?

Dafür dass du kein Berufsbild von Designern im Kopf hast, lässt du dich aber sehr deutlich darüber aus. Sich ein Dokument als Struktur vorzustellen, halte ich für einen intellektuellen Vorgang, den du Designern offenkundig nicht zutraust. -- Im Übrigen ist es bezeichnend, meine völlig allgemeine Aussage auf dich zu beziehen ;-)
MfG, at

[Struppi]

Ich habe überhaupt kein Berufsbild von Designern im Kopf. aber ich verstehe nicht was du meinst. Habe ich jemanden Intelligenz abgesprochen?

Dafür dass du kein Berufsbild von Designern im Kopf hast, lässt du dich aber sehr deutlich darüber aus. Sich ein Dokument als Struktur vorzustellen, halte ich für einen intellektuellen Vorgang, den du Designern offenkundig nicht zutraust. -- Im Übrigen ist es bezeichnend, meine völlig allgemeine Aussage auf dich zu beziehen ;-)

Naja, du hast dich auf meine Nachricht bezogen, oder?

Meine Erfahrungen mit Grafikdesigner ist die, das diese aus einer Vorlage ein schönes Bild entwerfen können und dieses auch in ihrem Grafikprogramm zusammensetzten. Bei diesem intellektuellen Vorgang sind sie mir haushoch überlegen. Doch um eine Internetseite daraus zu machen und eine logische Auszeichnung des Dokumentes mit HTML vorzunehmen, sind nach meiner Erfahrung wohl die meisten Grafikdesigner überfordert, ob sie das intellektuell sind ist mir nicht bekannt. Ich vermute eher das dies einfach eine andere herangehensweise ist. die zu den bekannten kaum nutzbaren Internetseiten führt.

Struppi.

[at]

Hallo.

Meine Erfahrungen mit Grafikdesigner ist die, das diese aus einer Vorlage ein schönes Bild entwerfen können und dieses auch in ihrem Grafikprogramm zusammensetzten. Bei diesem intellektuellen Vorgang sind sie mir haushoch überlegen. Doch um eine Internetseite daraus zu machen und eine logische Auszeichnung des Dokumentes mit HTML vorzunehmen, sind nach meiner Erfahrung wohl die meisten Grafikdesigner überfordert, ob sie das intellektuell sind ist mir nicht bekannt. Ich vermute eher das dies einfach eine andere herangehensweise ist. die zu den bekannten kaum nutzbaren Internetseiten führt.

Du kennst einfach die falschen Leute. Ebenso könnte ich behaupten, Programmierer seien nicht in der Lage, eine anschauliche Präsentation ihres derzeiten Projektes zu produzieren. Wenn dies jedoch ein Teil meiner Anforderungen an den Job ist, muss ich mir eben jemanden suchen, der dem gerecht wird. -- Es gibt sie ja, nur eben nicht wie Sand am Meer.
Ich fand nur die Verallgemeinerung unangebracht.
MfG, at

[Cyx23]

Hallo Struppi,

Meine Erfahrungen mit Grafikdesigner ist die, das diese aus einer Vorlage ein schönes Bild entwerfen können und dieses auch in ihrem Grafikprogramm zusammensetzten. Bei diesem intellektuellen Vorgang sind sie mir haushoch überlegen. Doch um eine Internetseite daraus zu machen und eine logische Auszeichnung des Dokumentes mit HTML vorzunehmen, sind nach meiner Erfahrung wohl die meisten Grafikdesigner überfordert, ob sie das intellektuell sind ist mir nicht bekannt. Ich vermute eher das dies einfach eine andere herangehensweise ist. die zu den bekannten kaum nutzbaren Internetseiten führt.

eine klassiche Werbeagentur muss nicht der optimale Partner für gutes Webdesign sein, auch der klassischer Grafiker muss zunächst nicht der optimale Webdesigner sein, doch selbst der -wenn es ihn denn so wie geschildert gibt- sollte aber schon einen gewissen Transfer auf das Medium schaffen, zumal ihm ein Teil seiner Ausbildung auch unmittelbar zugute kommen sollte.

Nun nennt sich solch ein Design-Studium aber z.B. Studiengang Visuelle Kommunikation oder Kommunikationsdesign, schaut also meist bereits über den von dir angenommen Tellerrand, dann gibt es ja noch beispielsweise Industrial- und Produktdesigner die noch stärker die Anwendbarkeit und Usability im Blick haben. Auch dein Ansatz der Umsetzung eines Bildes -"eine Internetseite daraus zu machen"- trifft so nicht unbedingt auf den Designvorgang zu.

Bei der deiner Krititk wohl zugrundeliegenden traditionellen Agentursituation, die schon wegen der Mac-Umgebung nachteilig sein dürfte, gibt es oft noch den "Webprogrammierer". Die Arbeitsteilung halte ich zwar auch für nachteilig, doch können sich die von dir angenommenen Punkte bereits da erledigt haben, ansonsten müsste auch noch die Abhängigkeit von bestimmter Software welche den HTML-Code ausgibt erörtert werden.

Nicht berücksichtigt hast du bei der Bewertung einer Seite die Frage nach dem Ziel der jeweiligen Arbeit etwa im Zusammenhang mit der "CI" und der Zielgruppe, manche Internetseite muss gar nicht deinen Anforderungen an Nutzbarkeit entsprechen, und vergessen hast du noch die Kritikpunkte einer Vorliebe für zu kleine Schriften und die unkritische Begeisterung für Flash;)

Grüsse

Cyx23

[at]

Hallo.

Nun nennt sich solch ein Design-Studium aber z.B. Studiengang Visuelle Kommunikation oder Kommunikationsdesign, schaut also meist bereits über den von dir angenommen Tellerrand, dann gibt es ja noch beispielsweise Industrial- und Produktdesigner die noch stärker die Anwendbarkeit und Usability im Blick haben.

Interessanterweise sind auch Produktdesigner oft Kommunikationsdesigner, da Produktdesign häufig eine Vertiefungsrichtung des Studiengangs Kommunikationsdsign ist.

Bei der deiner Krititk wohl zugrundeliegenden traditionellen Agentursituation, die schon wegen der Mac-Umgebung nachteilig sein dürfte, gibt es oft noch den "Webprogrammierer".

Was soll an einer Mac-Umgebung nachteilig sein?
MfG, at

[Cyx23]

Hallo,

Bei der deiner Krititk wohl zugrundeliegenden traditionellen Agentursituation, die schon wegen der Mac-Umgebung nachteilig sein dürfte, gibt es oft noch den "Webprogrammierer".

Was soll an einer Mac-Umgebung nachteilig sein?

an sich natürlich erstmal nichts, das hätte ich noch etwas ausführen müssen. Ich meinte Mac-Umgebung im Zusammenhang mit Webdesignerstellung und -kontrolle bei Webseiten für eine Windows-Mainstream-Zielgruppe.

Ich sehe einen kleinen Vorteil darin mit dem OS der Zielgruppe zu arbeiten, und bei der in einigen Agenturen üblichen OS-Monokultur, abgesehen von der Einstellung gegenüber Dosen, dürften Tests unter Windows sowieso etwas kurz ausfallen. Wobei ich das allerdings selbst nicht ganz konsequent anwende und verständlicherweise nicht so viel mit IEs unterwegs bin.

Bei Flash ist wohl etwas ähnliches auch mit Windows NT oder XP möglich, wenn z.B. die CPU-Auslastung bei Win9x mehr auffällt als bei anderen Win-Versionen oder Linux usw..

Auch die Auflösungsgeschichte der OSe ist ja ein alter und eigentlich geregelter Hut, und so stellt sich beispielsweise die Frage ob eine bewusste Verwendung von font-size:9px; als Besucherweiche gedacht ist oder was sonst dahinterstecken mag.

Grüsse

Cyx23

[at]

Hallo.

an sich natürlich erstmal nichts, das hätte ich noch etwas ausführen müssen. Ich meinte Mac-Umgebung im Zusammenhang mit Webdesignerstellung und -kontrolle bei Webseiten für eine Windows-Mainstream-Zielgruppe.

Ach so, verstehe.

Ich sehe einen kleinen Vorteil darin mit dem OS der Zielgruppe zu arbeiten, und bei der in einigen Agenturen üblichen OS-Monokultur, abgesehen von der Einstellung gegenüber Dosen, dürften Tests unter Windows sowieso etwas kurz ausfallen.

Darin gebe ich dir sicher Recht.

Wobei ich das allerdings selbst nicht ganz konsequent anwende und verständlicherweise nicht so viel mit IEs unterwegs bin.

Das dürfte ja für die meisten hier gelten. Auch der Anteil der Linux-Anwender, die folglich Mozilla oder Konqueror einsetzen, dürfte hier ja nicht wirklich repräsentativ sein.

Bei Flash ist wohl etwas ähnliches auch mit Windows NT oder XP möglich, wenn z.B. die CPU-Auslastung bei Win9x mehr auffällt als bei anderen Win-Versionen oder Linux usw..

In diesem Fall sollte eine Mac-Umgebung aber dem Worst-Case-Szenario recht nahe komen :-(

Auch die Auflösungsgeschichte der OSe ist ja ein alter und eigentlich geregelter Hut, und so stellt sich beispielsweise die Frage ob eine bewusste Verwendung von font-size:9px; als Besucherweiche gedacht ist oder was sonst dahinterstecken mag.

Unkenntnis und Unfähigkeit -- plattformübergreifend :-(
MfG, at

[Andreas-Lindig]

Hallo Struppi,

Meine Erfahrungen mit Grafikdesigner ist die, das diese aus einer Vorlage ein schönes Bild entwerfen können und dieses auch in ihrem Grafikprogramm zusammensetzten...

jaja und gut Sonnenblumen malen mit ihrem Tuschkasten können sie auch diese Disainer, alles klar ;-)

Was oft übersehen wird, ist, daß gutes Grafik-Design eben nicht nur ästhetisch ansprechend ist, sondern sehrwohl auch eine Struktur und logische Bezüge abbildet, aber eben anders als es HTML tut. Das ist der entscheidende Punkt. Der Grafiker betrachtet das Zusammenspiel von verschieden gerichteten Linien und verschiedenen Flächen und Punkten. Eine einfache Tabelle ist so ein Beispiel. Sie stellt sehrwohl eine Struktur dar - und zwar mit flächigen Mitteln. Eine Zeile oder Spalte ist nichts anderes als eine Linie, die zeigt: 'dies gehört zusammen' oder: 'dies folgt auf jenes'. Und wo sich zwei solcher Linien treffen, ist der gesuchte Wert. Grafik ist also fächig orientiert, zweidimensional. HTML hingegen ist Textorientiert, also eher eindimensional - die lineare Verzweigung von einem Stamm aus. Die grafiktaugliche Darstellung der Zusammenhänge ist in HTML eben schwierig.

Doch um eine Internetseite daraus zu machen und eine logische Auszeichnung des Dokumentes mit HTML vorzunehmen, sind nach meiner Erfahrung wohl die meisten Grafikdesigner überfordert...

kann sein, aber vor allem denken sie _anders_ und zwar so, wie es der Normalbürger auch besser versteht.

Ich vermute eher das dies einfach eine andere herangehensweise ist, die zu den bekannten kaum nutzbaren Internetseiten führt.

ob bei nicht nutzbaren Seiten nicht eher die Frontpagekids die Nase vorn haben?

Gruß, Andreas

[Schuer]

Hallo,

Laien fällt es offensichtlich schwer, sich einen Designer als intelligent vorzustellen und haben ein lückenhaftes Berufsbild im Kopf (das macht sie vermutlich zu Laien).

Himmel, fast wäre mir dieses Zitat durch die Lappen gegangen, weil mich das Thema des Threads nicht sonderlich interessierte! Gut, dass ich doch nur kurz reingeklickert habe :-)

Gruß,
_Di*pl Des.* rk

[Struppi]

Laien fällt es offensichtlich schwer, sich einen Designer als intelligent vorzustellen und haben ein lückenhaftes Berufsbild im Kopf (das macht sie vermutlich zu Laien).

Himmel, fast wäre mir dieses Zitat durch die Lappen gegangen, weil mich das Thema des Threads nicht sonderlich interessierte! Gut, dass ich doch nur kurz reingeklickert habe :-)

Nur ist es falsch, da ich weder von intelligenz gesprochen habe, noch ein Berufsbild von Designern habe. Und in keiner Silbe habe Profis oder Laien erwähnt.

Mir ging es in meiner Aussage nur um die Unterscheidung eines Entwurfs eines Designs und einer HTML Seite. Oftmals läuft der Designentwurf der HTML Struktur entgegen, was mich zu meiner These kommen liesse.

Keine Ahnung ob ich hier Designer auf dem Fuß getreten bin, es war nicht so von mir gewollt.
Im Gegenteil ich bewundere Menschen die die Fähigkeit haben visuell ansprechendes zu gestalten. Eine Fähigkeit, die ich nicht Ansatzweise habe  und bei der ich mit denm Hammer die Schraube in die Wand triebe, in dem ich immer wieder probiere, umstelle, Farben wechsle bis ich das Gefühl hab, es geht nicht mehr besser.

Trotz allem waren zumindest meine Erfahrungen in der Zusammenarbeit mit Designern bzw. richtig - Grafiker - wie von mir beschrieben und Aufgrund vieler Anfragen hier von verzweifelten die den Entwurf umsetzten müssen, kann man wohl davon ausgehen das das nicht selten ist.

Struppi.

[Schuer]

Hallo,

Nur ist es falsch, da ich weder von intelligenz gesprochen habe, noch ein Berufsbild von Designern habe. Und in keiner Silbe habe Profis oder Laien erwähnt.

ich habe das Zitat auch nicht auf deine Aussage bezogen - mir ist egal, welches Berufsbild du von und welche Erfahrungen du mit Designern hast oder nicht hast - sondern es gefällt mir allgemein sehr gut. Man wird mit solchen im Posting angesprochenen Behauptungen hin und wieder konfrontiert, wenn man auf Neider trifft, und da kann man auf gleichem Niveau sehr gut das Zitat anbringen, ohne wild diskutieren zu müssen.

Gruß,
_Dirk

[at]

Hallo.

ich habe das Zitat auch nicht auf deine Aussage bezogen - mir ist egal, welches Berufsbild du von und welche Erfahrungen du mit Designern hast oder nicht hast - sondern es gefällt mir allgemein sehr gut.

So, jetzt muss ich mich aber wirklich ganz höflich bedanken :-)
MfG, at

[Mitch]

Interessante Diskussion hier.

Bin inzwischen eigentlich nur noch Hobby-Webdesigner und habe immer auf Tabellen-Layout geschwört. Durch Eure Diskussion eröffnen sich mir aber doch ganz neue Aussichten. Da merkt man mal dass man sich nicht weiterentwickelt, wenn man sich nicht mit Profis über so Sachen unterhält. :)

Danke schonmal.

[Avalon]

Interessante Diskussion hier.

Bin inzwischen eigentlich nur noch Hobby-Webdesigner und habe immer auf Tabellen-Layout geschwört. Durch Eure Diskussion eröffnen sich mir aber doch ganz neue Aussichten. Da merkt man mal dass man sich nicht weiterentwickelt, wenn man sich nicht mit Profis über so Sachen unterhält. :)

Wenn Du Web-design nur noch zum Hobby machst, dann sind doch die ganzen Zwänge von außen (Kunden, Zeitdruck, usw.)weggefallen. Somit solltest Du eigentlich genug Muße haben Dir grundlegende Gedanken zur Strukturierung der Seite/ des Codes zu machen. Profis - zumindestens die in einer Webagentur - haben nicht die Zeit und Muße grundlegend neue Strukturen für das Web zu entwickeln (gut, vielleicht in ihrer Freizeit - aber wer beschäftigt sich in der Freizeit schon mit beruflichen Dingen).

Setz Dir ein Ziel: Jede Deiner Seiten soll ohne Tabellen auskommen, am besten auch gleich noch ohne Frames. Du wirst sehen, es geht und ist gar nicht so schwer. Wenn Du einmal erkannt hast wie's geht, wirst Du nie mehr auf Tabellen zurückgreifen wollen.

Tabellen gehören in Programme wie Excell oder vergleichbare.

Gruß
Avalon

[Tim]

Setz Dir ein Ziel: Jede Deiner Seiten soll ohne Tabellen auskommen, am besten auch gleich noch ohne Frames. Du wirst sehen, es geht und ist gar nicht so schwer. Wenn Du einmal erkannt hast wie's geht, wirst Du nie mehr auf Tabellen zurückgreifen wollen.

Hört, hört...
genau meine Rede. Finde ich ein gutes Statement.
Gruss

tim

[Wilhelm Turtschan]

habe d'ehre

Profis - zumindestens die in einer Webagentur - haben nicht die Zeit und Muße grundlegend neue Strukturen für das Web zu entwickeln (gut, vielleicht in ihrer Freizeit - aber wer beschäftigt sich in der Freizeit schon mit beruflichen Dingen).

Deine Meinung finde ich in hoechstem Masse absonderlich. Dieser "Profi" waere wohl die laengste Zeit "Profi", wenn er meint sich auf seinem Kenntnisstand von Gestern ausruhen zu koennen. Wie in jeder anderen Branche auch,

man liest sich
Wilhelm

[Avalon]

Deine Meinung finde ich in hoechstem Masse absonderlich. Dieser "Profi" waere wohl die laengste Zeit "Profi", wenn er meint sich auf seinem Kenntnisstand von Gestern ausruhen zu koennen. Wie in jeder anderen Branche auch,

Zwischen der Weiterentwicklung des eigenen Kenntnisstandes und der Weiterentwicklung von Webtechniken ist ein riesiger Unterschied, bitte bedenke dies.
Es war auch nie meine Intention den Profis die Fähigkeit sich zu Entwickeln abzusprechen.
Nur fällt es schwer, zwischen Kundenwünschen, Termindruck etc. Eigeninitiative für die Entwicklung neuer Webtechniken zu entwickeln, da geht man lieber ausgetrampelte Pfade weiter.
Wohlgemerkt soll dies keine Verallgemeinerung sein, nur ein Anstoß zum Nachdenken über das eigene Handeln.
Gruß
Avalon

[at]

Hallo.

Zwischen der Weiterentwicklung des eigenen Kenntnisstandes und der Weiterentwicklung von Webtechniken ist ein riesiger Unterschied, bitte bedenke dies.

Das hat er getan. Du liegst schlicht daneben.
MfG, at

[chlori]

Hi

Profis - zumindestens die in einer Webagentur - haben nicht die
Zeit und Muße grundlegend neue Strukturen für das Web zu entwickeln

1. Bei Profis geht's oft nicht anders als CSS, da es im besten
Fall nicht die gleiche Person ist (HTML/CSS).

Setz Dir ein Ziel: Jede Deiner Seiten soll ohne Tabellen auskommen,

Ich hoffe du meinst "ohne Tabellen für Layout".

am besten auch gleich noch ohne Frames.

Auf jedenfall. Frames sind schon lange tot.

Wenn Du einmal erkannt hast wie's geht, wirst Du nie mehr
auf Tabellen zurückgreifen wollen.

Bullshit, du wirst Tabellen sinnvoll einsetzen wo Tabellen gebraucht
sind.

Tabellen gehören in Programme wie Excell oder vergleichbare.

Und in Webseiten mit tabellarischen Daten.

Gruss
chlori

[Avalon]

Tabellen gehören in Programme wie Excell oder vergleichbare.

Und in Webseiten mit tabellarischen Daten.

Auf Webseiten gibt es nur geometrisch angeordnete Daten, aber keine tabellarischen Daten. Ein tabellarisches Datum setzt eine inhaltlich-logische Verknüpfung zu den Tabelleneingängen vorraus, diese ist auf Webseiten nicht gegeben, also bleibt die reine Geometrie der Darstellung. Hierzu braucht man nicht ein Konstrukt mit einer Verschachtelungstiefe von mindestens drei Ebenen (table, tr, td).
Das geht entschieden enfacher.

Gruß
Avalon

[chlori]

Hi

Tabellen gehören in Programme wie Excell oder vergleichbare.

Und in Webseiten mit tabellarischen Daten.

Auf Webseiten gibt es nur geometrisch angeordnete Daten,
aber keine tabellarischen Daten.

Hier sind wir nicht gleicher Meinung.

Wenn man alles benutzt wofür es gedacht ist, dann ist das eine
direkte Förderung/Ermöglichung der Entwicklung:

Benutzt man CSS für das Layout, dann können die Browser und auch
CSS in diese Richtung weiterentwickelt werden.

Das gleiche gilt für Tabellen. Wären Tabellen nur dafür eingesetzt
worden, wofür sie gedacht sind, hätten unsere Browser schon lange
Tabellen-Funktionen eingebaut wie sortieren, addieren, ein-
ausblenden, etc.

Es wäre im Sinne des Webs, wenn Webbrowser so funktionieren
könnten und nicht zusätzliche Software/Plugins dies übernehmen
müssen.

Gruss
chlori

[Avalon]

Das gleiche gilt für Tabellen. Wären Tabellen nur dafür eingesetzt
worden, wofür sie gedacht sind, hätten unsere Browser schon lange
Tabellen-Funktionen eingebaut wie sortieren, addieren, ein-
ausblenden, etc.

Das ist genau das Henne/Ei-Problem: Hätten die Browser sinnvolle Tabellenfunktionen, könnte man sie auch sinnvoll einsetzen.
Die rein geometrische Anordnung von HTML-Elementen ist KEINE sinnvolle Anwendung von Tabellen!

Es wäre im Sinne des Webs, wenn Webbrowser so funktionieren
könnten und nicht zusätzliche Software/Plugins dies übernehmen
müssen.

Stimmt, mit der Aussage habe ich überhaupt keine Probleme. Nur solange Tabellen nicht so funktionieren, gibt es auch keine sinnvolle Anwendung für sie.

Gruß
Avalon

[at]

Hallo.

Die rein geometrische Anordnung von HTML-Elementen ist KEINE sinnvolle Anwendung von Tabellen!

Doch. Sie dient hier wie anderswo der Vergleichbarkeit ihrer Inhalte.
MfG, at

[Avalon]

Hallo.

Die rein geometrische Anordnung von HTML-Elementen ist KEINE sinnvolle Anwendung von Tabellen!

Doch. Sie dient hier wie anderswo der Vergleichbarkeit ihrer Inhalte.

Das bezieht sich aber auf die geometrische Anordnung, nicht auf die Tabelle.
Ihr müßt Euch endlich angewöhnen, zwischen der Darstellung von Daten und der Methode zur Erzeugung dieser Darstellung zu differenzieren.
Ich sage nur, das es bessere Methoden zur geometrischen Darstellung von tabellarischen Konstrukten gibt als <table>, <tr> und <td>.

Gruß
Avalon

[at]

Hallo.

Doch. Sie dient hier wie anderswo der Vergleichbarkeit ihrer Inhalte.

Das bezieht sich aber auf die geometrische Anordnung, nicht auf die Tabelle.

Unsinn. Ob ich eine Tabelle überhaupt geometrisch anordne, fällt in die Zuständigkeit von CSS.

Ihr müßt Euch endlich angewöhnen, zwischen der Darstellung von Daten und der Methode zur Erzeugung dieser Darstellung zu differenzieren.

Das bestimmst du nicht.

Ich sage nur, das es bessere Methoden zur geometrischen Darstellung von tabellarischen Konstrukten gibt als <table>, <tr> und <td>.

Ja, CSS -- in Verbindung mit <table> etc.
MfG, at

[Avalon]

Doch. Sie dient hier wie anderswo der Vergleichbarkeit ihrer Inhalte.

Das bezieht sich aber auf die geometrische Anordnung, nicht auf die Tabelle.

Unsinn. Ob ich eine Tabelle überhaupt geometrisch anordne, fällt in die Zuständigkeit von CSS.

Überleg Dir mal, was Du sagst: nicht 'ob', sondern 'wie' muß es heißen. Angeordnet wird eine Tabelle immer, egal ob mit oder ohne CSS. Notfalls entscheidet der Browser.
Zweitens: auf die Geometrie der Tabelle hat CSS nur bescheidenen Einfluß. Das Grundmuster einer Tabelle kann nicht durch CSS beeinflußt werden.

Ihr müßt Euch endlich angewöhnen, zwischen der Darstellung von Daten und der Methode zur Erzeugung dieser Darstellung zu differenzieren.

Das bestimmst du nicht.

Stimmt, das entscheide ich nicht, der Unterschied ist a priori gegeben.
Dir kann man nur wärmstens empfehlen dies zu akzeptieren.
Oder kennst Du auch nicht den Unterschied zwischen einer Zahl und ihrer Darstellung?

Ich sage nur, das es bessere Methoden zur geometrischen Darstellung von tabellarischen Konstrukten gibt als <table>, <tr> und <td>.

Ja, CSS -- in Verbindung mit <table> etc.

Na klar, die Kopie ist besser als das Original.

Ich nehme mal einfach an, Du willst mich nicht verstehen. Vielleicht ist das auch alles etwas zu abstrakt.

Gruß
Avalon

[at]

Hallo.

Unsinn. Ob ich eine Tabelle überhaupt geometrisch anordne, fällt in die Zuständigkeit von CSS.

Überleg Dir mal, was Du sagst: nicht 'ob', sondern 'wie' muß es heißen. Angeordnet wird eine Tabelle immer, egal ob mit oder ohne CSS. Notfalls entscheidet der Browser.

Auch der entscheidet auf Grund seines internen CSS.

Zweitens: auf die Geometrie der Tabelle hat CSS nur bescheidenen Einfluß. Das Grundmuster einer Tabelle kann nicht durch CSS beeinflußt werden.

Nur weil du es nicht kannst, solltest du CSS diese Fähigkeit nicht absprechen.

Ihr müßt Euch endlich angewöhnen, zwischen der Darstellung von Daten und der Methode zur Erzeugung dieser Darstellung zu differenzieren.

Das bestimmst du nicht.

Stimmt, das entscheide ich nicht, der Unterschied ist a priori gegeben.
Dir kann man nur wärmstens empfehlen dies zu akzeptieren.
Oder kennst Du auch nicht den Unterschied zwischen einer Zahl und ihrer Darstellung?

Zuletzt hattest du dich noch auf die "Darstellung von Daten" und die "Methode zur Erzeugung dieser Darstellung" bezogen. Der Unterschied zwischen einer Zahl und ihrer Darstellung ist ein völlig anderes Thema und man könnte dich fast ob des spielereischen Jonglierens innerhalb dieser Begriffe bewundern -- bis einem dann wieder auffällt, welchen Unsinn du hier predigst.
MfG, at

[Avalon]

Hallo.

Unsinn. Ob ich eine Tabelle überhaupt geometrisch anordne, fällt in die Zuständigkeit von CSS.

Überleg Dir mal, was Du sagst: nicht 'ob', sondern 'wie' muß es heißen. Angeordnet wird eine Tabelle immer, egal ob mit oder ohne CSS. Notfalls entscheidet der Browser.

Auch der entscheidet auf Grund seines internen CSS.

Ach ja! Und was ist mit den Browsern, die kein CSS können?

Zweitens: auf die Geometrie der Tabelle hat CSS nur bescheidenen Einfluß. Das Grundmuster einer Tabelle kann nicht durch CSS beeinflußt werden.

Nur weil du es nicht kannst, solltest du CSS diese Fähigkeit nicht absprechen.

1. Das Grundmuster einer Tabelle ist vorgegeben, da kann niemand was dran ändern - auch nicht CSS -, sonst ist es keine Tabelle mehr.
2. Es geht ja auch nicht um die geometrische Anordnung der Tabelle, sondern von Daten.

Ihr müßt Euch endlich angewöhnen, zwischen der Darstellung von Daten und der Methode zur Erzeugung dieser Darstellung zu differenzieren.

Das bestimmst du nicht.

Stimmt, das entscheide ich nicht, der Unterschied ist a priori gegeben.
Dir kann man nur wärmstens empfehlen dies zu akzeptieren.
Oder kennst Du auch nicht den Unterschied zwischen einer Zahl und ihrer Darstellung?

Zuletzt hattest du dich noch auf die "Darstellung von Daten" und die "Methode zur Erzeugung dieser Darstellung" bezogen. Der Unterschied zwischen einer Zahl und ihrer Darstellung ist ein völlig anderes Thema

Klar anderes Thema aber gleiche Relation.
Zu Deinem Gunsten unterstelle ich Dir weiterhin, daß Du mich nicht verstehen WILLST.
Allerdings muß ich auch feststellen, daß Dir die Fähigkeit zu Transferleistungen fehlt.

Gruß
Avalon

[at]

Hallo.

Und was ist mit den Browsern, die kein CSS können?

Auch hier gilt, dass HTML nichts darstellt, sondern lediglich Strukturen auszeichnet. Wie Browser im einzelnen funktionieren ist zwar nicht maßgeblich, kannst du aber bei Bedarf bei Mozilla etc. erfragen. -- Bedarf besteht ja offenbar.

1. Das Grundmuster einer Tabelle ist vorgegeben, da kann niemand was dran ändern - auch nicht CSS -, sonst ist es keine Tabelle mehr.

Die Struktur, nicht die Darstellung.

2. Es geht ja auch nicht um die geometrische Anordnung der Tabelle, sondern von Daten.

Eben. Und die sind deshalb in Tabellen gut untergebracht, wenn sie denn tabellarisch sein sollen.

Zuletzt hattest du dich noch auf die "Darstellung von Daten" und die "Methode zur Erzeugung dieser Darstellung" bezogen. Der Unterschied zwischen einer Zahl und ihrer Darstellung ist ein völlig anderes Thema

Klar anderes Thema aber gleiche Relation.

Die Relation entspricht "HTML <-> CSS".

Zu Deinem Gunsten unterstelle ich Dir weiterhin, daß Du mich nicht verstehen WILLST.
Allerdings muß ich auch feststellen, daß Dir die Fähigkeit zu Transferleistungen fehlt.

Wenn du unter pathologichen Verifikationsanfällen leidest, solltest du noch einmal deinen Arzt oder Apotheker konsultieren.
MfG, at

[Schuer]

Hallo,

Ihr müßt Euch endlich angewöhnen, zwischen der Darstellung von Daten und der Methode zur Erzeugung dieser Darstellung zu differenzieren.
Ich sage nur, das es bessere Methoden zur geometrischen Darstellung von tabellarischen Konstrukten gibt als <table>, <tr> und <td>.

kannst du das Thema mal ganz kurz und schnell anreißen, damit es verständlicher wird? Es klingt mir sehr interessant.

Gruß,
_Dirk

[at]

Hallo.

Auf Webseiten gibt es nur geometrisch angeordnete Daten, aber keine tabellarischen Daten.

Nonsens. Wie ich Daten anordne, ist eine Frage von CSS. Und ob Daten tabellarisch sind, hast du nicht zu entscheiden.
MfG, at

[Cyx23]

Hallo,

• Einschränkungen bei Änderungen des Layouts (mit <div>s ist man da freier als mit Tabellen, da man sie z.B. einfacher woanders positionieren kann wenn sich mal das Layout ändert)

neuin, denn das würde besonders auf ein auch wieder unerwünschtes unflexibles Layout mit absoluten Positionierungen zutreffen

• Für mich aufwendiger zu 'programmieren'

Für andere nicht.

• Die Ladezeit, bzw. die Zeit für die Darstellung im Browser soll angeblich höher sein, da der Browser zuerst die gesamte Tabelle lädt und dann alles auf einmal darstellt (wenn man z.B. die gesamte Seite in einer Tabelle hat).

Nicht ganz so wild, und einige Browser (wie sogar Netscape 4) sind bei einem üblichen Tabellenanteil mit nicht zu hoher Verschachtelung recht schnell.

Vielleicht habt Ihr noch ein paar schlagende Argumente gegen Tabellendesign damit ich meine Bekannte endgültig davon überzeugen kann es sein zu lassen.

Nein, denn "Tabellendesign" hat gar nicht so viele grundsätzliche Nachteile, dafür viele Vorteile z.B. bei den IEs.
Bleibt eigentlich eine bessere Wartbarkeit von CSS, aber eine Trennung von Formatierung und Inhalt ist wegen der ungeklärten oder nicht unmsetzbaren strukturellen Zusammenhänge bei CSS und HTML nicht möglich, es bedarf oft Containerdivs und Hilfselemente und CSS-Weichen usw.

Grüsse

Cyx23

[Tim]

Hallo,

neuin, denn das würde besonders auf ein auch wieder unerwünschtes unflexibles Layout mit absoluten Positionierungen zutreffen

ja, aber die absoluten Positionierungen kann man ja über CSS wiederum verändern

Gruss
Tim

[Cyx23]

Hallo,

neuin, denn das würde besonders auf ein auch wieder unerwünschtes unflexibles Layout mit absoluten Positionierungen zutreffen

ja, aber die absoluten Positionierungen kann man ja über CSS wiederum verändern

mit absoluten Positionierungen sind m.E. überzeugende, einfache und nahezu pixelgenaue Lösungen für die meisten Browser dann möglich wenn ggf. per JavaScript angepasst und kontrolliert wird.
Bei der nach wie vor hohen Verbreitung von aktiviertem JavaScript wohl eine zulässige Strategie mit Restrisiko, ohne JavaScript sehe ich Vorteile für die Tabelle.

Grüsse

Cyx23

[Tim]

Hallo,

mit absoluten Positionierungen sind m.E. überzeugende, einfache und nahezu pixelgenaue Lösungen für die meisten Browser dann möglich wenn ggf. per JavaScript angepasst und kontrolliert wird.
Bei der nach wie vor hohen Verbreitung von aktiviertem JavaScript wohl eine zulässige Strategie mit Restrisiko, ohne JavaScript sehe ich Vorteile für die Tabelle.

Javascript habe ich noch nie für eine pixelgenaue Positionierung eingesetzt. JavaScript verwende ich nur für (teilweise) Eingabevalidierung und für bewegliche Navigation und sonstigen Schnickschnack.

Meiner Meinung nach ist eine pixelgenaue Positionierung allein mit CSS möglich. Kann sein, dass man für browserübergreifende Lösungen einiger CSS-Workarounds gebrauch machen muss, aber kein JS.

Gruss
tim

[Elya]

Hallo Tim,

Meiner Meinung nach ist eine pixelgenaue Positionierung allein mit CSS möglich. Kann sein, dass man für browserübergreifende Lösungen einiger CSS-Workarounds gebrauch machen muss, aber kein JS.

Verstehe ich Dich richtig, daß Du die ganze Zeit von fixen, pixelgenauen Layouts mit weitestgehend absoluter Positionierung sprichst?

Gruß aus Köln-Ehrenfeld,

Elya

[Tim]

Hallo Elya

Verstehe ich Dich richtig, daß Du die ganze Zeit von fixen, pixelgenauen Layouts mit weitestgehend absoluter Positionierung sprichst?

Ne, ursprünglich ging es mir nur um Tabellenlayout versus non Tabellenlayout. Falls ich mal absolute Positionierung benötige brauche ich aber kein JS dazu.

Tim

[chlori]

Hi

Meiner Meinung nach ist eine pixelgenaue Positionierung allein mit
CSS möglich.

Pixelgenaue Positionierung ist IMHO das fehlende Verständnis
für die Vorteile des Webs. Liquid Layout ist das andere.

Gruss
chlori

[at]

Hallo.

Pixelgenaue Positionierung ist IMHO das fehlende Verständnis
für die Vorteile des Webs. Liquid Layout ist das andere.

Das eine muss das andere ja nicht ausschließen. Zur pixelgenauen Positionierung zähle ich auch den gezielten Einsatz von "margin", "padding" und "border". Und solange Bild-Ressourcen meist besser in Pixeln bemessen werden, färbt dies häufig genug auch in sinnvoller Weise auf die genannten Attribute ab.
MfG, at

[Cyx23]

Hallo,

deine ursprüngliche Behauptung "mit <div>s ist man da freier als mit Tabellen, da man sie z.B. einfacher woanders positionieren kann wenn sich mal das Layout ändert" trifft wie schon gesagt besonders oder auch überspitzt formuliert _nur_ auf absolute Positionierung zu.

Insofern kommt die Idee der absoluten Positionierung von dir bzw. von deinen m.E. unrealistischen Anforderungen schneller Positionierung per CSS.

Und um genau diese Vorstellung erträglich oder barrierefei_er_ umzusetzen wäre JavaScript nötig (Netscape 4 kann ja hier als Sonderfall bei der Betrachtung Aussen vor bleiben).

Da du das (absolute Positionierung) offenbar doch nicht meintest bleibt die Frage wie du liquid Layout schneller und für alle Browser umpositionieren möchtest als es bei einer Tabelle möglich wäre, zumal bei der hier oft ungeeigneten (zumal ohne JavaScript) CSS-Unterstützung durch die IEs.

Grüsse

Cyx23

[chlori]

Hi

Und um genau diese Vorstellung erträglich oder barrierefei_er_
umzusetzen wäre JavaScript nötig

"Barrierefrei" und "JavaScript" in einem Satz? ;)

Gruss
chlori

[Cyx23]

Hallo,

Und um genau diese Vorstellung erträglich oder barrierefei_er_
umzusetzen wäre JavaScript nötig

"Barrierefrei" und "JavaScript" in einem Satz? ;)

und dazu besonders in dem Zusammenhang dass mittles JavaScript die Barrierefreiheit verbessert werden kann! >)

Grüsse

Cyx23

[Tim]

Hallo

Und um genau diese Vorstellung erträglich oder barrierefei_er_ umzusetzen wäre JavaScript nötig (Netscape 4 kann ja hier als Sonderfall bei der Betrachtung Aussen vor bleiben).

In dem Punkt gebe ich Dir Recht. Da ich bei der Entwicklung der Web-Seiten allerdings NS4 und IE4 abwärts ausser Acht lasse (Kundenwunsch) habe ich das Problem nicht.
Somit sind die Seiten nicht 100% barrierefrei. Welcher Kunde ist denn bereit dafür zu zahlen? Es ist schon schwer genug sie zu überzeugen, dass valider Code gut für sie ist.

Tim

[Cyx23]

Hallo Tim,

Und um genau diese Vorstellung erträglich oder barrierefei_er_ umzusetzen wäre JavaScript nötig (Netscape 4 kann ja hier als Sonderfall bei der Betrachtung Aussen vor bleiben).

In dem Punkt gebe ich Dir Recht. Da ich bei der Entwicklung der Web-Seiten allerdings NS4 und IE4 abwärts ausser Acht lasse (Kundenwunsch) habe ich das Problem nicht.

der Konjunktiv ("wäre nötig") bezieht auf "um genau diese Vorstellung" und nicht auf Netscape 4.

Die Aussage in Klammern bedeutet dass es einen _weiteren_ Grund für JavaScript gibt den ich aber gar nicht erörtert hatte ("Aussen vor bleiben").

Wenn du mir nun mit "In dem Punkt gebe ich Dir Recht" zugestimmt hast dass Browser wie der Internet Explorer, z.B. IE 6, (unter den vorher im Thread genannten Voraussetzungen eines üblichen tableless Layouts, bzw. wie von dir gewünscht schnell positionierbar) auf JavaScript angewiesen sind um trotz dürftiger CSS-Fähigkeiten an Usability und Barrierefreiehit zu gewinnen ist ja alles klar.

Grüsse

Cyx23

[Andreas-Lindig]

neuin, denn das würde besonders auf ein auch wieder unerwünschtes unflexibles Layout mit absoluten Positionierungen zutreffen
ja, aber die absoluten Positionierungen kann man ja über CSS wiederum verändern

sie bleibt aber absolut und das muß man eben sehen. Es ist weder besser noch schlechter, aber eben eingeschränkt. Mit CSS-absolut kann man dieses Mittelstreifendesign kreieren:

|------------------------------------|
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 | Weissraum |   Inhalt   | Weissraum |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |           |   Inhalt   |           |
 |------------------------------------|

naja, wenn's paßt. Aber, wenn sich die Seite dem Fenster anpassen soll, sieht das schon anders aus. Ich habe öfters gern ein Gestaltungsraster und da bleiben die Zellen - wenn sich eine ausdehnen muß - eben nur mit Tabelle in der Flucht.

Gruß, Andreas

[at]

Hallo.

naja, wenn's paßt. Aber, wenn sich die Seite dem Fenster anpassen soll, sieht das schon anders aus.

Üben! ;-)
MfG, at

[Andreas-Lindig]

Üben! ;-)

das sag ich den Brausern ja auch immer, aber sie tun einfach zu wenig ;-)

Gruß, Andreas

[Elya]

Hallo Tim,

gerade noch einen interessanten Artikel dazu gefunden:

http://www.andybudd.com/archives/2004/05/an_objective_look_at_table_based_vs_css_based_design/index.php

Gruß aus Köln-Ehrenfeld,

Elya

[Stefan Muenz]

Hallo Elya,

http://www.andybudd.com/archives/2004/05/an_objective_look_at_table_based_vs_css_based_design/index.php

Interessanter Artikel. Wobei alle Argumente, egal ob pro oder contra, fuer mich immer etwas subjektiv klingen. Der Artikel kann allerdings helfen, die Dinge einfach pragmatischer zu sehen. CSS-basierte Layouts sind moderner und bei Projekten mit vielen einheitlichen Seiten wegen der zentralen Definierbarkeit effizienter. Dagegen wuerde ich bei einem Formular, wo ich Feldbeschriftungen und Felder gegeneinander ausrichten will, niemals anfangen mit dem Gefloate, sondern bleibe schoen brav bei Tabellen. Ebenso, wenn ich z.B. Thumbnail-Bilder mit zugeordneten Bildunterschriften auf einer Seite verteilen will.

Mit Argumenten, dass CSS-basierte Layouts weniger HTML-Code enthalten und damit bei Suchmaschinen beliebter sind, waere ich uebrigens vorsichtig: die gleichen Argumente koennte man naemlich auch fuer die so verpoenten frames-basierte Seiten anfuehren (also bitte aufpassen, dass der Schuss nicht nach hinten los geht ;-). Denn kaum eine Seite enthaelt weniger Layout-Code als eine, die einfach als Textinhalt in einem Frameset angezeigt wird.

viele Gruesse
  Stefan Muenz

[Elya]

Hallo Stefan,
danke für Deine Antwort.

Interessanter Artikel. Wobei alle Argumente, egal ob pro oder contra, fuer mich immer etwas subjektiv klingen. Der Artikel kann allerdings helfen, die Dinge einfach pragmatischer zu sehen.

letzteres ist es, was mir daran gefallen hat, und deshalb habe ich ihn übersetzt (http://www.visuelya.de/pgs/item.php?id=00080). Der "subjektive" Blick ergibt sich vermutlich aus der täglichen Arbeit in der Agentur, die meist weder allzuviele Experimente noch einen zu radikalen Ansatz erlaubt. Wobei weder Andy noch ich im Verdacht stehen dürften, Tabellenlayouts zu favorisieren ;) - Was ist aber dann in diesem Fall ein "objektiver" Blick? Klar sind Pro- und Contra-Argumente subjektiv. Wer aber beide Arbeitsweisen gut kennt, die Argumente gegeneinander abwägt und dies aber aus einer praxisorientierten Perspektive tut, ist der schon subjektiv? Oder kann nur der echt objektiv sein, der nicht in die Dinge involviert ist?

Obwohl ich Chräckers Meinung aus [pref:t=81349&m=473282]

Aber ich habe die Erfahrung, auch hier im Laufe der Zeit, gemacht, das diese "elitären Gedankengebilde" letztendlich dann doch wieder postiven Einfluß haben, in unserer Sichtweise, wie Alltagsdinge gestaltet werden müssen.

zustimme, habe ich manchmal den Eindruck, daß die Diskussion hier gelegentlich etwas aus dem Ruder läuft. Ich kann mich des Eindrucks nicht erwehren, daß einige der ganz "jungen Radikalen", die sich so vehement dem vorherrschenden puristischen "Anti-Tabellen-Mainstream" angeschlossen haben und das jeden, der noch der "alten Lehre" anhängt, teils recht deutlich spüren lassen, noch nie eine komplexe CSS-Site für einen Kunden entwickelt haben, mit allen Anforderungen, Hochs und Tiefs, die dazu gehören.

Versteh mich bitte nicht falsch: es braucht Vordenker und "Radikale", und ohne die wären viele von uns "Pragmatikern" auch längst nicht da, wo wir heute stehen, aber ich bemerkte bei mir selbst, die ich eigentlich recht entspannt und praxisorientiert bin, schon diese radikale "Igitt - Tabellen"-Attitüde, die ja eigentlich nicht sein muß.

Deshalb, und weil er so zeit- und themennah an meinem ersten Diskusionsbeitrag in diesem Thread lag, fand ich Andys Zusammenfassung mal erfrischend anders und "unverkrampft".

Gruß aus Köln-Ehrenfeld und einen schönen Rest-Sonntag,

Elya

[Cyx23]

Hallo Elya,

Tableless Layout ist zum einen immer nur gelegentlich kritisch hinterfragt
worden, zum anderen ist es aber schon lange auch als Lösung für den Mainstream
vielleicht nicht umfassend verbeitet, aber dennoch etabliert. Ich würde als
Zeitpunkt 2001 oder noch früher ansetzen, also midestens drei Jahre Tableless
Layout. Ein W3C "howto", welches Tableless Layout ansatzweise als Liquid
Layout darlegt, wurde Anfang 2002 veröffentlicht [1], die "Semantic Web
Road map" von Berners-Lee [2] bereits 1998.

Eine "Igitt-Tabellen"-Attitüde im Jahre 2004 wie du sie gelegentlich
bemerkst ist da inzwischen schon recht konservativ.

Mittlerweile können also auch die Tableless-Layout Pragmatiker Bilanz ziehen
und die Unstimmigkeiten und Nachteile des Tableless-Layout reflektieren und
entsprechend auch die Vorzüge der Tabelle formulieren, und sei es als
"elitäre Gedankengebilde".

Eine solche Bilanz müsste hinsichtlich CSS und der damit verbunden Ansprüche
oder Hoffnungen schon deshalb zunächst katastrophal ausfallen weil mit
normalem CSS ein übliches "Layout" unter verschiedenen Browsern noch
nicht mal ähnlich ausfällt.

Ein grundsätzlicher Purismus kann oft als Folge des CSS nicht einmal auf das
HTML angewandt werden, die Hilfscontainer und Divs und Dummies statt Tabellen
dürften auch die Maschinenlesbarkeit nur etwas verbessern, die Behauptung
einer Trennung von Form und Inhalt wird selbst auf der niedrigsten Ebene,
dem Code, ad absurdum geführt.

Und hier in diesem Forum werden bei Diskussionen wie dieser die Nachteile
von CSS immer wieder verdrängt, was die Chancen (eigentlich nötiger)
konzeptioneller Überlegungen zu dem Thema leider nicht verbessert.

Grüsse

Cyx23

[1] http://www.w3.org/2002/03/csslayout-howto
[2] http://www.w3.org/DesignIssues/Semantic.html

[Elya]

Hallo Cyx23,

Tableless Layout ist zum einen immer nur gelegentlich kritisch hinterfragt
worden, zum anderen ist es aber schon lange auch als Lösung für den Mainstream
vielleicht nicht umfassend verbeitet, aber dennoch etabliert. Ich würde als
Zeitpunkt 2001 oder noch früher ansetzen, also midestens drei Jahre Tableless
Layout.

OK, da ich etwa zu diesem Zeitpunkt gerade mal von Golive wegkam und hier mein erstes Posting abgesetzt habe, habe ich diese Entwicklung nicht von Anfang an verfolgt (Ich hatte Probleme, meine Tabellen und Frames in den Griff zu kriegen *g*)

Ein W3C "howto", welches Tableless Layout ansatzweise als Liquid
Layout darlegt, wurde Anfang 2002 veröffentlicht [1], die "Semantic Web
Road map" von Berners-Lee [2] bereits 1998.

Bis es dann am Boden der Realität ankommt, dauert es aber doch meist _sehr_ lange, oder? Danke für die Links.

Mittlerweile können also auch die Tableless-Layout Pragmatiker Bilanz ziehen
und die Unstimmigkeiten und Nachteile des Tableless-Layout reflektieren und
entsprechend auch die Vorzüge der Tabelle formulieren,

genau das hat Andy Budd getan, und das fand ich daran so reizvoll - viel von dieser Art der Reflektion hatte ich bis vor ein paar Tagen nämlich noch nicht gelesen (bis auf den Beitrag von Zeldman, der aber eher humoristisch gefärbt war).

"elitäre Gedankengebilde".

kann es sein, daß ich mit dem Begriff "elitär" hier einigen auf die Füße gestiegen bin? ;-)

[...]

Und hier in diesem Forum werden bei Diskussionen wie dieser die Nachteile
von CSS immer wieder verdrängt, was die Chancen (eigentlich nötiger)
konzeptioneller Überlegungen zu dem Thema leider nicht verbessert.

ACK. Ich würde mich freuen, wenn sich in dieser Diskussion noch der eine oder andere konzeptionelle Gedanke wiederfände.

Gruß aus Köln-Ehrenfeld,

Elya

[Cyx23]

Hallo Elya,

OK, da ich etwa zu diesem Zeitpunkt gerade mal von Golive wegkam und hier mein erstes Posting abgesetzt habe, habe ich diese Entwicklung nicht von Anfang an verfolgt (Ich hatte Probleme, meine Tabellen und Frames in den Griff zu kriegen *g*)

verstärkt hat sich der Wunsch nach Tableless Layout durch die allgemeine Entwicklung zu richtigem HTML und durch das Thema Barrierefreiheit, da wurde ja meist pauschal einem Tableless Layout ein Plus an Barrierefreiheit unterstellt. Leider ist das Forums-Archiv von 2001 unvollständig, vielleicht fehlt sogar etwas von 2002 oder es ist nicht alles archiviert worden, sonst könnte ich verlässlicher nachschauen ob und wie sich das hier im Forum dargestellt hat; für mich war jedenfalls 2001 bis 2002 immer deutlicher geworden dass hinsichtlich Netscape 4 Bedarf nach W3C-konformen Anpassungen, auch für Tableless Layout, besteht.

Ein W3C "howto", welches Tableless Layout ansatzweise als Liquid
Layout darlegt, wurde Anfang 2002 veröffentlicht [1], die "Semantic Web
Road map" von Berners-Lee [2] bereits 1998.
Bis es dann am Boden der Realität ankommt, dauert es aber doch meist _sehr_ lange, oder? Danke für die Links.

Das Beispiel des W3C verwendet interessanterweise statt der zur Verwendung von CSS propagierten Trennung von Form und Inhalt doch einen Inlinestyle, ausgerechnet beim Image-Tag steht style="float: left;", was Netscape 4 im Gegensatz zu einem Eintrag im CSS bei dieser Seite Probleme verursachen kann. Statt also Netscape 4 das CSS zugänglich zu machen ein unnötiger Rauschmeisser per Inlinestyle. Noch einfacher als Cross-Browser Lösung wäre ein "align=left", was beim Vergleich zu <img style="float: left;" ... > zeigt wie lächerlich "richtiges HTML" -oder die betr. Diskussion- sein kann.

Beim Semantic Web ist m.E. noch unklarer was warum am von dir erwähnten Boden der Realität ankommen soll. Letztendlich geht es um Maschinenlesbarkeit, mir fallen da als typische Vertreter Google und Vorlesesoftware ein, die sich beide aber gar nicht so sehr an Tabellen stören.

Mittlerweile können also auch die Tableless-Layout Pragmatiker Bilanz ziehen
und die Unstimmigkeiten und Nachteile des Tableless-Layout reflektieren und
entsprechend auch die Vorzüge der Tabelle formulieren,
genau das hat Andy Budd getan, und das fand ich daran so reizvoll - viel von dieser Art der Reflektion hatte ich bis vor ein paar Tagen nämlich noch nicht gelesen (bis auf den Beitrag von Zeldman, der aber eher humoristisch gefärbt war).

Eigentlich müßten sich hier im Forumsarchiv auch Postings zu dem Thema finden lassen, aber vielleicht keine umfassende Diskussion.

"elitäre Gedankengebilde".
kann es sein, daß ich mit dem Begriff "elitär" hier einigen auf die Füße gestiegen bin? ;-)

Weiß ich nicht. Wenn sich hier "elitäre Gedankengebilde" oder "Radikale" oder wovon noch die Rede war darauf beschränken besonders puristisch eine reine Lehre o.ä. zu propagieren ist das m.E. weder zukunftweisend noch praktikabel.

Und hier in diesem Forum werden bei Diskussionen wie dieser die Nachteile
von CSS immer wieder verdrängt, was die Chancen (eigentlich nötiger)
konzeptioneller Überlegungen zu dem Thema leider nicht verbessert.
ACK. Ich würde mich freuen, wenn sich in dieser Diskussion noch der eine oder andere konzeptionelle Gedanke wiederfände.

Mich würde dabei z.B. auch interessieren welchen Mehrwert sauberes HTML hat, insbesondere ob im Weiteren der Verzicht auf Container Divs und <br style="float:.. usw. zu einer unwichtigen Quellcodeästhetik führt, also zum Selbstzweck verkommt, oder nicht.

Grüsse

Cyx23

[Elya]

Hallo Cyx23,

anscheinend geht das Thema gerade in den einschlägigen Weblogs rund, jetzt hat auch Zengarden-Guru Dave Shea sich geäußert:

http://www.mezzoblue.com/archives/2004/05/13/gasp_tables/
und der Nachfolge-Artikel, bei dem Shea auch ein Beipiel für eine "sinnvolle" Tabellenverwendung gibt:
http://www.mezzoblue.com/archives/2004/05/15/tables_oh_th/

Interessanterweise bezieht er sich wieder auf Andy, der "Inner Circle" ist doch ziemlich klein ;-)

Besonders interessant finde ich den Absatz über den semantischen Vergleich divs/tds weiter unten, in Bezug auf ein mehrspaltiges Layout:

[...]
Using a table for tabular data is universally accepted as being proper use of a table. Which carries with it the assumption that the table is structural and not presentational in that case. Fair enough.

But if tabular data is structurally tabular, then what inherently (besides a fear of the past) makes a two- or three-column layout structurally non-tabular? Two columns invariably end up in a pair of <div>s, or a pair of <td>s. What makes the former structural, but the latter any less so? A pair of <div>s implies two distinct, separated blocks of structure; a pair of <td>s does the same,
[...]

Ein mehrspaltiges Layout als eine Art Tabellenstruktur zu sehen, finde ich ziemlich interessant, zumal dann eine Tabelle sogar sinnvoller wäre als ein semantisch sinnfreies <div>.

Gruß aus Köln-Ehrenfeld,

Elya

[at]

Hallo.

Ein mehrspaltiges Layout als eine Art Tabellenstruktur zu sehen, finde ich ziemlich interessant, zumal dann eine Tabelle sogar sinnvoller wäre als ein semantisch sinnfreies <div>.

Ist es also den Fachleuten nach Jahren endlich gelungen, eine gute Begründung für die Verwendung von Tabellen zu diesem Zweck zu finden? Nein, das kann ich nicht nachvollziehen.
HTML hat nicht für jeden Zusammenhang, in dem mehrere Inhalte zusammenhängen können, ein eigenes Element zur Verfügung. Deswegen aber irgendeinen Sinn herbei zu interpretieren, statt ein neutrales Element zu verwenden, halte ich für Unfug.
Stattdessen sollte die Autoren dazu übergehen, bestimmte Klassen und ID für bestimmte Zwecke zu reservieren, etwa "navigation", "footer" etc., um einen Quasi-Standard zu etablieren.
Dass man auf das W3C nicht warten muss, zeigen ja unter anderem Dublin Core oder der Erfolg von RSS.
MfG, at

[Elya]

Hallo at,
sag mal, kann es sein, daß ich auf Deiner Whitelist gelandet bin? ;-) Du liest ja anscheinend jeden meiner Beiträge (nicht, daß mich das stören würde...)

Ist es also den Fachleuten nach Jahren endlich gelungen, eine gute Begründung für die Verwendung von Tabellen zu diesem Zweck zu finden? Nein, das kann ich nicht nachvollziehen.

Es ging um die konstruktive konzeptionelle Auseinandersetzung, und dieses Argument schien mir neu und diskussionswürdig. Die übermäßige Verwendung  von "neutralen Elementen" ist ja auch nicht ganz unumstritten.

HTML hat nicht für jeden Zusammenhang, in dem mehrere Inhalte zusammenhängen können, ein eigenes Element zur Verfügung. Deswegen aber irgendeinen Sinn herbei zu interpretieren, statt ein neutrales Element zu verwenden, halte ich für Unfug.

Ja, aber ist das so abwegig, drei _Spalten_ eines Layouts als eine Art Tabellenstruktur zu interpretieren? Ein zusammenfallender Header, drei Spalten mit den Inhalten, eine zusammenfallende Fußzeile mit Meta-Daten, Fußnoten etc. - So sehen Tabellen aus. OK, ich bin jetzt wieder bei Präsentation, also anders: stehen die Spalten in so einem Fall in einer Relation, wie bei tabellarischen Daten üblicherweise? Ist das eine notwendige Bedingung für eine "echte" Tabelle?

Stattdessen sollte die Autoren dazu übergehen, bestimmte Klassen und ID für bestimmte Zwecke zu reservieren, etwa "navigation", "footer" etc., um einen Quasi-Standard zu etablieren.

das wiederum finde ich einen schönen Ansatz, ich könnte mir vorstellen, daß das durchaus Anhänger fände.

Gruß aus Köln-Ehrenfeld,

Elya

[at]

Hallo.

sag mal, kann es sein, daß ich auf Deiner Whitelist gelandet bin? ;-)

Ja, gerade eben ;-)

Du liest ja anscheinend jeden meiner Beiträge (nicht, daß mich das stören würde...)

Im Augenblick habe ich wieder etwas Zeit und lese etwa zwei Drittel aller Threads -- vollständig und von unten nach oben. Alle anderen blende ich manuell aus. Durch diese Vorgehensweise komme ich zwar selten aus dem Forum-Keller, bin aber im Augenblick schon in der oberen Hälfte des Forums angelangt.
Und: Ja, dein Name ist ein verlässlicher Indikator für interessante Themen.

Es ging um die konstruktive konzeptionelle Auseinandersetzung, und dieses Argument schien mir neu und diskussionswürdig. Die übermäßige Verwendung  von "neutralen Elementen" ist ja auch nicht ganz unumstritten.

Natürlich. Meine Darstellung war etwas übertrieben.

HTML hat nicht für jeden Zusammenhang, in dem mehrere Inhalte zusammenhängen können, ein eigenes Element zur Verfügung. Deswegen aber irgendeinen Sinn herbei zu interpretieren, statt ein neutrales Element zu verwenden, halte ich für Unfug.

Ja, aber ist das so abwegig, drei _Spalten_ eines Layouts als eine Art Tabellenstruktur zu interpretieren? Ein zusammenfallender Header, drei Spalten mit den Inhalten, eine zusammenfallende Fußzeile mit Meta-Daten, Fußnoten etc. - So sehen Tabellen aus. OK, ich bin jetzt wieder bei Präsentation, also anders: stehen die Spalten in so einem Fall in einer Relation, wie bei tabellarischen Daten üblicherweise? Ist das eine notwendige Bedingung für eine "echte" Tabelle?

Der entscheidende Teil meiner Definition -- nun, jedenfalls der Definition, die ich mir zu eigen gemacht habe -- ist die Frage nach dem Wunsch des Autoren, die Inhalte der Tabellenzellen durch den Leser in vergleichender Weise miteinander in Verbindung gebracht zu wissen.
Auf Grund dieser Definition verwende ich auch keine Tabellen für Listen von Adressen und Telefonnummern. -- Wer sollte die vergleichen wollen? Warum soll ich sie also innerhalb eines Elementes präsentieren, das eine solche Vorgehensweise nahelegt?

Stattdessen sollte die Autoren dazu übergehen, bestimmte Klassen und ID für bestimmte Zwecke zu reservieren, etwa "navigation", "footer" etc., um einen Quasi-Standard zu etablieren.
das wiederum finde ich einen schönen Ansatz, ich könnte mir vorstellen, daß das durchaus Anhänger fände.

Wir können die Methode ja in passenden Diskussionen weiterhin im Forum und anderswo propagieren -- "Bei dir oder bei mir?" ;-)
Vielleicht funktioniert es ja :-)
MfG, at

[Elya]

Hallo at,

Der entscheidende Teil meiner Definition -- nun, jedenfalls der Definition, die ich mir zu eigen gemacht habe -- ist die Frage nach dem Wunsch des Autoren, die Inhalte der Tabellenzellen durch den Leser in vergleichender Weise miteinander in Verbindung gebracht zu wissen.

ok, die Vergleichbarkeit der oder die Beziehung zwischen den Zeilen ist ein Argument, zumindest wenn wir von "reinen" Datentabellen ausgehen. Dave hatte den Begriff "structural data" wohl etwas weiter gefaßt, nämlich eine Struktur, in der zwei oder drei Blöcke nebeneinander stehen, und diese wäre in tds oder divs gleichermaßen strukturiert.

Hm. aber nehmen wir einmal ein recht schlichtes zweispaltiges Layout, in dem links eine Navigation und rechts der Inhalt steht. Eine Beziehung zwischen den beiden Bereichen ist schon vorhanden, oder?

Jetzt habe ich mich doch in den (Un-)Tiefen semantischer Betrachtungen verheddert, dabei wollte ich doch nur ein wenig mehr Gelassenheit und Praxisbezogenheit in der Diskussion anregen...

Gruß aus Köln-Ehrenfeld,

Elya

[at]

Hallo.

ok, die Vergleichbarkeit der oder die Beziehung zwischen den Zeilen ist ein Argument, zumindest wenn wir von "reinen" Datentabellen ausgehen. Dave hatte den Begriff "structural data" wohl etwas weiter gefaßt, nämlich eine Struktur, in der zwei oder drei Blöcke nebeneinander stehen, und diese wäre in tds oder divs gleichermaßen strukturiert.

"Nebeneinanderstehen" ist ein guter Begriff. Wenn ich eine Seite mit Tabellen strukturiere, ordne ich ja nicht nur zu, sondern suggeriere eine gewisse Gleichwertigkeit innerhalb einer Reihe oder Spalte. Dagegen schaffe ich mit eienr Reihe von <div>, oder natürlich anderen Elementen wie Listen, Absätzen etc.,  eher eine Hierarchie. -- Dünnes Eis, ich weiß. Aber ich halte diese Feinheiten für wichtig.

Hm. aber nehmen wir einmal ein recht schlichtes zweispaltiges Layout, in dem links eine Navigation und rechts der Inhalt steht. Eine Beziehung zwischen den beiden Bereichen ist schon vorhanden, oder?

Um es klar zu sagen: Ich kann mir sehr gut Anwendungsfälle vorstellen, in denen eine solche Struktur nicht nur gerechtfertigt ist, sondern andere Lösungen klar auf die Plätze verweist. Entscheidend ist für mich die Art der Beziehung, in der die Inhalte der Bereiche stehen sollen.

Jetzt habe ich mich doch in den (Un-)Tiefen semantischer Betrachtungen verheddert, dabei wollte ich doch nur ein wenig mehr Gelassenheit und Praxisbezogenheit in der Diskussion anregen...

Wenn du gelesen hast, was ich geschrieben habe, wirst du sehen, dass du dein Ziel nicht verfehlt hast :-)
Und: Nein, das muss nicht das Schlusswort gewesen sein ;-)
MfG, at

[Detlef G.]

Hallo Elya

Es ging um die konstruktive konzeptionelle Auseinandersetzung, und dieses Argument schien mir neu und diskussionswürdig. Die übermäßige Verwendung  von "neutralen Elementen" ist ja auch nicht ganz unumstritten.

Meiner unbedeutenden Meinung vor allen Dingen deshalb, weil diese einfach
ohne Notwendigkeit eingesetzt werden. Anstatt sinnvolle HTML-Auszeichnungen
zu verwenden und diesen dann mittels CSS zu formatieren und "neutrale
Elemente" nur dort zu verwenden wo diese zusätzlich nötig sind, scheinen
viele Seitenschreiber mit den Möglichkeiten von CSS vergessen zu haben, dass
es außer div und span noch andere Elemente gibt, oder packen alles noch
zusätzlich in diese Elemente, als ob nur diese mittels CSS formatiert werden könnten.

Ja, aber ist das so abwegig, drei _Spalten_ eines Layouts als eine Art Tabellenstruktur zu interpretieren?

Ich finde es abwegig.

Ein zusammenfallender Header, drei Spalten mit den Inhalten, eine zusammenfallende Fußzeile mit Meta-Daten, Fußnoten etc. - So sehen Tabellen aus.

Finde ich nicht, so sieht ein Kastenlayout aus.
Das was du hier beschreibst, ist eine Überschrift, dann drei Textblöcke
nebeneinander, eventuell drei Absätze, darunter weitere Daten, die sich
keiner einzelnen Spalte zuordnen lassen.
So etwas wird dann, wenn es dann eventuell noch mit Rahmen versehen wird,
fälschlicherweise oft als Tabelle bezeichnet, ist aber keine.
Es _sieht_ einer Tabelle ähnlich.

OK, ich bin jetzt wieder bei Präsentation, ...

Genau.
Das Problem dabei ist, dass wir vielleicht alle viel zu sehr visuell
orientiert sind.

...also anders: stehen die Spalten in so einem Fall in einer Relation, wie bei tabellarischen Daten üblicherweise?

Wohl kaum.
Welchen Bezug haben diese Spalten zueinander?
Entweder, es sind verschiedene Absätze oder Listen, wie beim klassischen
3-Spalten-Layout (z.B. Navigation, Content, News) ohne direkten Bezug
zueinander, oder, sie sind einfach nur Fließtext, vieleicht auch
aufeinanderfolgende Absätze, die willkürlich bzw. nach rein optischen
Gesichtspunkten auf die Spalten verteilt sind.

Ist das eine notwendige Bedingung für eine "echte" Tabelle?

Ja, denn sonst bestimmt die visuelle Präsentation die Struktur und nicht
die logische Struktur die Präsentation.

MFG
Detlef

[Elya]

Hallo Detlef,

Es ging um die konstruktive konzeptionelle Auseinandersetzung, und dieses Argument schien mir neu und diskussionswürdig. Die übermäßige Verwendung  von "neutralen Elementen" ist ja auch nicht ganz unumstritten.

Anstatt sinnvolle HTML-Auszeichnungen
zu verwenden und diesen dann mittels CSS zu formatieren und "neutrale
Elemente" nur dort zu verwenden wo diese zusätzlich nötig sind, scheinen
viele Seitenschreiber mit den Möglichkeiten von CSS vergessen zu haben, dass
es außer div und span noch andere Elemente gibt, oder packen alles noch
zusätzlich in diese Elemente, als ob nur diese mittels CSS formatiert werden könnten.

Stimmt, das begegnet mir oft in der Diskussion: wie, keine Tabellen mehr? Wie denn sonst? Divs? Einmal sogar: "H1? Ich dachte, das benutzt man gar nicht mehr"

Das Problem dabei ist, dass wir vielleicht alle viel zu sehr visuell
orientiert sind.

Die Frage ist aber auch, ob man Struktur und Präsentation wirklich und immer strikt getrennt halten kann oder ob nicht doch manchmal eines das andere bedingt.

...also anders: stehen die Spalten in so einem Fall in einer Relation, wie bei tabellarischen Daten üblicherweise?
Wohl kaum.
Welchen Bezug haben diese Spalten zueinander?
Entweder, es sind verschiedene Absätze oder Listen, wie beim klassischen
3-Spalten-Layout (z.B. Navigation, Content, News) ohne direkten Bezug
zueinander,

Navigation und Inhalt stehen in keinem Bezug? Aber ich sehe, worauf Du hinauswillst. Es war eben ein mir interessant erscheinender Gedanke, und Dave Sheah hat in seinem Artikel wohl eher den Strukturcharakter von tds und divs miteinander verglichen als auf die enge Diskussion von Tabellensemantik einzugehen.

Gruß aus Köln-Ehrenfeld,

Elya

[Detlef G.]

Hallo Elya

Stimmt, das begegnet mir oft in der Diskussion: wie, keine Tabellen mehr? Wie denn sonst? Divs? Einmal sogar: "H1? Ich dachte, das benutzt man gar nicht mehr"

Auch hier im Forum begegnet uns häufig die Frage, wie man ein Div-Layout
aufbaut oder man findet in geposteten Quelltexten nur Div-und Span-Suppen
ohne logische Formatierungen.

Die Frage ist aber auch, ob man Struktur und Präsentation wirklich und immer strikt getrennt halten kann oder ob nicht doch manchmal eines das andere bedingt.

Natürlich kann man dies nicht strikt trennen, in der Bedeutung von
Austauschbarkeit oder Unerheblichkeit, es bedingt sich wohl.
Ich stelle oft fest (auch bei mir selbst), dass sich eine Seite, ihr Inhalt
und Struktur an der Vorstellung einer visuellen Präsentation festmacht, und
es schwer fällt, die Struktur selbst zu erfassen, um dann diese Struktur
durch die visuelle Präsentation zu unterstreichen.

Die Struktur sollte die Präsentation bestimmen und nicht umgekehrt.

Dabei gehe ich allerdings von Seiten aus, bei denen die Information der
primäre Anspruch ist. Bei einer Seite, die HTML hauptsächlich für
künstlerische oder ähnliche Zwecke "missbraucht", kann durchaus die
Präsentation der eigentliche Inhalt sein und sich die Struktur dann auch
daraus ergeben.

Navigation und Inhalt stehen in keinem Bezug?

Nicht wirklich, der Inhalt genau dieser Seite hat meist keinen direkten
Bezug zur Navigation. Für Verweise, die direkte Bezüge des Seiteninhalts zu
anderen Seiten herstellen sind Links im Inhalt (z.B. Textlinks) vorgesehen.
Die Navigation ist eher dem gesamten Projekt zugehörig, nicht einem
bestimmten Inhalt der aktuellen Seite, wie die verschiedenen Spalten einer
Tabellenzeile.

MFG
Detlef

[Cyx23]

Hallo Detlef,

Auch hier im Forum begegnet uns häufig die Frage, wie man ein Div-Layout
aufbaut oder man findet in geposteten Quelltexten nur Div-und Span-Suppen
ohne logische Formatierungen.

semantisch richtiges und strukturierendes HTML ist natürlich weitgehend möglich und sinnvoll.
Oft werden aber zusätzliche Divs benötigt, die möglicherweise (ebenso wie Teile des CSS)
auch eine (geringe) semantische Aufgabe erfüllen.

Umgekehrt ist mir unklar wie verlässlich die fehlende semantische Bedeutung von Divs und Span
ist (etwa wenn Rahmen oder Hintergundfarbe nur so dargestellt werden können); zugleich müsste
der Anspruch eines Semantic Web mit dem begleitenden Argument einer besseren Wartbarkeit auch
eine bessere Übersichtlichkeit des HTML auch für Auswertung durch Menschen bedeuten, spätestens
da stören die oft nötigen Container-Divs und die bessere Wartbarkeit ist dann eigentlich auch
nicht mehr gegeben.

Die Struktur sollte die Präsentation bestimmen und nicht umgekehrt.

Die Präsentation wird ja -idealerweise auch vom Autor- meist vor der Veröffentlichung
überprüft. Die Präsentation kann als nichtzufällige Information verstanden werden, die vom
Autor beabsichtigt oder zumindest akzeptiert worden ist, jedenfalls bei der Interpretation
innerhalb des gleichen Kulturkreises.

[...] künstlerische oder ähnliche Zwecke "missbraucht", kann durchaus die
Präsentation der eigentliche Inhalt sein und sich die Struktur dann auch
daraus ergeben.

Dabei ist das m.E. kein Sonderfall sondern findet sich mehr oder weniger stark in den meisten
Projekten.

Navigation und Inhalt stehen in keinem Bezug?

Nicht wirklich, der Inhalt genau dieser Seite hat meist keinen direkten
Bezug zur Navigation. Für Verweise, die direkte Bezüge des Seiteninhalts zu
anderen Seiten herstellen sind Links im Inhalt (z.B. Textlinks) vorgesehen.
Die Navigation ist eher dem gesamten Projekt zugehörig, nicht einem
bestimmten Inhalt der aktuellen Seite, wie die verschiedenen Spalten einer
Tabellenzeile.

Navigation und Inhalt können als so gegensätzlich verstanden werden, dass Frames und
getrennte Dokumente dringend erforderlich sind.

Zugleich bedingen, benötigen sie aber einander, was sich sehr gut in einer zweispaltigen
Tabelle unsetzen lässt, sofern eine Tabelle überhaupt eine semantische Bedeutung hat, und
sofern eine solche vmtl. eher geringe semantische Bedeutung für das "Semantic Web" überhaupt
eine Rolle spielt.

Und anders betrachtet, die normale Einbindung eines Navigationsblocks in ein Dokument im
normalen HTML (statt etwa als <link..) kann auch als semantisch viel unrichtiger betrachtet
werden als die Platzierung der Navigation in einer eigenen Tabellenspalte.

Ein Tableless Layout ohne Frames bedeutet also womöglich nicht nur Layout- oder
Informationsverlust bei nicht berücksichtigten CSS-unfähigen Browsern und dazu oft
Darstellungsprobleme bei über 80% der Browser bis zum IE6, sondern beinhaltet wohl
auch eine semantisch eher falsche Umsetzung der Navigation.

Grüsse

Cyx23

[Ingo Turski]

Hi,

Ja, aber ist das so abwegig, drei _Spalten_ eines Layouts als eine Art Tabellenstruktur zu interpretieren?

in den meisten Fällen: Ja.

Ein zusammenfallender Header,

<Hx>

drei Spalten mit den Inhalten,

hierauf kommt es dann IMHO an. Stehen diese Spalten wirklich in einer konkreten Beziehung zueinander? Was auch impliziert: Ist diese Anordnung (links - mitte - rechts) wirklich erforderlich oder wäre jede andere Anordnung ebenso möglich? Meist wäre sie es ja: Menü muß nicht links sein, Inhalt nicht in der Mitte und was in der rechten Spalte steht, kann manchmal auch ganz wegfallen..;-)

eine zusammenfallende Fußzeile mit Meta-Daten, Fußnoten etc. - So sehen Tabellen aus.

findest Du Fußzeilen tatsächlich immer in typischen Tabellen? Ich nicht.

freundliche Grüße
Ingo

[Cyx23]

Hallo Elya,

Ja, aber ist das so abwegig, drei _Spalten_ eines Layouts als eine Art Tabellenstruktur zu interpretieren? Ein zusammenfallender Header, drei Spalten mit den Inhalten, eine zusammenfallende Fußzeile mit Meta-Daten, Fußnoten etc. - So sehen Tabellen aus. OK, ich bin jetzt wieder bei Präsentation, also anders: stehen die Spalten in so einem Fall in einer Relation, wie bei tabellarischen Daten üblicherweise? Ist das eine notwendige Bedingung für eine "echte" Tabelle?

da sehe ich mehrere Aspekte, zunächst die Unmöglichkweit der Trennung von Layout und Inhalt. Layout unterstützt Inhalt und hat damit oft schon inhaltliche Bedeutung, Layout selbst ist aber oft auch bereits Inhalt.

Dann der auch hier im Forum immer wieder aufgestellte Satz Tabellen wären nicht fürs "design" geschaffen, der in mehrfacher Hinsicht falsch ist.

Auch die hier im Forum kaum gestellte Frage wieweit sich Webdesigner handwerkliche Techniken wegen einer eigentlich nicht konkret begründeten Suche nach Semantic mit unklaren Zielvorgaben verkneifen sollen. Das geht wieder einher mit der geäusserten Behauptung was den HTML wäre und was nicht, was im Weiteren unnötigerweise zu firmenabhängigen Formaten wie Flash führt, wo dann erst der eigentliche Widerspruch der Verwendung oder eben Nichtverwendung von HTML entsteht.

Bei deinem Tabellenbeispiel kann natürlich noch der häufige Verzicht auf Frames betrachtet werden, hier könnte der möglichen Einschätzung dass Tabellen zur Umsetzung einer Framestruktur "mißbraucht" würden der Tabellencharakter von Frames entgegengehalten werden.

Schliesslich die Frage wie denn Konformität und Validität nach den Forderungen des W3C bewertet und gegen andere mögliche Qualtiäten von Code abgewogen werden können. Hinsichtlich des W3C scheint hier im Forum schon lange die Kritikfähigkeit begrenzt zu sein, was vielleicht mangels Alternativen sogar "richtig" sein mag. Dabei muss gerade diese Frage hinsichtlich der fragwürdigen Folgen wie CSS-Browser-Weichen und deren potenzieller Risiken sowie den erheblichen Leistungsdefiziten von CSS (oder CSS in Verbindung mit gebräuchlichen Browsern) ggf. anders oder neu gestellt werden.

Grüsse

Cyx23

[Christian Seiler]

Hallo Stefan,

Dagegen wuerde ich bei einem Formular, wo ich Feldbeschriftungen und Felder gegeneinander ausrichten will, niemals anfangen mit dem Gefloate, sondern bleibe schoen brav bei Tabellen.

</archiv/2002/12/32885/>

Viele Grüße,
Christian