it-swarm-eu.dev

Warum machen Leute Tische mit Divs?

In der modernen Webentwicklung stoße ich immer häufiger auf dieses Muster. Es sieht aus wie das:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

Und in CSS gibt es so etwas wie:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

* (Klassennamen dienen nur zur Veranschaulichung; im wirklichen Leben sind dies normale Klassennamen, die widerspiegeln, worum es bei dem Element geht.)

Ich habe es sogar kürzlich selbst versucht, weil ... weißt du, jeder macht es.

Aber ich verstehe es immer noch nicht. Warum machen wir das? Wenn Sie einen Tisch brauchen, dann machen Sie einfach einen gesprengten <table> und damit fertig sein. Ja, auch wenn es sich um ein Layout handelt. Dafür sind Tische gedacht - um Dinge tabellarisch auszulegen.

Die beste Erklärung, die ich habe, ist, dass inzwischen jeder das Mantra "Verwenden Sie keine Tabellen für das Layout" gehört hat, also folgen sie ihm blind. Aber sie brauchen immer noch eine Tabelle für das Layout (weil nichts anderes die Erweiterungsmöglichkeiten einer Tabelle hat), also machen sie ein <div> (weil es nicht eine Tabelle ist!) und fügen Sie dann CSS hinzu, das es trotzdem zu einer Tabelle macht.

Für die ganze Welt scheint mir das, als würde man willkürlich unnötige Hindernisse in den Weg stellen und dann zusätzliche Arbeit leisten, um sie zu umgehen.

Das ursprüngliche Argument für die Abkehr von Tabellen für das Layout war, dass es schwierig ist, ein tabellarisches Layout danach zu ändern. Das Ändern eines "Faux-Table" -Layouts ist jedoch aus den gleichen Gründen genauso schwierig. In der Praxis ist das Ändern eines Layouts immer schwierig, und es reicht fast nie aus, nur das CSS zu ändern, wenn Sie etwas Ernsthafteres als kleinere Änderungen vornehmen möchten. Sie werden müssen die HTML-Struktur für ernsthafte Designänderungen verstehen und ändern. Und Tabellen machen die Arbeit nicht schwieriger oder einfacher als Divs.

Tatsächlich sehe ich nur, wenn Sie ein Layout nur schwer ändern können, wenn Sie es tun abbenutzte sie und schuf ein gottloses Durcheinander. Das kannst du auch mit divs machen.

Also ... in dem Versuch, dies von einem Geschwätz in eine zusammenhängende Frage zu verwandeln: Was vermisse ich? Was sind die tatsächlichen Vorteile der Verwendung eines "Faux-Tisches" gegenüber einem echten?

Über den doppelten Link : Dies ist kein Vorschlag, ein anderes Tag oder etwas anderes zu verwenden. Dies ist eine Frage zur Verwendung eines <table> vs display:table.

278
Vilx-

Dies ist ein gängiges Muster für die Erstellung von reaktionsschnellen Tabellen. Die Anzeige von Tabellendaten auf Mobiltelefonen ist schwierig, da die Seite entweder zum Lesen von Text vergrößert wird, dh Tabellen von der Seite der Seite entfernt werden und der Benutzer zum Lesen der Tabelle vor- und zurückblättern muss, oder die Seite wird verkleinert Dies bedeutet normalerweise, dass die Tabelle zu klein ist, um gelesen werden zu können.

Responsive Tabellen ändern das Layout auf kleineren Bildschirmen - manchmal werden einige Spalten ausgeblendet oder Spalten zusammengeführt, z. Name und E-Mail-Adresse können auf großen Bildschirmen getrennt sein, auf kleinen Bildschirmen jedoch in einer Zelle zusammengefasst werden, sodass die Informationen lesbar sind, ohne dass ein Bildlauf erforderlich ist.

<div> S werden aus mehreren Gründen verwendet, um die Tabellen anstelle von <table> - Tags zu erstellen. Wenn <table> - Tags verwendet werden, müssen Sie die Standardstile und das Standardlayout des Browsers überschreiben, bevor Sie Ihren eigenen Code hinzufügen. In diesem Fall sparen <div> - Tags viel CSS auf dem Boilerplate. Darüber hinaus erlauben ältere Versionen von IE nicht, Standard-Tabellenstile zu überschreiben, sodass die Verwendung von <div> S auch die browserübergreifende Entwicklung vereinfacht.

Es gibt eine ziemlich gute Übersicht über reaktionsschnelle Tabellen zu CSS-Tricks .

Bearbeiten: Ich sollte darauf hinweisen, dass ich dieses Muster nicht befürworte - es fällt in die Divitis-Falle und ist nicht semantisch -, aber deshalb finden Sie Tabellen aus divs.

122
whostolemyhat

Die Frage ist, ob die Daten semantisch eine Tabelle sind (d. H. Ein Satz von Daten oder Informationseinheiten, die logisch in zwei Dimensionen organisiert sind) oder ob Sie das Raster nur für das visuelle Layout verwenden, z. weil Sie möchten, dass eine Seitenleiste erweitert wird oder so etwas.

Wenn Ihre Informationen semantisch eine Tabelle sind, verwenden Sie ein <table> - Tag. Wenn Sie nur ein Raster für Layoutzwecke benötigen, verwenden Sie einige andere geeignete HTML-Elemente und verwenden display:table Im Stylesheet.

Wann sind Daten semantisch eine Tabelle? Wenn die Daten logisch entlang zweier Achsen organisiert sind. Wenn es mit Überschriften für die Zeilen oder Spalten sinnvoll ist, haben Sie möglicherweise eine semantische Tabelle. Ein Beispiel für etwas, das nicht semantisch eine Tabelle ist, ist die Darstellung eines Textes in Spalten wie in einer Zeitung. Dies ist keine semantische Tabelle, da Sie sie immer noch linear lesen würden und keine Bedeutung verloren gehen würde, wenn die Präsentation entfernt würde.


OK, warum nicht <table> Für alles verwenden und nicht nur für etwas, das semantisch eine Tabelle ist? Optisch ist es offensichtlich dasselbe (da das Tabellenelement nur display:element Im Standard-Stylesheet enthält).

Der Unterschied besteht darin, dass die semantischen Informationen alternativen Benutzeragenten helfen können. Mit einem Bildschirmleser können Sie beispielsweise in zwei Dimensionen in der Tabelle navigieren und die Überschriften für eine Zelle für beide Achsen lesen, wenn Sie vergessen, wo Sie sich befinden. Dies wäre nur verwirrend, wenn die Tabelle nicht semantisch eine Tabelle wäre, sondern nur für das visuelle Layout verwendet würde.

Die Diskussion <table> Gegenüber display:table Ist nur ein Fall des allgemeineren Prinzips der Verwendung von semantischem Markup. Siehe zum Beispiel: Warum sollte man sich die Mühe machen, richtig und semantisch zu markieren? oder Warum wird semantischem Markup für Suchmaschinen mehr Gewicht beigemessen?

An einigen Stellen ist es möglicherweise gesetzlich vorgeschrieben, aus Gründen der Barrierefreiheit semantisches Markup zu verwenden, und es gibt auf keinen Fall einen Grund, Ihre Seite absichtlich weniger zugänglich zu machen.

Selbst wenn Sie sich nicht um behinderte Benutzer kümmern, bietet eine von Inhalten getrennte Präsentation Vorteile. Z.B. Ihr dreispaltiges Layout kann auf einem Mobiltelefon mithilfe eines alternativen Stylesheets in einer einzelnen Spalte dargestellt werden.

154
JacquesB

Eigentlich würde ich sagen, dass die Verwendung von Klassennamen wie "Tabelle" in Ihrem Beispiel zeigt, dass die Leute nicht wirklich verstehen, was sie tun, wenn sie nach semantischem Markup suchen. Sie erhalten Noten für den Versuch zu zeigen, dass Inhalt sind keine tabellarischen Daten , aber sie verlieren Noten für schlechte Klassennamen.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Alles, was dieser Entwickler getan hat, ist das ursprüngliche <table> Markup mit CSS-Klassennamen. Dies bedeutet, sobald dieses Layout keine Tabelle ist, sind die Klassennamen uneins.

Was dieser Entwickler hätte tun sollen, ist zu überlegen, welche Informationen in der Tabelle enthalten sind - handelt es sich um eine Miniaturbildgalerie? Na dann:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Jetzt kann ich ein adaptives CSS erstellen:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Warum divs und nicht Tabellen

Eine Tabelle enthält tabellarische Daten - Die Darstellung einer Tabelle ist untrennbar mit der Struktur einer Tabelle verbunden. Tabellarische Daten müssen immer in tabellarischer Form vorliegen, unabhängig davon, wo Sie diesen Inhalt ablegen oder auf welchem ​​Bildschirm/Gerät er angezeigt werden soll.

Eine Miniaturgalerie (oder viele andere Dinge, wie ein Registrierungsformular, ein Menü und mehr) sind keine tabellarischen Daten. In einigen Design-Layouts wird es möglicherweise wie eine Tabelle dargestellt, in anderen Fällen, z. B. bei schmalen Telefonbildschirmen, möchten Sie jedoch, dass traditionellere Block-Layouts verwendet werden. Oder Sie möchten Miniaturansichten in einer Seitenleiste anstatt im Hauptinhaltsbereich anzeigen.

Sie haben jetzt die Wahl, unterschiedliche Markups für den Breitbildinhalt (Tabellen) und den Seitenleisten- oder Schmalbildinhalt (Divs) auszugeben. Dies bedeutet, dass Ihre serverseitigen Skripts wissen müssen, wohin der Inhalt geht, wenn Sie dies programmgesteuert erstellen - oder Sie lassen Ihr serverseitiges Skript das gleiche Markup ausgeben (da es egal sein sollte, wo Sie dies platzieren) und verwenden unterschiedliche CSS-Regeln für die verschiedenen Situationen.

Dann haben Sie die Wahl, immer Tabellen auszugeben und dann die Regeln für die natürliche Tabellenanzeige mit Block zu überschreiben (was wirklich einige Zahnräder in jedem Entwicklerkopf schleifen sollte) oder mit gut beschrifteten Divs zu arbeiten, die flexiblere Ansätze für das Styling ermöglichen.

Und Best Practices seit mehreren Jahren bestand darin, Tabellen zu vermeiden, wenn keine tabellarischen Daten dargestellt werden müssen.

102
HorusKol

In früheren Zeiten war die Tabellen-Rendering-Engine "erschienen" langsamer, wenn Sie Prozentsätze für Spaltenbreiten verwendeten. Die Engine musste im Wesentlichen den gesamten Datensatz herunterladen, bevor sie herausfinden konnte, wie groß alles war, um ihn auf dem Bildschirm zu zeichnen.

Der DIV-Motor war anders. Wenn der Browser auf einen DIV stieß, platzierte er ihn und füllte den Inhalt inline. Natürlich können Divs herumspringen, wenn die Daten vollständig geladen sind. Deshalb bin ich oben in Anführungszeichen erschienen. Der Zeitrahmen für die Fertigstellung beider war der gleiche, jedoch wurden die Tabellen erst am Ende gezeichnet, was bedeutete, dass der Benutzer nicht sicher war, ob er geladen wurde oder nicht, für ein oder zwei Sekunden.

Dies wurde schlimmer, als Tabellen verschachtelt wurden.

Es gab damals (und gibt es immer noch) Möglichkeiten, das Rendern von Tabellen bei weitem zu beschleunigen. Grundsätzlich beginnt der Browser sofort mit dem Rendern von Tabellendaten, indem er einen Hinweis darauf gibt, dass sich die Spaltengrößen nicht ändern. Letztendlich bedeutet dies, dass Tabellen tatsächlich an der richtigen Position angezeigt werden können schneller als divs, was ihnen den Anschein gibt, besser zu sein.

Aber das ist nicht die ganze Geschichte. Der Rest ist, dass die meisten Entwickler sich einfach nicht die Mühe machen, ihr Handwerk gut genug zu lernen, um dies zu wissen. Stattdessen springen sie auf verschiedene Bandwaggons und verwenden den Code, aus dem sie kopieren/einfügen können. Bis heute stelle ich fest, dass nur sehr wenige Webentwickler den Unterschied von einem Doctype zum nächsten kennen - und das ist der Hauptgrund, warum verschiedene Websites alle möglichen Problemumgehungen haben, um verschiedene Browser abzudecken.

Also +1 an Sie, dass Sie die Frage gestellt haben.

11
NotMe

Wenn ich hier ein kleines "Meta" bekommen kann, kommen mir zwei Probleme in den Sinn:

Erstens: Jemand schlägt aus gutem Grund eine Regel vor, und die Leute verfehlen den Punkt völlig, indem sie dem technischen Buchstaben der Regel folgen und dabei den Geist ignorieren. Sie finden einen Weg, um all die schlechten Dinge zu erreichen, die die Regel zu verhindern versuchte, während sie die Regel technisch wie formuliert befolgen.

Zweitens: Jemand sieht ein Problem und schlägt eine Regel vor, um es zu verhindern. Andere sehen den Wert dieser Regel. Dann bestehen sie auf einer blinden Hingabe an diese Regel, ohne Rücksicht auf das ursprüngliche Problem, das sie lösen sollte, und/oder unabhängig davon, welche anderen Probleme sie verursacht. Ich habe viele Gespräche geführt, in denen jemand sagt: "Du musst X machen, weil das die Regel ist", und dann frage ich: "Aber warum sollten wir X machen?", Und sie sehen mich verwirrt und verärgert an und sagen: "Aber Ich habe es dir gerade gesagt! Weil es die Regel ist! " Ich antworte: "Aber es scheint mehr Probleme zu verursachen als es zu lösen. Ich denke, wir wären besser dran, Y zu tun." Und dann sagt die Person: "Nein, schau, ich werde es dir zeigen. Siehst du, es ist genau hier in diesem Buch. X ist die Regel."

In diesem Fall haben wir ein Problem: Das Tabellen-Tag führt zwei Dinge aus: Erstens steuert es das Layout eines Dokuments. Zweitens vermittelt es die Idee, dass die eingeschlossenen Daten aus Zeilen und Spalten von Zahlen oder anderen Daten bestehen.

So viele Leute schlugen die Lösung vor: Verwenden Sie keine Tabellen-Tags, um das Layout von Dingen zu steuern, die nicht logisch "Tabellen" sind. Verwenden Sie CSS.

Bei dieser Lösung gibt es jedoch ein Problem. Das Tabellen-Tag und seine Untertags führen viele sehr nützliche Layoutfunktionen aus, die mit CSS nicht einfach zu erreichen sind. Wenn sie erreicht werden können, ist der dafür erforderliche Code oft umständlich - schwer zu lesen und schwer zu warten. Warum sollten wir Dinge ungeschickt und schwierig machen, wenn es einen sauberen und einfachen Weg gibt?

Persönlich denke ich, dass wir besser dran gewesen wären, nur zu erklären: "Die Tatsache, dass sich etwas in einem Tabellen-Tag befindet, bedeutet nicht unbedingt, dass es Zeilen und Spalten von Zahlen darstellt." Dies wäre keine empörende Aussage gewesen. Ich habe noch nie jemanden sagen hören, dass das "p" -Tag nur für Dinge verwendet werden kann, die wirklich Absätze grammatikalisch korrekter, logisch konstruierter englischer Sätze sind. Ich habe noch nie jemanden sagen hören, dass es falsch ist, ein "ul" -Tag für eine Liste zu verwenden, die tatsächlich in einer logischen Reihenfolge vorliegt, nur weil Sie Aufzählungszeichen und keine Sequenznummern wollten. Usw.

5
Jay

Hier gibt es bereits Tonnen großartige Antworten. Aber ich wollte hinzufügen, dass table Elemente Rendering-Einschränkungen haben, die für div Elemente nicht existieren. Versuchen Sie, eine Tabelle zu erstellen, die virtuelles Scrollen ausführt (z. B. SlickGrid , DataTables und andere), und Sie werden sehr enttäuscht sein. Es funktioniert einfach nicht. Die meisten (alle?) Modernen Javascript-Raster verwenden divs, da das CSS ein viel flexibleres Rendern ermöglicht.

Es gibt auch andere Einschränkungen. Meine allgemeine Regel lautet: Wenn ich die gesamte Tabelle auf einem einzigen Bildschirm sehen möchte und kein/viel benutzerdefiniertes Rendering dafür möchte, verwende ich ein table -Element, andernfalls gehe ich mit divs, weil Ich kann die Ergebnisse viel, viel einfacher kontrollieren.

5
Crisfole

HTML und CSS haben ein gewisses Maß an Flexibilität entwickelt, das bedeutet, dass selbst konzeptionell "blockierende" Elemente wie <div> (HTMLs älteste und allgemeinste Form von Blockinhalten) nicht als Blöcke angezeigt werden müssen:

div { display: inline; }

Wie Sie bemerken, kann <div> Umbenannt werden, um <table> Und seine Mitreisenden zu emulieren. Eigentlich können die meisten Tags. Aufgrund ihrer besonderen Rollen bezweifle ich, dass Sie Makrotags wie <html>, <head>, <body> Und <script> Nützlich neu zuordnen können, aber "allgemeine" Tags wie <div>, <p>, <b>, <em>, <span> Und <pre>? Zu gewinnen. Lassen Sie die Inline-Tags-Blöcke, die Inline-Blöcke, die vorformatierten Tags fließen, die stationären schweben. Mach dich verrückt, wenn du magst!

Es ist möglich . Vielleicht möchten Sie ein Garn darüber spinnen, wie wir alle "semantisches Markup" verwenden sollen, bla bla bla, oder mit den Pythonisten glauben, dass "es eine - und vorzugsweise nur eine - offensichtliche geben sollte Weg, es zu tun. " Doch Tim Toady ist ein kluger und neugieriger Typ. Mit freier Hand wird er sie alle erkunden. Dazu gehört, dass die verfügbare Flexibilität für Substitutionen genutzt wird. Einige sind weise, andere werden anders bewiesen. Aber Versuch, Irrtum und Erfahrung sind der einzige Weg, dies herauszufinden. Damit sind die ausreichenden Substitutionsbedingungen gegeben.

Ich denke nicht, dass es übertrieben ist zu sagen, dass auch eine Substitution notwendig ist. Zumindest ist es extrem praktisch . HTML hatte lange Zeit keine <menu>, <section> Oder <aside> Elemente. Webseiten und Apps verfügen jedoch überall über Menüs, Abschnitte und Seitenleisten. Wie? Da HTML-Listenelemente (<ul>, <ol> Und <li>) Leicht neu verwendet werden konnten und einige Verwendungen als Menücontainer und Teile neu klassifiziert wurden. <div> Könnte für <article>, <section>, <aside>, <figure> Und <summary> Stehen. HTML5 hat einige zuvor nicht adressierte Anwendungsfälle eingeholt und maßgeschneiderte Elemente hinzugefügt. Es ist ein großartiges Update und eine Korrektur, um den allgemeinen Gebrauch in der Praxis zu ermöglichen.

Trotzdem bleiben viele gängige Redewendungen, die keine maßgeschneiderten Tags oder semantischen Modelle haben . Dinge wie Seiten, Fußnoten, Zitate, Kommentar-Streams, zugehörige Avatare, "Likes", Unterüberschriften und Untertitel, die ich und viele andere jeden Tag verwenden. Was sollen wir tun? Was wir können. Verwenden Sie "nahe, aber ungenaue" Elemente mit Klassen und IDs neu, um unsere Arbeit für die nächsten fünf oder zehn oder wie viele Jahre auch immer zu unterstützen, bis HTML6 oder HTML7 aufholt. HTML/CSSs "Ja, es ist theoretisch ein X, aber wir werden es markieren und als Y damit arbeiten" -Funktion ist unglaublich praktisch. Wirklich unverzichtbar. Dadurch werden Webinhalte flexibel und nicht spröde.

Wenn Sie noch weiter gehen, hat "semantisches Markup" irreduzible Einschränkungen . Das gilt für jede Art von strenger Struktur, die Sie sich für Inhalte vorstellen können.

Standardformate können nicht den gesamten Reichtum menschlicher Bedürfnisse, Wünsche und Vielfalt umfassen. Sie werden immer "hinter der Kurve" dessen sein, was die Leute tun jetzt. Wie sie innovativ sind. Heck, HTML5 ist immer noch hinter der Kurve in Bezug auf Fußnoten, Überschriften und andere Druckinnovationen des 17. Jahrhunderts. Es fehlen Funktionen, die für viele Information Worker und Inhaltsersteller wesentlich sind. Also improvisieren wir.

Noch unveränderlicher ist, dass Informationen sich nicht an ein Regelwerk halten. Klar, es beginnt als Tisch. Aber vielleicht möchten Sie nur die Zusammenfassung - sagen Sie den Titel für jede Zeile als Liste. Möglicherweise nimmt es zu viel Platz ein, und Sie möchten es als platzsparende Inline-Liste. Möglicherweise haben Sie Datensätze, deren Titel Sie nur möchten. Wenn Sie dann auf klicken, werden die zugrunde liegenden Details angezeigt. Oder Sie möchten, dass Elemente in einer komplexen Liste oder Tabelle gruppiert und kategorisiert werden. Oh, jetzt möchten Sie, dass es anders transponiert und kategorisiert wird. Oder die als Balkendiagramm dargestellten Werte. Dies werden jeden Tag in Apps, Tabellenkalkulationen und Datenvisualisierungen erledigt. Sie sind Teil unserer Informationslandschaft und dessen, was wir im Web tun wollen und müssen. Der Mensch organisiert die Form und Darstellung unserer Daten ständig neu. Es ist nicht nur eine Sache oder ein Format/Layout oder ein Konzept. Es ist fungibel, wobei die Semantik von den Umständen und den Entscheidungen abhängt, die Benutzer interaktiv treffen. Ja, markieren Sie Text als "hervorgehoben" (<em>), Aber das ist nur eine Konvention. Ich habe an Dokumenten mit mindestens einem halben Dutzend verschiedener Arten von "Betonung" gearbeitet. Wir müssen in der Lage sein, dies für unterschiedliche Verwendungszwecke und unterschiedliche Interpretationen anzupassen und neu zuzuordnen. Eine Art von HTML-Betonung? Qualvoll reduktionistisch. Begrenzen. Spröde. Gleiches gilt für <table>, <p> Usw.

Es ist großartig, Tags/Elemente zu haben, mit denen die gesamte Community darüber nachdenken kann, was wohin geht. Das hilft, Konventionen und Redewendungen zu etablieren, und macht uns gemeinsam effizienter. Aber die Fähigkeit, Dinge neu zuzuordnen, diese Strukturen neu zu bestimmen und neu zu nutzen? Dies ist ein wesentlicher Bestandteil der Inklusivität und des Erfolgs des Web.

3
Jonathan Eunice

Anwendungsfälle sind wichtig. Es gibt einen großen Unterschied zwischen Layout/Präsentation auf einer Inhaltsseite und in einer Anwendung. Inhaltlich ist die Semantik für das SEO-Bewusstsein und die Benutzerfreundlichkeit von großer Bedeutung. In diesen Fällen ist die Verwendung von Tabellen zur Darstellung von Tabellendaten im Allgemeinen das Richtige. Wie andere angemerkt haben, werden Sie von Suchmaschinen bestraft, und Sie verstoßen möglicherweise sogar gegen die Usability-Gesetze, wenn Sie gesetzlich verpflichtet sind, die Richtlinien zur Benutzerfreundlichkeit der Regierung einzuhalten.

In einer Webanwendung können Entwickler völlig separate Ansichten für SEO- und Usability-Zwecke erstellen. Responsive Design hat dazu geführt, dass Benutzer Ansichten erstellen, die Desktop- und mobile Layouts verarbeiten können, und Divs sind in diesen Anwendungsfällen besser als Tabellen.

Nehmen Sie zum Beispiel E-Commerce-Websites. Das Anzeigen einer Liste von Produkten in einem Such- oder Suchergebnis zeigt im Allgemeinen eine Liste von Produkten in Tabellenform an. Diese Ansichten können jedoch durchaus mithilfe von divs (die allgemeinere und flexiblere Layout- und Stiloptionen bieten) anstelle von Tabellen generiert werden. Amazon und eBay sind gute Beispiele für diesen Ansatz. Wenn Sie ein Suchergebnis auf beiden Websites überprüfen, sehen Sie eine tief verschachtelte Gruppe von Divs.

0
Robert Munn