html - vorlage - table design layout




Warum nicht Tabellen für das Layout in HTML verwenden? (20)

Es scheint die allgemeine Meinung zu sein, dass Tabellen nicht für das Layout in HTML verwendet werden sollten.

Warum?

Ich habe nie (oder selten um ehrlich zu sein) gute Argumente dafür gesehen. Die üblichen Antworten sind:

  • Es ist gut, Inhalt vom Layout zu trennen
    Aber das ist ein trügerisches Argument; Klischees Denken . Ich denke, es stimmt, dass die Verwendung des Tabellenelements für das Layout wenig mit Tabellendaten zu tun hat. Na und? Ist mein Chef interessiert? Interessieren meine Benutzer?

    Vielleicht ich oder meine Mitentwickler, die eine Webseite pflegen müssen ... Ist ein Tisch weniger pflegeleicht? Ich denke, die Verwendung einer Tabelle ist easier als die Verwendung von divs und CSS.

    Übrigens ... warum benutzt man ein div oder eine span gute inhaltliche Trennung vom Layout und einer Tabelle nicht? Für ein gutes Layout mit nur divs sind oft verschachtelte divs erforderlich.

  • Lesbarkeit des Codes
    Ich denke, es ist umgekehrt. Die meisten Menschen verstehen HTML, wenige verstehen CSS.

  • Es ist besser für SEO, keine Tabellen zu verwenden
    Warum? Kann jemand Beweise zeigen, dass es ist? Oder eine Aussage von Google, dass Tabellen aus SEO-Sicht entmutigt werden?

  • Tabellen sind langsamer.
    Ein zusätzliches Körperelement muss eingefügt werden. Das sind Erdnüsse für moderne Webbrowser. Zeigen Sie mir einige Benchmarks, wo die Verwendung einer Tabelle eine Seite erheblich verlangsamt.

  • Eine Layout-Überarbeitung ist einfacher ohne Tische, siehe css Zen Garden .
    Die meisten Websites, die ein Upgrade benötigen, 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. Zen Garden ist eine nette Website, aber ein bisschen theoretisch. Ganz zu schweigen von seinem misuse von CSS.

Ich bin wirklich an guten Argumenten interessiert, divs + CSS anstelle von Tabellen zu verwenden.


Es ist gut, Inhalt vom Layout zu trennen
Aber das ist ein trügerisches Argument; Klischees Denken

Es ist ein falsches Argument, weil HTML-Tabellen Layout sind! Der Inhalt sind die Daten in der Tabelle, die Darstellung ist die Tabelle selbst. Deshalb kann es manchmal sehr schwierig sein, CSS von HTML zu trennen. Sie trennen den Inhalt nicht von der Präsentation, Sie trennen die Präsentation von der Präsentation! Ein Stapel verschachtelter divs ist nicht anders als eine Tabelle - es ist nur ein anderer Satz von Tags.

Das andere Problem bei der Trennung von HTML und CSS besteht darin, dass sie intime Kenntnisse voneinander benötigen - Sie können sie wirklich nicht vollständig voneinander trennen. Das Tag-Layout im HTML ist eng mit der CSS-Datei gekoppelt, egal was Sie tun.

Ich denke, Tabellen vs Divs kommt auf die Bedürfnisse Ihrer Anwendung.

In der Anwendung, die wir bei der Arbeit entwickeln, benötigten wir ein Seitenlayout, in dem die Teile sich dynamisch an ihren Inhalt anpassen. Ich habe tagelang versucht, dies browserübergreifend mit CSS und DIVs zu bewerkstelligen, und es war ein kompletter Albtraum. Wir sind zu den Tischen gewechselt und es hat alles funktioniert .

Wir haben jedoch eine sehr geschlossene Zielgruppe für unser Produkt (wir verkaufen ein Stück Hardware mit einer Weboberfläche) und Probleme mit der Barrierefreiheit sind für uns kein Thema. Ich weiß nicht, warum Screenreader nicht gut mit Tabellen umgehen können, aber ich denke, wenn das so ist, dann müssen Entwickler damit umgehen.


I guess it's true that using the table element for layout has little to do with tabular data. Na und? Does my boss care? Do my users care?

Google and other automated systems do care, and they're just as important in many situations. Semantic code is easier for a non-intelligent system to parse and process.


Dies ist nicht das definitive Argument, aber mit CSS können Sie das gleiche Markup nehmen und das Layout je nach Medium ändern, was ein netter Vorteil ist. Bei einer Druckseite können Sie die Navigation ruhig unterdrücken, ohne beispielsweise eine druckerfreundliche Seite erstellen zu müssen.


Ein Tisch für das Layout wäre nicht so schlecht. Aber Sie können das Layout, das Sie benötigen, meist nicht mit nur einem Tisch bekommen. Sehr bald haben Sie zwei oder drei verschachtelte Tabellen. Dies wird sehr umständlich.

  • Es ist viel schwieriger zu lesen. Das ist nicht der Meinung. Es gibt nur mehr verschachtelte Tags ohne identifizierende Markierungen.

  • Die Trennung von Inhalt und Präsentation ist eine gute Sache, da Sie sich auf das konzentrieren können, was Sie tun. Das Mischen der beiden führt zu aufgeblähten Seiten, die schwer zu lesen sind.

  • CSS für Stile ermöglicht es Ihrem Browser, die Dateien zwischenzuspeichern und nachfolgende Anforderungen sind viel schneller. Das ist riesig.

  • Tabellen sperren Sie in ein Design ein. Sicher, nicht jeder braucht die Flexibilität von CSS Zen Garden, aber ich habe noch nie auf einer Seite gearbeitet, wo ich das Design hier und da nicht ein bisschen ändern musste. Es ist viel einfacher mit CSS.

  • Tische sind schwer zu stylen. Sie sind nicht sehr flexibel mit ihnen (dh Sie müssen noch HTML-Attribute hinzufügen, um die Stile einer Tabelle vollständig zu steuern)

Ich habe keine Tabellen für nicht-tabellarische Daten in wahrscheinlich 4 Jahren verwendet. Ich habe nicht zurückgeblickt.

Ich würde wirklich vorschlagen, CSS Mastery von Andy Budd zu lesen. Es ist fantastisch.

Bild bei ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


Hier ist die Antwort meines Programmierers von einem ähnlichen Thread

Semantik 101

Sehen Sie sich zuerst diesen Code an und überlegen Sie, was hier nicht stimmt ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

Das Problem ist natürlich, dass ein Fahrrad kein Auto ist. Die Fahrzeugklasse ist eine ungeeignete Klasse für die Fahrradinstanz. Der Code ist fehlerfrei, aber semantisch falsch. Es reflektiert schlecht auf dem Programmierer.

Semantik 102

Wenden Sie dies jetzt auf Dokumentenmarkierung an. Wenn Ihr Dokument tabellarische Daten enthalten soll, wäre das entsprechende Tag <table> . Wenn Sie die Navigation jedoch in eine Tabelle einfügen, missbrauchen Sie den Zweck des <table> -Elements. Im zweiten Fall geben Sie keine Tabellendaten an. Sie verwenden (fälschlicherweise) das <table> -Element, um ein Präsentationsziel zu erreichen.

Fazit

Werden die Besucher bemerken? Nein. Kümmert sich dein Chef? Könnte sein. Schneiden wir manchmal als Programmierer ab? Sicher. Aber sollten wir? Nein. Wer profitiert, wenn Sie semantisches Markup verwenden? Sie - und Ihr beruflicher Ruf. Jetzt geh und mach das Richtige.


Hier ist ein Abschnitt von HTML aus einem aktuellen Projekt:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

Und hier ist der gleiche Code wie ein tabellenbasiertes Layout.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

Die einzige Sauberkeit, die ich in diesem tabellenbasierten Layout sehe, ist die Tatsache, dass ich mit meiner Einrückung übereifrig bin. Ich bin mir sicher, dass der Inhaltsbereich zwei weitere eingebettete Tabellen enthalten würde.

Eine andere Sache, über die Sie nachdenken sollten: Dateigrößen . Ich habe festgestellt, dass tabellenbasierte Layouts in der Regel doppelt so groß sind wie ihre CSS-Gegenstücke. Auf unserem High-Speed-Breitband ist das kein großes Problem, aber auf denen mit Einwahlmodems.


Layout sollte einfach sein. Die Tatsache, dass Artikel darüber geschrieben werden, wie ein dynamisches dreispaltiges Layout mit Kopf- und Fußzeilen in CSS erreicht werden kann, zeigt, dass es sich um ein schlechtes Layoutsystem handelt. Natürlich können Sie es zur Arbeit bringen, aber es gibt buchstäblich Hunderte von Artikeln online, wie es geht. Es gibt so ziemlich keine Artikel für ein ähnliches Layout mit Tabellen, weil es offensichtlich ist. Egal, was Sie gegen Tabellen und zugunsten von CSS sagen, diese eine Tatsache macht alles rückgängig: Ein einfaches dreispaltiges Layout in CSS wird oft "Der Heilige Gral" genannt.

Wenn du nicht "WTF" sagst, musst du die Kool-Hilfe jetzt wirklich ablegen.

Ich liebe CSS. Es bietet erstaunliche Styling-Optionen und einige coole Positionierungstools, aber als Layout-Engine ist es mangelhaft. Es muss eine Art dynamisches Rasterpositionierungssystem geben. Eine einfache Möglichkeit, Boxen auf mehreren Achsen auszurichten, ohne zuerst ihre Größe zu kennen. Es ist mir egal, wenn Sie es <table> oder <gridlayout> oder was auch immer nennen, aber das ist eine grundlegende Layout-Funktion, die in CSS fehlt.

Das größere Problem ist, dass die CSS-Zeloten, wenn sie nicht zugeben, dass es fehlende Features gibt, CSS von allem zurückhalten, was es sein könnte. Ich wäre sehr glücklich, wenn ich aufhören würde, Tabellen zu verwenden, wenn CSS eine anständige mehrachsige Gitterpositionierung bietet, wie es bei jeder anderen Layout-Engine der Welt der Fall ist. (Sie wissen, dass dieses Problem schon viele Male in vielen Sprachen von allen außer dem W3C gelöst wurde, richtig? Und niemand sonst hat bestritten, dass solch ein Feature nützlich war.)

Seufzer. Genug Entlüftung. Geh voran und steck deinen Kopf in den Sand.


Leider kann CSS Zen Garden nicht mehr als Beispiel für gutes HTML / CSS-Design verwendet werden. Praktisch alle ihre neueren Designs verwenden Grafiken für Abschnittsüberschriften. Diese Grafikdateien sind in der CSS angegeben.

Eine Website, deren Zweck darin besteht, den Vorteil zu demonstrieren, dass Design aus Inhalten herausgehalten wird, verpflichtet nun regelmäßig die UNSICHERBARE SÜNDE, Inhalte in Design zu bringen. (Wenn sich die Abschnittsüberschrift in der HTML-Datei ändern würde, würde die angezeigte Abschnittsüberschrift nicht funktionieren).

Das zeigt nur, dass selbst diejenigen, die für die strikte DIV & CSS Religion eintreten, nicht ihren eigenen Regeln folgen können. Sie können das als Richtlinie dafür verwenden, wie genau Sie ihnen folgen.


Sehen Sie sich diese doppelte Frage an.

Ein Gegenstand, den du vergisst, ist die Zugänglichkeit. Tabellenbasierte Layouts übersetzen nicht so gut, wenn Sie beispielsweise einen Bildschirmleser verwenden müssen. Und wenn Sie für die Regierung arbeiten, können unterstützende Browser wie Bildschirmleser erforderlich sein .

Ich denke auch, Sie unterschätzen die Auswirkungen einiger der Dinge, die Sie in der Frage erwähnt haben. Wenn Sie zum Beispiel sowohl der Designer als auch der Programmierer sind, haben Sie möglicherweise keine vollständige Vorstellung davon, wie gut Präsentation und Inhalt voneinander getrennt sind. Aber sobald Sie in einen Laden kommen, wo sie zwei verschiedene Rollen sind, beginnen die Vorteile klarer zu werden.

Wenn Sie wissen, was Sie tun und gute Werkzeuge haben, hat CSS wirklich erhebliche Vorteile gegenüber Tabellen für das Layout. Und während jeder Gegenstand für sich allein nicht rechtfertigen kann, Tische zu verlassen, ist es im Allgemeinen doch wert.


Layout flexibility
Imagine you're making a page with a large number of thumbnails.
DIVs :
If you put each thumbnail in a DIV, floated left, maybe 10 of them fit on a row. Make the window narrower, and BAM - it's 6 on a row, or 2, or however many fit.
TABLE:
You have to explicitly say how many cells are in a row. If the window is too narrow, the user has to scroll horizontally.

Maintainability
Same situation as above. Now you want to add three thumbnails to the third row.
DIVs:
Add them in. The layout will automatically adjust.
TABLE: Paste the new cells into the third row. Oops! Now there are too many items there. Cut some from that row and put them on the fourth row. Now there are too many items there. Cut some from that row... (etc)
( Of course, if you're generating the rows and cells with server-side scripting, this probably won't be an issue. )


Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them -- but hey, welcome to the world of computers).

Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.

It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.


CSS layouts are generally much better for accessibility, provided the content comes in a natural order and makes sense without a stylesheet. And it's not just screen readers that struggle with table-based layouts: they also make it much harder for mobile browsers to render a page properly.

Also, with a div-based layout you can very easily do cool things with a print stylesheet such as excluding headers, footers and navigation from printed pages - I think it would be impossible, or at least much more difficult, to do that with a table-based layout.

If you're doubting that separation of content from layout is easier with divs than with tables, take a look at the div-based HTML at CSS Zen Garden , see how changing the stylesheets can drastically change the layout, and think about whether you could achieve the same variety of layouts if the HTML was table based... If you're doing a table-based layout, you're unlikely to be using CSS to control all the spacing and padding in the cells (if you were, you'd almost certainly find it easier to use floating divs etc. in the first place). Without using CSS to control all that, and because of the fact that tables specify the left-to-right and top-to bottom order of things in the HTML, tables tend to mean that your layout becomes very much fixed in the HTML.

Realistically I think it's very hard to completely change the layout of a div-and-CSS-based design without changing the divs a bit. However, with a div-and-CSS-based layout it's much easier to tweak things like the spacing between various blocks, and their relative sizes.


I think that boat has sailed. If you look at the direction the industry has taken you will notice that CSS and Open Standards are the winners of that discussion. Which in turn means for most html work, with the exception of forms, the designers will use divs instead of tables. I have a hard time with that because I am not a CSS guru but thats the way it is.


I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:

.1. CSS & SEO:

a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.

b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google

c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout

.2. Generated content:

A table is considerably easier to generate programmically than the equivalent CSS layout.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).

Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.

This is one reason why some very well designed websites (SO for instance) still use table layouts.

Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.

.3. Quick conversion testing

When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier

.4. Different solutions for different problems

Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.

However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)

There are a lot of downsides to tables, including maintenance, lack of flexibility... but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.

Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS

I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"

As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?


It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.

The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.

The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?

If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- to structure the application so that the changes fit in a simple and comfortable manner.


Looks like you are just used to tables and that's it. Putting layout in a table limits you for just that layout. With CSS you can move bits around, take a look at http://csszengarden.com/ And no, layout does not usally require a lot of nested divs.

With no tables for layout and proper semantics HTML is much cleaner, hence easier to read. Why should someone who cannot understand CSS try to read it? And if someone considers himself to be webdeveloper then the good grasp of CSS is a must.

SEO benefits come from the ability to have most important content higher up the page and having better content-to-markup ratio.

will


Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.

CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font -tags are better than specifying typography in CSS, since CSS gives you the same power than font -tags, but in a much cleaner way.

The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell ).

So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.

The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10/ advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.


The fact that this is a hotly debated question is a testament to the failure of the W3C to anticipate the diversity of layout designs which would be attempted. Using divs+css for semantically-friendly layout is a great concept, but the details of implementation are so flawed that they actually limit creative freedom.

I attempted to switch one of our company's sites from tables to divs, and it was such a headache that I totally scrapped the hours of work I had poured into it and went back to tables. Trying to wrestle with my divs in order to gain control of vertical alignment has cursed me with major psychological issues that I will never shake as long as this debate rages on.

The fact that people must frequently come up with complex and ugly workarounds to accomplish simple design goals (such as vertical alignment) strongly suggests that the rules are not nearly flexible enough. If the specs ARE sufficient, then why do high-profile sites (like SO) find it necessary to bend the rules using tables and other workarounds?


This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings - technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.


Tools that use table layouts can become extraordinarily heavy due to the amount of code required to create the layout. SAP's Netweaver Portal by default uses TABLE to layout their pages.

The production SAP portal at my current gig has a home page whose HTML weighs over 60K and goes seven tables deep, three times within the page. Add in the Javascript, the misuse of 16 iframes with similar table issues inside of them, overly heavy CSS etc, and the page weighs over 5MB.

Taking the time to lower the page weight so you can use your bandwidth to do engaging activities with users is worth the effort.





layout