Ich werde Ihre Argumente nacheinander durchgehen und versuchen, die darin enthaltenen Fehler aufzuzeigen.
Es ist gut, Inhalte vom Layout zu trennen. Dies ist jedoch ein trügerisches Argument. Klischee denken.
Es ist überhaupt nicht trügerisch, weil HTML absichtlich entworfen wurde. Der Missbrauch eines Elements kommt möglicherweise nicht völlig in Frage (schließlich haben sich auch in anderen Sprachen neue Redewendungen entwickelt), aber mögliche negative Auswirkungen müssen ausgeglichen werden. Selbst wenn es heute keine Argumente gegen den Missbrauch des <table>Elements gäbe, könnte es morgen sein, da Browser-Anbieter das Element speziell behandeln. Schließlich wissen sie, dass „ <table>Elemente nur für tabellarische Daten bestimmt sind“ und können diese Tatsache nutzen, um die Rendering-Engine zu verbessern, das <table>Verhalten subtil zu ändern und damit Fälle zu brechen, in denen sie zuvor missbraucht wurden.
Na und? Interessiert es meinen Chef? Interessieren sich meine Benutzer?
Hängt davon ab. Ist Ihr Chef spitzhaarig? Dann könnte es ihn nicht interessieren. Wenn sie kompetent ist, wird sie sich darum kümmern, weil die Benutzer es tun werden .
Vielleicht ich oder meine Kollegen, die eine Webseitenpflege pflegen müssen ... Ist eine Tabelle weniger wartbar? Ich denke, die Verwendung einer Tabelle ist einfacher als die Verwendung von divs und css.
Die Mehrheit der professionellen Webentwickler scheint sich Ihnen zu widersetzen[ Zitat benötigt ] . Das Tabelle ist in der Tat weniger wartbar sollte klar sein. Die Verwendung von Tabellen für das Layout bedeutet, dass das Ändern des Unternehmenslayouts tatsächlich das Ändern jeder einzelnen Seite bedeutet. Dies kann sehr teuer sein. Auf der anderen Seite, vernünftige Nutzung von semantisch sinnvoller HTML mit CSS kombiniert könnte solche Änderungen an die CSS beschränken und die verwendeten Bilder.
Übrigens ... warum ist die Verwendung eines div oder eines span eine gute Trennung von Inhalt und Layout und einer Tabelle nicht? Um ein gutes Layout nur mit Divs zu erhalten, sind häufig viele verschachtelte Divs erforderlich.
Tief verschachtelte <div>s sind genau wie Tabellenlayouts ein Anti-Pattern. Gute Webdesigner brauchen nicht viele von ihnen. Auf der anderen Seite haben selbst solche tief verschachtelten Divs nicht viele Probleme mit Tabellenlayouts. Tatsächlich können sie sogar zu einer semantischen Struktur beitragen, indem sie den Inhalt logisch in Teile teilen.
Lesbarkeit des Codes Ich denke, es ist umgekehrt. Die meisten Leute verstehen HTML, wenig verstehen CSS. Es ist einfacher.
"Die meisten Leute" spielen keine Rolle. Profis sind wichtig. Für Profis verursachen Tabellenlayouts viel mehr Probleme als HTML + CSS. Dies ist wie zu sagen, ich sollte GVim oder Emacs nicht verwenden, da Notepad für die meisten Menschen 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 dies nicht als Argument verwenden, aber es wäre logisch. Suchmaschinen suchen nach relevanten Daten. Während tabellarische Daten natürlich relevant sein könnten, ist es selten das, wonach Benutzer suchen. Benutzer suchen nach Begriffen, die im Seitentitel verwendet werden, oder nach ähnlich prominenten Positionen. Es wäre daher logisch, tabellarische Inhalte von der Filterung auszuschließen und damit die Verarbeitungszeit (und die Kosten!) Um einen großen Faktor zu reduzieren.
Tabellen sind langsamer. Ein zusätzliches tbody-Element muss eingefügt werden. Dies sind Erdnüsse für moderne Webbrowser.
Das zusätzliche Element hat nichts damit zu tun, dass Tabellen langsamer sind. Andererseits ist der Layoutalgorithmus für Tabellen viel schwieriger. Der Browser muss häufig warten, bis die gesamte Tabelle geladen ist, bevor er mit dem Layout des Inhalts beginnen kann. Darüber hinaus funktioniert das Zwischenspeichern 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ürde mich selbst dafür interessieren, weil es richtig ist, dass diesem Argument eine gewisse wissenschaftliche Genauigkeit fehlt.
Die meisten Websites, die aktualisiert werden müssen, benötigen ebenfalls neuen Inhalt (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 das Ändern des Designs durch eine Trennung von Inhalt und Design vereinfacht wurde. Es ist oft noch notwendig, HTML-Code zu ändern, aber die Änderungen sind immer viel enger. Darüber hinaus müssen Designänderungen gelegentlich dynamisch vorgenommen werden. Betrachten Sie Template-Engines, wie sie vom WordPress-Blogging-System verwendet werden. 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äftsanforderungen.
Etwas anderes. 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 bietet. Ich arbeite in der Bioinformatik, wo dies eine traurige Realität ist. Moderne Webtechniken und WebServices haben die meisten Entwickler nicht erreicht, und häufig ist Screen Scraping die einzige Möglichkeit, den Prozess des Datenabrufs zu automatisieren. Kein Wunder, dass viele Biologen solche Aufgaben immer noch manuell ausführen. Für Tausende von Datensätzen.