Ich werde Ihre Argumente der Reihe nach durchgehen und versuchen, die Fehler darin aufzuzeigen.
Es ist gut, Inhalt und Layout zu trennen Aber das ist ein trügerisches Argument; Klischeedenken.
Das ist überhaupt nicht abwegig, denn HTML wurde absichtlich so gestaltet. Die missbräuchliche Verwendung eines Elements ist zwar nicht völlig ausgeschlossen (schließlich haben sich auch in anderen Sprachen neue Redewendungen entwickelt), aber mögliche negative Auswirkungen müssen gegeneinander abgewogen werden. Außerdem, selbst wenn es keine Argumente gegen die missbräuchliche Verwendung des <table> Element gibt, kann es morgen aufgrund der Art und Weise, wie die Browser-Anbieter das Element besonders behandeln, nicht mehr geben. Schließlich wissen sie, dass " <table> Elemente sind nur für tabellarische Daten" und könnte diese Tatsache nutzen, um die Rendering-Engine zu verbessern und dabei die Art und Weise, wie <table> s verhalten und somit Fälle, in denen es zuvor missbraucht wurde, zu beenden.
Und wenn schon? Ist es meinem Chef egal? Interessiert es meine Benutzer?
Kommt drauf an. Ist Ihr Chef spitzhaarig? Dann ist es ihm vielleicht egal. Wenn sie kompetent ist, wird es ihr wichtig sein, denn die Benutzer se .
Vielleicht interessiert es mich oder meine Entwickler-Kollegen, die eine Webseite pflegen müssen... Ist eine Tabelle weniger wartungsfreundlich? Ich denke, eine Tabelle ist einfacher als Divs und CSS.
Die Mehrheit der professionellen Webentwickler scheint sich Ihnen zu widersetzen [ Zitate erforderlich ] . Diese Tabellen sind in der Tat weniger wartungsfreundlich ist, sollte offensichtlich sein. Die Verwendung von Tabellen für das Layout bedeutet, dass bei einer Änderung des Unternehmenslayouts auch jede einzelne Seite geändert werden muss. Dies kann muy teuer. Auf der anderen Seite ist der vernünftige Einsatz von semantisch sinnvollem HTML in Kombination mit CSS könnte beschränken Sie solche Änderungen auf das CSS und die verwendeten Bilder.
Übrigens... warum ist die Verwendung eines Divs oder eines Spans eine gute Trennung von Inhalt und Layout und eine Tabelle nicht? Ein gutes Layout mit nur divs erfordert oft eine Menge von verschachtelten divs.
Tief verschachtelt <div> s sind ein Anti-Muster, ebenso wie Tabellenlayouts. Gute Web-Designer brauchen nicht viele davon. Andererseits haben selbst solche tief verschachtelten Divs nicht viele der Probleme von Tabellenlayouts. Sie können sogar zu einer semantischen Struktur beitragen, indem sie den Inhalt logisch in Teile unterteilen.
Lesbarkeit des Codes Ich denke, es ist genau umgekehrt. Die meisten Leute verstehen html, nur wenige verstehen css. Es ist einfacher.
"Die meisten Menschen" spielen keine Rolle. Es sind die Profis. Für Profis verursachen Tabellenlayouts viel mehr Probleme als HTML + CSS. Das ist so, als würde ich sagen, dass ich GVim oder Emacs nicht verwenden sollte, weil Notepad für die meisten Leute einfacher ist. Oder dass ich LaTeX nicht verwenden sollte, weil MS Word für die meisten Menschen einfacher ist.
Für SEO ist es besser, keine Tabellen zu verwenden
Ich weiß nicht, ob dies wahr ist, und würde es nicht als Argument verwenden, aber es wäre logisch. Suchmaschinen suchen nach . Daten. Tabellarische Daten können natürlich relevant sein, aber sie sind selten das, wonach die Nutzer suchen. Die Nutzer suchen nach Begriffen, die im Seitentitel oder an ähnlich prominenter Stelle verwendet werden. Es wäre daher logisch, tabellarische Inhalte von der Filterung auszuschließen und so die Verarbeitungszeit (und die Kosten!) um einen großen Faktor zu reduzieren.
Tische sind langsamer. Es muss ein zusätzliches tbody-Element eingefügt werden. Für moderne Webbrowser sind das Peanuts.
Das zusätzliche Element hat nichts damit zu tun, dass die Tische langsamer sind. Andererseits ist der Layout-Algorithmus für Tabellen viel schwieriger, der Browser muss oft warten, bis die gesamte Tabelle geladen ist, bevor er mit dem Layout des Inhalts beginnen kann. Außerdem funktioniert die Zwischenspeicherung des Layouts nicht (CSS kann problemlos zwischengespeichert werden). All dies wurde bereits erwähnt.
Zeigen Sie mir einige Benchmarks, bei denen die Verwendung einer Tabelle eine Seite erheblich verlangsamt.
Leider habe ich keine Benchmark-Daten. Ich wäre selbst daran interessiert, denn es ist richtig, dass dieses Argument eine gewisse wissenschaftliche Strenge vermissen lässt.
Die meisten Websites, die ein Upgrade benötigen, brauchen auch neue Inhalte (html). Szenarien, in denen eine neue Version einer Website nur eine neue CSS-Datei benötigt, sind nicht sehr wahrscheinlich.
Ganz und gar nicht. Ich habe an mehreren Fällen gearbeitet, in denen die Änderung des Designs durch eine Trennung von Inhalt und Design vereinfacht wurde. Oft ist es zwar immer noch notwendig, einen Teil des HTML-Codes zu ändern, aber die Änderungen sind immer sehr viel begrenzter. Außerdem müssen Änderungen am Design gelegentlich dynamisch vorgenommen werden. Denken Sie an Template-Engines wie die des Blogging-Systems WordPress. Tabellenlayouts würden dieses System buchstäblich zerstören. Ich habe an einem ähnlichen Fall für eine kommerzielle Software gearbeitet. Die Möglichkeit, das Design zu ändern, ohne den HTML-Code zu ändern, war eine der geschäftlichen Anforderungen.
Und noch etwas. Das Tabellenlayout erschwert das automatische Parsen von Websites (Screen Scraping) erheblich. Das mag trivial klingen, denn wer macht das schon? Ich war selbst überrascht. Screen Scraping kann sehr hilfreich sein, wenn der betreffende Dienst keine WebService-Alternative für den Zugriff auf seine Daten anbietet. Ich arbeite in der Bioinformatik, wo dies eine traurige Realität ist. Moderne Webtechniken und WebServices sind bei den meisten Entwicklern noch nicht angekommen, und oft ist Screen Scraping die einzige Möglichkeit, den Prozess der Datenbeschaffung zu automatisieren. Kein Wunder, dass viele Biologen solche Aufgaben immer noch manuell erledigen. Für Tausende von Datensätzen.
