Warum verwenden Google und Amazon Tabellen für das Layout?

[Rolf]

Hallo,

wie hier und anderswo ist oft die Meinung zu lesen, dass man Tabellen _ausschließlich_ zur Darstellung tabellarischer Daten verwenden sollte.
Dies richtet sich offensichtlich gegen den "Missbrauch" von Tabellen für Layoutzwecke.

Aus Sicht eines Informatikers ist das auch vollkommen einleuchtend.

Wenn ich mir nun aber einige "große" Sites anschaue sehe ich, dass die ihre Seiten teilweise mit Tabellen layouten.

Nun ist es durchaus nicht unmöglich, dass wir kleinen, smarten People den großen auch einmal etwas voraus haben können, als Erklärung reicht mir das aber noch nicht wirklich.

Warum verwenden z.B. Google und Amazon Tabellen für nichttabellarische Daten?

Gruß
Rolf

[Cybaer]

Hi,

wie hier und anderswo ist oft die Meinung zu lesen, dass man Tabellen _ausschließlich_ zur Darstellung tabellarischer Daten verwenden sollte.

Ja ja ...

Aus Sicht eines Informatikers ist das auch vollkommen einleuchtend.

Informatikern sagt man auch oft nach, ein wenig weltfremd zu sein.

Nun ist es durchaus nicht unmöglich, dass wir kleinen, smarten People den großen auch einmal etwas voraus haben können, als Erklärung reicht mir das aber noch nicht wirklich.

Es gibt, wie meistens, Gründe Pro & Contra.

Aus meiner Sicht spricht für Tabellenlayout, daß es "robuster" ist. D.h.:

• daß Content irgendwo "overflowed" ist in TL faktisch nicht existent, in reinen CSS-Seiten ein häufig zu sehendes Ärgerniss.
• TL-Seiten sehen auch in Non-CSS-Browsern noch (mehr oder weniger) so aus, wie der Autor/die Marketingabteilung es wünscht. Der Informatiker als solcher meint hingegen, eine rein semantische Darstellung (Menu ggf. auch als nackte OrderedList) sei akzeptabel.

Aus meiner Sicht gegen TL spricht, daß es weniger fluid ist. Zwar kann man es auch beim TL (wenn man will) problemlos so machen, daß Fonts problemlos skalieren, aber bei Browser auf kleinen Displays, kommt man irgendwann an eine Grenze (mit reinem CSS kann man hingegen z.B. die rechte "Werbe-Spalte" unter den Content, und den unter die linke "Menü-Spalte" fließen lassen, wenn die Auflösung zzu klein wird.

Allerdings haben gerade größere Auftritte oft sinnigerweise ohnehin ein separates Layout (wenn nicht gar separates Angebot) für "kleine" Clients, sodaß sich hier keine wirkliche Notwendigkeit ergibt.

Die Trennugn von Layout & Content ist für mich kein Argument. Die Trennung findet bereits vorher statt. D.h., welches Layout der Browser letztlich bekommt, sollte vom Content so oder so unabhängig sein ...

Gruß, Cybaer

[LX]

Wenn Google oder Amazon Tabellen für nichttabellarische Daten verwenden, kann das 3 mögliche Gründe haben:

• Die jeweiligen Seiten sind so alt, dass sie vor dem Durchbruch von CSS-basierten Layouts erstellt wurden
• Man hat sich aus anderen Gründen für eine Tabelle entschieden (in manchen Fällen hat man bereits ein Modul, welches ordentliche Tabellen liefert und möchte dieses lieber exzessiv nutzen, als ein neues Modul für semantisches Layout zu entwickeln).
• Die verantwortlichen Entwickler sind zu semantischem Markup unfähig.

Gruß, LX

[Rolf]

Hi,

Wenn Google oder Amazon Tabellen für nichttabellarische Daten verwenden, kann das 3 mögliche Gründe haben:

Ich kann mir das bei den "Giganten Google und Amazon wirklich nicht vorstellen.

• Die jeweiligen Seiten sind so alt, dass sie vor dem Durchbruch von CSS-basierten Layouts erstellt wurden

Die investieren so viel in neueste Technik, da werden die doch nicht eine alte Website einfach der Bequemlichkeit wegen lassen wie sie ist. Ist doch irgendwie auch eine Art Aushängeschild (zumindest für die die den Quellcode verstehen können)

• Man hat sich aus anderen Gründen für eine Tabelle entschieden (in manchen Fällen hat man bereits ein Modul, welches ordentliche Tabellen liefert und möchte dieses lieber exzessiv nutzen, als ein neues Modul für semantisches Layout zu entwickeln).

Siehe oben.

• Die verantwortlichen Entwickler sind zu semantischem Markup unfähig.

Wenn die sich keine wirklich guten Entwickler leisten können, wer dann?

Ne, diese Gründe kann ich mir nicht vorstellen.

Gruß
Rolf

[suit]

• Man hat sich aus anderen Gründen für eine Tabelle entschieden (in manchen Fällen hat man bereits ein Modul, welches ordentliche Tabellen liefert und möchte dieses lieber exzessiv nutzen, als ein neues Modul für semantisches Layout zu entwickeln).
  Siehe oben.

hast du schon mal versucht eine seite mit sagen wir 30.000 unterseiten neu zu machen und von einem alten layout auf ein neues umzustellen?

[Beat]

hast du schon mal versucht eine seite mit sagen wir 30.000 unterseiten neu zu machen und von einem alten layout auf ein neues umzustellen?

Du willst mir echt nicht sagen, dass Google 30'000 Seiten händisch erstellt?

Nö. die werden überall ihr CMS einsetzen.

mfg Beat

[suit]

Du willst mir echt nicht sagen, dass Google 30'000 Seiten händisch erstellt?

Nö. die werden überall ihr CMS einsetzen.

das ist mir schon klar - aber nimm amazon als beispiel - die artikeldaten selbst liegen sicher nicht sauber getrennt in der datenbank vor - da sind wahrscheinlich bei 90% die visuellen informationen hardcodiert drinnen - so einfach auf die schnelle umstellbar ist das nicht - bei der menge artikel sind auch viele alte artikel dabei - die müsste man wahrscheinlich alle neu eingeben und verfassen

bei einer seite dieser dimension ist es einfach nicht möglich mal schnell zu relaunchen

[Cybaer]

Hi,

das ist mir schon klar - aber nimm amazon als beispiel - die artikeldaten selbst liegen sicher nicht sauber getrennt in der datenbank vor - da sind wahrscheinlich bei 90% die visuellen informationen hardcodiert drinnen

Sorry, aber das kann ich mir echt nicht vorstellen.

Hast Du schon mal einen Shop/CMS programmiert? Da was "händisch" zu machen, insbesondere bei der Größe von Amazon, ist doch vollkommen neben der Kappe. IMHO kommt niemand bei auch nur halben Verstand auf so eine Idee - und ich glaube auch nicht, daß Amazon da zu Beginn bereits Leute mit nicht mal halben Verstand daran gesetzt hat, bzw. es nie nötig befand, das, falls doch, zu ändern ...

Gruß, Cybaer

[suit]

Hast Du schon mal einen Shop/CMS programmiert? Da was "händisch" zu machen, insbesondere bei der Größe von Amazon, ist doch vollkommen neben der Kappe. IMHO kommt niemand bei auch nur halben Verstand auf so eine Idee - und ich glaube auch nicht, daß Amazon da zu Beginn bereits Leute mit nicht mal halben Verstand daran gesetzt hat, bzw. es nie nötig befand, das, falls doch, zu ändern ...

die inhalte werden ja sicher nicht händisch gewartet, aber sicher durch ein tool generiert - es reicht ja auch ein simpler wysiwyg-editor im permament dämlichen code in die datenbank zu bannen - der fck-editor in alten versionen ist zb ein guter kandidat dafür

[Cybaer]

Hi,

die inhalte werden ja sicher nicht händisch gewartet, aber sicher durch ein tool generiert - es reicht ja auch ein simpler wysiwyg-editor im permament dämlichen code in die datenbank zu bannen - der fck-editor in alten versionen ist zb ein guter kandidat dafür

Ich gehe fest davon aus, daß solche Seiten (oder Teile davon) *nicht* mit solchen Tools in Berührung kommen. Oder anders und aus eigener Erfahrung gesagt: Bei einem CMS kann ich mir das noch vorstellen, bei einem Shop aber nicht.

Da liegen die nackten Daten in irgendeinem allg. Format in einer Datenbank, und mit diesen Daten werden Templates nach Wahl gefüllt und ausgegeben. Ob die Templates nun in WML, HTML oder XHTML gecodet sind, spielt da keine Rolle.

Meine allererste Webanwendung war ein Shop, und da war das von meiner Logik her geradezu zwangsläufig. Bei Amazon dürften sich vermutlich keine Nulpen an sowas "mal versucht" haben. Es macht jedenfalls ansonsten nicht den Eindruck ...

Gruß, Cybaer

[Rolf]

hast du schon mal versucht eine seite mit sagen wir 30.000 unterseiten neu zu machen und von einem alten layout auf ein neues umzustellen?

Nein, aber bei Google scheint mir das Verhältnis von erforderlichen Aufwand und Googles Möglichkeiten nicht der Grund für das Verwenden einer "falschen" Technologie zu sein.

[suit]

hast du schon mal versucht eine seite mit sagen wir 30.000 unterseiten neu zu machen und von einem alten layout auf ein neues umzustellen?
Nein, aber bei Google scheint mir das Verhältnis von erforderlichen Aufwand und Googles Möglichkeiten nicht der Grund für das Verwenden einer "falschen" Technologie zu sein.

damit hast du recht - aber hast du dir schon mal den code der google-startseite angesehen? da wird code gespart wos nur geht, 1-buchstaben-variablen-namen im javascript, jeder unnötige umbruch und jedes unnötige leerzeichen wird entfernt

das hat sicher auch traffic gründe und spart denen geld - die sind denke ich geizig bis zum gehtnichtmehr ;)

[Beat]

... aber hast du dir schon mal den code der google-startseite angesehen? da wird code gespart wos nur geht, 1-buchstaben-variablen-namen im javascript, jeder unnötige umbruch und jedes unnötige leerzeichen wird entfernt
das hat sicher auch traffic gründe und spart denen geld - die sind denke ich geizig bis zum gehtnichtmehr ;)

... Offenbar nicht zu geizig, um mit Interpunktion zu sparen.

mfg Beat

[suit]

... Offenbar nicht zu geizig, um mit Interpunktion zu sparen.

ich verfasse meine texte im stil eines inneren monologes, da ist interpunktion hinterlich - wenn du auf das anspielst :D

[Gunnar Bittersmann]

@@suit:

da ist interpunktion hinterlich

▲
'.' steht in der Tat oft ganz hinten.

Live long and prosper,
Gunnar

[Thorsten Schleppi]

Hallo!

Die investieren so viel in neueste Technik, da werden die doch nicht eine alte Website einfach der Bequemlichkeit wegen lassen wie sie ist. Ist doch irgendwie auch eine Art Aushängeschild (zumindest für die die den Quellcode verstehen können)

Hast du schonmal die Google oder Amazon Startseite durch den Validator gejagt?
Von wegen Aushängeschild...

Viele Grüße
Thorsten

[Cybaer]

Hi,

Hast du schonmal die Google oder Amazon Startseite durch den Validator gejagt?
Von wegen Aushängeschild...

Nach einem kurzen Blick auf das Google-Ergebnis: Man sollte Validatoren nicht nur nutzen, sondern die Ergebnisse auch interpretieren können! (Jedenfalls bevor man sich drüber ausläßt.)

Der einzige wirkliche Verstoß, ist, daß in URLs das "&" nicht als "&" codiert wird (wobei das früher eh nicht üblich war, und ich spontan nicht weiß, ob es nicht auch Clients gibt, die eher über "&" stolpern). Praktisch hat das keinen negativen Effekt.

Wenn man der Meinung ist, nicht HTML 4.01 coden zu wollen (und das W3C einem sowieso am Arsch vorbei geht), dann ist die Seite ansonsten problemloses HTML (auch wenn das W3C, und alle seine Jünger, dagegen wettern würden*)).

Diese Haltung ist in der Praxis recht häufig verbreitet (zu ca. 90% - oder was weiß ich - bitte in der Google-Web-Statistik nachlesen).

Gruß, Cybaer

*) Haaach, wenn das HTML nicht dem W3C-Standard entspricht, dann ist es gar nicht HTML, bla, blubb, etc. ...

PS: Aber natürlich ist es gerade für den Einsteiger sinnvoll, valides HTML 4.01 (bzw. besser: HTML 5) zu coden. Er weiß ja sonst eh nicht, was er darf und was nicht, bzw. was problematisch ist, und was nicht.
PPS: Wenn mir jemand den Google-Code zur Abnahme vorlegen würde, würde ich sicherlich die Nase rümpfen, aber verweigern würde ich sie nicht. Und das ist (leider) nicht die Regel ... (will heißen: Im Vergleich zu dem, was professionelle Entwickler so abliefern, ist das noch geleckt ...)

[Gunnar Bittersmann]

@@Cybaer:

Der einzige wirkliche Verstoß, ist, daß in URLs das "&" nicht als "&" codiert wird (wobei das früher eh nicht üblich war, […]).

An welcher Stelle der SGML-Spec steht, dass '&' als Zeichen nicht escapet werden muss, wenn es nicht gerade vor Whitespace steht?

Und was meinst du mit „früher“?

„The & character can be included in its own right using the named character entity &.“ [HTML32] Früh genug?

Live long and prosper,
Gunnar

[Cybaer]

Hi,

Der einzige wirkliche Verstoß, ist, daß in URLs das "&" nicht als "&" codiert wird (wobei das früher eh nicht üblich war, […]).

An welcher Stelle der SGML-Spec steht, dass '&' als Zeichen nicht escapet werden muss, wenn es nicht gerade vor Whitespace steht?

An keiner. Deswegen schrieb ich ja auch, daß das der einzige wirkliche Verstoß sei.

Und was meinst du mit „früher“?

Als Amazon entstand (ungefähr zum gleichen Zeitpunkt fing ich auch mit dem Web an - das war vor ca. 12 Jahren). Damals ...

„The & character can be included in its own right using the named character entity &.“ [HTML32] Früh genug?

... gab es noch nicht mal HTML 2. :) Von HTML 3.2 ganz zu schweigen.

Davon abgesehen ist es aber nicht das, was ich meine. Ich meine nicht die Theorie, sondern die Praxis. Und das "&" in URLs nicht zu kodieren, ist selbst heute noch der wohl mit Abstand häufigste Fehler, den man bei Webautoren antrifft.

Und falls ein Browser darüber stolpert, mag es ein tolles SGML-Tool sein, aber als HTML-Browser für die Praxis reichlich verfehlt.

Gruß, Cybaer

[Gunnar Bittersmann]

@@Cybaer:

Und das "&" in URLs nicht zu kodieren, ist selbst heute noch der wohl mit Abstand häufigste Fehler, den man bei Webautoren antrifft.

Der eigentliche Fehler* liegt nicht bei den Webautoren, sondern den Browser- und Script- und ...-entwicklern, überhaupt mit '&' ein Zeichen zur Trennung von Key-Value-Paaren zu verwenden, das in HTML eine Sonderbedeutung hat.

Wenn dafür einfach ';' verwendet werden würde, wie es [HTML401 §B.2.2] empfiehlt, bestünde das Problem gar nicht.

Live long and prosper,
Gunnar

* kann man durchaus schon als Dummheit bezeichnen

[suit]

Wenn dafür einfach ';' verwendet werden würde, wie es [HTML401 §B.2.2] empfiehlt, bestünde das Problem gar nicht.

wenn mans richtig macht, besteht kein problem

man könnte genausogut verlangen, nur mehr klettverschlüsse bei schuhen zu verwenden, weil es doch viele leute gibt, die ihre schuhbänder nicht richtig binden können oder weile die immer wieder aufgehen

[Cybaer]

Hi,

man könnte genausogut verlangen, nur mehr klettverschlüsse bei schuhen zu verwenden, weil es doch viele leute gibt, die ihre schuhbänder nicht richtig binden können oder weile die immer wieder aufgehen

Aus diesem Grund sind IMHO die Frames aus HTML 5 rausgeflogen. Wenn es wirklich der angegebene Grund wäre (nicht näher erläuterte technische Gründe), dann wären die IFrames auch über den Jordan gegangen.

Aber "die Autoren waren zu doof, die Technik verantwortungsvoll und korrekt zu nutzen" kann man halt nicht schreiben ...

... und ganz drauf verzichten wollte man wohl letztlich auch nicht.

Gruß, Cybaer

[Gunnar Bittersmann]

@@suit:

Wenn dafür einfach ';' verwendet werden würde, wie es [HTML401 §B.2.2] empfiehlt, bestünde das Problem gar nicht.

wenn mans richtig macht, besteht kein problem

Es ist einfach nervig, beim C&P von URIs aus bspw. der Adressleite in HTML-Quelltext hinein immer '&' in '&' ändern zu müssen.

man könnte genausogut verlangen, nur mehr klettverschlüsse bei schuhen zu verwenden, weil es doch viele leute gibt, die ihre schuhbänder nicht richtig binden können oder weile die immer wieder aufgehen

Nicht alles, was hinkt, sind orthopädische Schuhe.

Live long and prosper,
Gunnar

[suit]

Es ist einfach nervig, beim C&P von URIs aus bspw. der Adressleite in HTML-Quelltext hinein immer '&' in '&' ändern zu müssen.

sicher, aber das sollte doch der parser deines cms für dich übernehmen - der meines cms tut das für mich ;)

[Gunnar Bittersmann]

@@suit:

Es ist einfach nervig, beim C&P von URIs aus bspw. der Adressleite in HTML-Quelltext hinein immer '&' in '&' ändern zu müssen.

sicher, aber das sollte doch der parser deines cms für dich übernehmen - der meines cms tut das für mich ;)

CMS? Pfui bäh! ;-)

Live long and prosper,
Gunnar

[suit]

CMS? Pfui bäh! ;-)

ja du mit deinen 2 html dokumenten und 2 domains (oder sinds doch mehr) brauchst vermutlich kein cms ;)

[Beat]

CMS? Pfui bäh! ;-)
ja du mit deinen 2 html dokumenten und 2 domains (oder sinds doch mehr) brauchst vermutlich kein cms ;)

Denk an all die Error Pages.

mfg Beat

[Auge]

Hallo

• Die jeweiligen Seiten sind so alt, dass sie vor dem Durchbruch von CSS-basierten Layouts erstellt wurden
  Die investieren so viel in neueste Technik, da werden die doch nicht eine alte Website einfach der Bequemlichkeit wegen lassen wie sie ist. Ist doch irgendwie auch eine Art Aushängeschild (zumindest für die die den Quellcode verstehen können)

Wen interessiert denn der Quelltext? Eventuell uns, ja und? Die Seiten sind nicht zur Analyse des Quelltextes sondern zur Anzeige von Daten gemacht worden. Und genau das taten sie früher und tun sie noch heute.

Tschö, Auge

[Beat]

Wenn Google oder Amazon Tabellen für nichttabellarische Daten verwenden, kann das 3 mögliche Gründe haben:

• Die jeweiligen Seiten sind so alt, dass sie vor dem Durchbruch von CSS-basierten Layouts erstellt wurden
• Man hat sich aus anderen Gründen für eine Tabelle entschieden (in manchen Fällen hat man bereits ein Modul, welches ordentliche Tabellen liefert und möchte dieses lieber exzessiv nutzen, als ein neues Modul für semantisches Layout zu entwickeln).
• Die verantwortlichen Entwickler sind zu semantischem Markup unfähig.

Da du schon mal deine Glaskugel hervorgeholt hast...

Ich bezweifle, dass im Fall von Google dies zutrifft.
Der Grund dürfte schlicht sein, dass es keine Alternative gibt, die so zuverlässig arbeitet. Praxis ist wichtiger als Theorie.

Ich nehme an, dass Google sehr scharf prüft, wie die Seiten rüber kommen für verschiedene Browser/User-Agents. Wenn Layout-Tabellen aus der Sicht der Zugänglichkeit eine Hürden darstellten, hätte Google eine Alternative gefunden, oder einen Beitrag geleistet, dass eine bessere Alternative als diese Fucking Floats (du sollst sie nicht missbrauchen!) zur Verfügung stünden.

mfg Beat

[Klawischnigg]

Hi there,

wie hier und anderswo ist oft die Meinung zu lesen, dass man Tabellen _ausschließlich_ zur Darstellung tabellarischer Daten verwenden sollte.

sollte, ja. Es gibt aber keinen kategorischen Imperativ des Webdesigns. Wenn Du auf das 'warum sollte man' keine für Dich relevante Antwort findest, dann lass es bleiben.

Dies richtet sich offensichtlich gegen den "Missbrauch" von Tabellen für Layoutzwecke.

offensichtlich.

Aus Sicht eines Informatikers ist das auch vollkommen einleuchtend.

Nein. Aus der Sicht eines Sendungsbewusstseinbehafteten ist das einleuchtend. Mit Informatik hat das nicht das mindeste zu tun. (Es sei denn, irgendjemand wartet Webseiten, indem er Texte und Bilder direkt in irgendeinen "Wysiwig"-Editor klopft.

Nun ist es durchaus nicht unmöglich, dass wir kleinen, smarten People den großen auch einmal etwas voraus haben können, als Erklärung reicht mir das aber noch nicht wirklich.

Was wir kleinen, smarten People denen voraus haben ist der Umstand, daß wir im Vergleich zu denen praktisch alle unserer produzierten Seiten im Privatissimum betreiben, bezogen auf die Besucherzahlen.

Warum verwenden z.B. Google und Amazon Tabellen für nichttabellarische Daten?

Weil es ihnen sch***egal ist? Weil sie mit dem *Inhalt* ihrer Seiten Kohle machen und nicht mit dem Design? Weil die Seite einfach funktioniert? Weil es Browser und User gibt, die mit CSS nichts anfangen können (wollen)? Weil Style-sheets in Mobiltelefonen und Organizern lange nicht so gut funktionieren wie Tabellen? Weil es, wenn man ein CMS verwendent, egal ist, wie die Inhalte dargestellt werden? Weil sie kein Sendungsbewusstsein haben?  Weil sie ihre Produkte an den Mann bringen wollen und keine pseudophilosophischen Betrachtungen über semantisches Markup?

Such' Dir einen Grund aus...

[Cybaer]

Hi,

Aus Sicht eines Informatikers ist das auch vollkommen einleuchtend.
Nein. Aus der Sicht eines Sendungsbewusstseinbehafteten ist das einleuchtend. Mit Informatik hat das nicht das mindeste zu tun.

Widerspruch: Ich bin zwar kein Informatiker, aber Mathematiker (OK, nicht studiert, nur Abifach, aber ich fühle mich der Thematik ziemlich verbunden).

Und als solcher finde ich "schlechten" HTML-Code ziemlich "würg". Die Klarheit und Reinheit von (gezwungernermaßem "sauberen") SGML-Code hingegen brillant (a la: So, bevor wir ein sauber strukturiertes Dokument schreiben, machen wir uns erstmal intensivst Gedanken und schreiben eine DTD dafür)!

Das hat nichts mit "Sendungsbewußtsein" zu tun, sondern einfach etwas mit "Ästhetik"! Und da sind "wir" halt ein wenig anders als "Normalsterbliche".

Oder anders gesagt: Wenn mein alter Elektriker eine Riesenwampe hat und dazu noch viele Warzen im Gesicht (selbstgestricktes HTML), dann ist mir das egal. Ich bin nicht schwul. Aber falls eine junge, super-sexy Elektrikerin auftaucht (valides XHTML), dann bevorzuge ich automatisch die! O;-)

Meinen Kunden haben allerdings nicht meine persönlichen Vorlieben zu interessieren, den interessiert nur das praktische Ergebniss (immer und überall Strom mit ausreichender Spannung).

Gruß, Cybaer

[Klawischnigg]

Hi there,

Und als solcher finde ich "schlechten" HTML-Code ziemlich "würg". Die Klarheit und Reinheit von (gezwungernermaßem "sauberen") SGML-Code hingegen brillant (a la: So, bevor wir ein sauber strukturiertes Dokument schreiben, machen wir uns erstmal intensivst Gedanken und schreiben eine DTD dafür)!

Das ästhetische Argument kann ich durchaus nachvollziehen, auch wollte ich mit meiner dem Originalposter gegebenen Antwort keineswegs dem Tabellenlayout das Wort reden, alleine, Klarheit und Reinheit sind nun mal keine Kategorien der Informatik, ebensowenig wie Brillianz. Das ist imho auch in der Mathematik nicht anders, wobei da natürlich "schlanken" und klaren Lösungen immer der Vorzug zu geben ist.

Meinen Kunden haben allerdings nicht meine persönlichen Vorlieben zu interessieren, den interessiert nur das praktische Ergebniss (immer und überall Strom mit ausreichender Spannung).

Ja eh, auf das Ergebnis kommt es an, auch wenn ich Dir persönlich viele hübsche Elektrikerinnen wünsche;)

[Orlando]

Ich bin zwar kein Informatiker, aber Mathematiker (OK, nicht studiert, nur Abifach, aber ich fühle mich der Thematik ziemlich verbunden).

Oh. Dann bin ich ein Frauenschwarm.

Meinen Kunden haben allerdings nicht meine persönlichen Vorlieben zu interessieren, den interessiert nur das praktische Ergebniss (immer und überall Strom mit ausreichender Spannung).

Ähm, ja.

Roland

[Cyx23]

Hallo.

Warum verwenden z.B. Google und Amazon Tabellen für nichttabellarische Daten?

Weil es schon immer so gemacht wurde.
Weil es funktioniert.
Weil es besser funktionert.
Weil keiner Bock hat, wegen etwas Quellcode-Ästhetik das CMS umzustricken.
Weil auf einigen Seiten sowieso "tabellarische Daten" angezeigt werden.
Weil gerade da die Semantik bei HTML eh eine geringe Rolle spielt.
Weil Tabellen sowieso Layoutwerkzeuge sind.

Grüsse

Cyx23

[at]

Hallo.
Vielleicht gibt es aber auch nachvollziehbare Gründe.
MfG, at

[Cyx23]

Hallo,

dass die Tabellendarstellung aller irgendwie noch gebräuchlichen Browser ggf. besser ist als die CSS-Unterstützung hatte ich ja schon angedeutet. Dass Tabellen einige Dinge besser können eigentlich auch.

Dass Tabellen irgendwie einfacher anzuwenden wären, war ja auch mal zu lesen, da möchte ich allerdings widersprechen, und die Wartbarkeit ist i.d.R. eines der besseren Argumente gegen "Layoutabellen".

Die auch hier im Forum gebetsmühlenartig wiederholte Behauptung, CSS würde viel Code sparen, hat so pauschal nie gestimmt. Und auch mit der Trennung von Inhalt und Layout war es ja angesichts zahlreicher Container oder zusätzlicher clear-fix Basteleien nicht ganz so weit her.

Vielleicht gibt es aber auch nachvollziehbare Gründe.

Du meinst Google? Leider hast du keine weiteren Gründe gepostet, ich vermute dass mehrere Punkte, die mit dem Formular zusammenhängen, ausschlaggebend sind.

Grüsse

Cyx23

[Cybaer]

Hi,

die Wartbarkeit ist i.d.R. eines der besseren Argumente gegen "Layoutabellen".

Wobei das bei einem CMS- oder Shop-System keine Rolle spielt, da man eh nur über Template geht - und dort investierte Arbeitszeit bezügl. "Differenz in Wartbarkeit CSS ./. Table" läßt sich wohl kaum in Promille des Gesamtaufwand beziffern.

Und dort, also eine Ebene höher als nun ausgerechnet im Outputcode, ...

Und auch mit der Trennung von Inhalt und Layout war es ja angesichts zahlreicher Container oder zusätzlicher clear-fix Basteleien nicht ganz so weit her.

... findet sinnvollerweise auch die Trennung von Inhalt (Datenbank) und Layout (was-für-eines-auch-immer) statt.

Gründe für TL wurden genannt - at hat sie nur nicht gelesen, wollte sie nicht lesen, oder wollte sie nicht akzeptieren. >;->

Gruß, Cybaer

[at]

Hallo.

die Wartbarkeit ist i.d.R. eines der besseren Argumente gegen "Layoutabellen".

Wobei das bei einem CMS- oder Shop-System keine Rolle spielt, da man eh nur über Template geht - und dort investierte Arbeitszeit bezügl. "Differenz in Wartbarkeit CSS ./. Table" läßt sich wohl kaum in Promille des Gesamtaufwand beziffern.

Auch Promille läppern sich zusammen. Als Trinkgeld nähme ich die gern.

Und dort, also eine Ebene höher als nun ausgerechnet im Outputcode, ...

Und auch mit der Trennung von Inhalt und Layout war es ja angesichts zahlreicher Container oder zusätzlicher clear-fix Basteleien nicht ganz so weit her.

... findet sinnvollerweise auch die Trennung von Inhalt (Datenbank) und Layout (was-für-eines-auch-immer) statt.

Das sehe in prinzipiell auch so. Meist empfiehlt es sich aber, den Inhalt und das Layout, also die Datenbankinhalte und das CSS, durch eine Struktur, also HTML, zu verbinden.

Gründe für TL wurden genannt - at hat sie nur nicht gelesen, wollte sie nicht lesen, oder wollte sie nicht akzeptieren. >;->

Wie meist akzeptiere ich auch hier nur gute Gründe, und die wurden bisher nicht genannt. Ob das daran liegt, dass es keine gibt, kann ich nicht beurteilen.
MfG, at

[Cybaer]

Hi,

Wie meist akzeptiere ich auch hier nur gute Gründe, und die wurden bisher nicht genannt. Ob das daran liegt, dass es keine gibt, kann ich nicht beurteilen.

Es wurde, mehrfach, als Grund die "Robustheit" des TLs genannt, bei gleichzeitiger Beibehaltung des gewünschten Layouts (also Fehlerfreiheit bei der Darstellung mangels unerwünschter Überlappungen, gepaart mit einem Basisdesign, im Gegensatz zum "blanken Inhalt" bei CSS-losen Browsern) - ein Punkt übrigens, der mich auch persönlich immer erfreut, wenn ich mit der Dreambox (TV-Receiver mit Linux) mal eben surfe ...

... ob das für dich ein guter Grund ist, sei natürlich dahingestellt. Für andere ist's einer.

Deswegen darfst Du deine Seiten ja auch so machen, wie Du möchtest, und andere machen die Seiten so, wie sie möchten. :-)

Gruß, Cybaer

[at]

Hallo.

dass die Tabellendarstellung aller irgendwie noch gebräuchlichen Browser ggf. besser ist als die CSS-Unterstützung hatte ich ja schon angedeutet.

Na, dieses kleine "ggf." liest sich schon ganz anders als die in ihrer Absolutheit vorgetragenen Thesen.

Dass Tabellen einige Dinge besser können eigentlich auch.

Und Frames könnes auch einige Dinge besser, und Flash auch, und ... -- dennoch sind sie nicht das Maß der Dinge. Und Layout-Werkzeuge sind sie auch nur für Leute, die Schrauben mit dem Hammer in die Wand treiben.

Dass Tabellen irgendwie einfacher anzuwenden wären, war ja auch mal zu lesen, da möchte ich allerdings widersprechen, und die Wartbarkeit ist i.d.R. eines der besseren Argumente gegen "Layoutabellen".

Das finde ich auch. Und das gilt meiner Meinung nach gerade im angedeuteten Zusammenhang mit CMS.

Die auch hier im Forum gebetsmühlenartig wiederholte Behauptung, CSS würde viel Code sparen, hat so pauschal nie gestimmt.

Das Gegenteil aber auch nicht -- wie das bei pauschalen Behauptungen ja meist ist. Dass es aber eine generelle Tendenz gibt, dass Websites mit wachsendem Umfang von externen Stylesheets profitieren, halte ich für konsensfähig. Und dass Websites eher wachsen als schrumpfen, sicher auch.

Und auch mit der Trennung von Inhalt und Layout war es ja angesichts zahlreicher Container oder zusätzlicher clear-fix Basteleien nicht ganz so weit her.

Die meisten Container sind ja weitestgehend überflüssig. Ich wüsste noch nicht einmal, wann ich zuletzt ein <div> verwendet hätte. Man muss ja keinen CSS-Zengarden-Code produzieren. Und wenn, wäre der zwar so aufgebläht und damit hässlich wie eine Tabelle, aber semantisch immerhin neutral. Und HTML bietet immerhin das höchste sowie ein weiter wachsendes Maß an Semantik unter den verbreiteten Auszeichnungssprachen.

Vielleicht gibt es aber auch nachvollziehbare Gründe.

Du meinst Google? Leider hast du keine weiteren Gründe gepostet, ich vermute dass mehrere Punkte, die mit dem Formular zusammenhängen, ausschlaggebend sind.

Ich kenne weder Googles Gründe noch nachvollziehbare.
MfG, at

[Cybaer]

Hi,

Dass es aber eine generelle Tendenz gibt, dass Websites mit wachsendem Umfang von externen Stylesheets profitieren, halte ich für konsensfähig.

Keine Frage. Aber CSS und TL schließen sich ja nicht aus.

Das gerne benutzte Beispiel CSS Zen Garden taugt ja hier nicht, da wohl kaum eine Firma ihre immer gleichen Inhalte immer verschieden verpackt ...

Sollte es doch so eine Firma geben (ich kenne keine - ich kenne nur "Corporate Identity"), dann ist sie sicherlich mit CSS "pur" gut bedient. I.d.R. wollen die Firmen ihr CI halt solange es nur eben geht (will heißen: unter welchem Browser auch immer) beibehalten ...

Gruß, Cybaer

[at]

Hallo.

Dass es aber eine generelle Tendenz gibt, dass Websites mit wachsendem Umfang von externen Stylesheets profitieren, halte ich für konsensfähig.

Keine Frage. Aber CSS und TL schließen sich ja nicht aus.

Ja, keine Frage. Aber ich hatte mich ja nur auf ein einzelnes Argument bezogen, das die beiden Techniken derart gegenüberstellt. Dass ich der Kombination schon deshalb keinen Sinn sehe, weil ich in Tabellen als Layout-Werkzeug keinen solchen sehe, ist ja eine andere Frage und längst bekannt.

Das gerne benutzte Beispiel CSS Zen Garden taugt ja hier nicht, da wohl kaum eine Firma ihre immer gleichen Inhalte immer verschieden verpackt ...

Das ist natürlich eine Frage des Grades der Variation. Und der CSS Zen Garden drückt ja schon in seinem Namen aus, dass er nur eine der mindestens drei Ebenen variiert. Aber eigentlich taugt der ja ohnehin zu nichts weiter als zu dem Zweck, dem er ursprünglich dienen sollte. Das allerdings gelingt ihm nach wie vor gut.

Sollte es doch so eine Firma geben (ich kenne keine - ich kenne nur "Corporate Identity"), dann ist sie sicherlich mit CSS "pur" gut bedient. I.d.R. wollen die Firmen ihr CI halt solange es nur eben geht (will heißen: unter welchem Browser auch immer) beibehalten ...

Gerade diesen Unternehmen ließe sich alles verkaufen, weil deren Entscheider in den seltensten Fällen Ahnung von Corporate Design oder dessen medienspezifischen Einschränkungen haben. Dass man dort noch häufig Tabellen-Layouts vorfindet, hat also mit den Wünschen seitens des Unternehmens meist ebenso wenig zu tun wie mit der vorgeblichen Kompetenz der beauftragten Agentur.
Einige Konzerne leisten sich ja sogar Agenturen, die nichts anderes tun, als bei den beauftragten übrigen Agenturen die Einhaltung der Corporate Identity zu überwachen. Dass sie diesen Auftrag fortgesetzt erhalten, obwohl sie nach vernünftigen Maßstäben regelmäßig scheitern, zeugt einmal mehr von der mangelnden Beurteilungsfähigkeit innerhalb der Unternehmen -- oder von der unzulänglichen Festlegung des Corporate Design, was aber in Hinsicht auf die Verantwortlichen keinen Unterschied ergibt.
Und dass sehr wohl eine immer weiter steigende Zahl großer Unternehmen ihre Tabellen-Layouts in den Wind schießen -- teilweise sogar unter Mithilfe für solche Kreise regelrecht prominenter Webdesigner --, ist ja ebenso bekannt wie nachprüfbar. Bei einigen wünschte ich mir allerdings fast, sie hätten darauf verzichtet, statt einfach <table>, <tr> und <td> durch <div> zu ersetzen.
MfG, at

[Cybaer]

Hi,

Dass ich der Kombination schon deshalb keinen Sinn sehe, weil ich in Tabellen als Layout-Werkzeug keinen solchen sehe, ist ja eine andere Frage und längst bekannt.

Ist hier aber nicht das Thema, da es um Entwickler geht, die das anders sehen.

Dass man dort noch häufig Tabellen-Layouts vorfindet, hat also mit den Wünschen seitens des Unternehmens meist ebenso wenig zu tun wie mit der vorgeblichen Kompetenz der beauftragten Agentur.

Sicher. Ist aber hier auch nicht die Frage. Zumindest Google, aber auch Amazon unterstelle ich erstmal, daß sie Entwickler haben, die was vom Thema verstehen. Daß der Webdesigner der Lieschen-Müller-AG nicht so fit ist, ist klar - und tagtäglich zu beobachten.

Und dass sehr wohl eine immer weiter steigende Zahl großer Unternehmen ihre Tabellen-Layouts in den Wind schießen -- teilweise sogar unter Mithilfe für solche Kreise regelrecht prominenter Webdesigner --, ist ja ebenso bekannt wie nachprüfbar.

Keine Frage. Aber auch hier die Frage, warum es nicht alle derart im Web exponierten Firmen machen. IMHO wird die Mehrzahl der Firmen die umstellen, es aus dem gleichen Grund machen, aus dem auch TL gewählt wurde: Der Webdesigner hat es so gewollt. Ob dahinter i.d.R. wirkliches Wissen oder eine Abwägung steht, sei mehrheitlich in beiden Fällen bezweifelt.

Bei einigen wünschte ich mir allerdings fast, sie hätten darauf verzichtet, statt einfach <table>, <tr> und <td> durch <div> zu ersetzen.

Ja. Z.B. ist es verständlich, wenn gerade ECMAScript.org als "Standardisierer" ohne TL codet. Aber das Ergebnis unterscheidet sich in keinster Weise vom TL - außer, daß in Non-CSS-Browsern jegliches Layout fehlt. Wenn man es *so* macht, dann kann man IMHO auch beim TL bleiben ...

Gruß, Cybaer

[at]

Hallo.

Dass man dort noch häufig Tabellen-Layouts vorfindet, hat also mit den Wünschen seitens des Unternehmens meist ebenso wenig zu tun wie mit der vorgeblichen Kompetenz der beauftragten Agentur.

Sicher. Ist aber hier auch nicht die Frage. Zumindest Google, aber auch Amazon unterstelle ich erstmal, daß sie Entwickler haben, die was vom Thema verstehen.

Vom Thema Corporate Design, auf das sich die Aussage auf deine Einbringen dieser Thematik hin bezog? Wohl kaum.

Daß der Webdesigner der Lieschen-Müller-AG nicht so fit ist, ist klar - und tagtäglich zu beobachten.

Ich meinte durchaus Unternehmen in der Kategorie von Google oder Amazon.

IMHO wird die Mehrzahl der Firmen die umstellen, es aus dem gleichen Grund machen, aus dem auch TL gewählt wurde: Der Webdesigner hat es so gewollt. Ob dahinter i.d.R. wirkliches Wissen oder eine Abwägung steht, sei mehrheitlich in beiden Fällen bezweifelt.

Das war der Kern meiner Aussage.
MfG, at