Dlaczego nie używać tabel dla układu w HTML? [zamknięte]

Oto moja odpowiedź programisty z wątku simliar

Semantyka 101

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

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

Semantyka 102

Teraz zastosuj to do znaczniki dokumentu. Jeśli dokument wymaga przedstawienia danych tabelarycznych, odpowiednim znacznikiem będzie <table>. Jeśli jednak umieścisz nawigację w tabeli, to nadużywasz zamierzonego celu elementu <table>. W drugim przypadku nie przedstawiasz danych tabelarycznych - używasz (źle)elementu <table> do osiągnięcia celu prezentacyjnego.

Wniosek

Oczywista odpowiedź: Zobacz CSS Zen Garden . Jeśli powiesz mi, że możesz łatwo zrobić to samo z układem opartym na tabelach (pamiętaj-HTML się nie zmienia), to użyj tabel do układu.

Dwie inne ważne rzeczy to dostępność i SEO.

Oboje dbają o to, w jakiej kolejności prezentowane są informacje. Nie można łatwo wyświetlić nawigacji na górze strony, jeśli układ oparty na tabeli umieszcza ją w 3. komórce 2. wiersza 2. zagnieżdżonej tabeli na strona.

Więc twoje odpowiedzi to Konserwacja, dostępność i SEO.

Nie bądź leniwy. Rób rzeczy we właściwy i właściwy sposób, nawet jeśli są one nieco trudniejsze do nauczenia się.

Zobacz to zduplikowane pytanie.

Jeden element, o którym zapominasz, to dostępność. Układy oparte na tabelach nie tłumaczą się również, jeśli potrzebujesz na przykład użyć czytnika ekranu. A jeśli pracujesz dla rządu, obsługa dostępnych przeglądarek, takich jak czytniki ekranu, może być wymagana .

Myślę również, że nie doceniasz wpływu niektórych rzeczy, o których wspomniałeś w pytaniu. Na przykład, jeśli jesteś zarówno projektantem, jak i programistą, możesz nie mają pełnego uznania tego, jak dobrze oddziela prezentację od treści. Ale kiedy wejdziesz do sklepu, w którym są to dwie różne role, zalety zaczynają być jaśniejsze.

Jeśli wiesz, co robisz i masz dobre narzędzia, CSS naprawdę ma znaczącą przewagę nad tabelami dla układu. I chociaż każdy przedmiot sam w sobie może nie uzasadniać porzucenia stołów, wzięte razem, ogólnie jest tego warte.

Niestety, CSS Zen Garden nie może być już używany jako przykład dobrego projektu HTML/CSS. Praktycznie wszystkie ich ostatnie projekty wykorzystują grafikę do nagłówka sekcji. Te pliki graficzne są określone w CSS.

Stąd strona internetowa, której celem jest pokazanie korzyści z trzymania designu z dala od treści, teraz regularnie popełnia niewypowiedziany grzech umieszczania treści w projekcie. (Jeśli nagłówek sekcji w pliku HTML zmieni się, nagłówek sekcji zostanie wyświetlony nie).

Co pokazuje tylko, że nawet ci, którzy popierają ścisłą religię DIV & CSS, nie mogą przestrzegać własnych zasad. Możesz użyć tego jako wskazówki, jak dokładnie ich przestrzegasz.

To nie jest ostateczny argument, w żaden sposób, ale z CSS można wziąć te same znaczniki i zmienić układ w zależności od medium, co jest miłą zaletą. W przypadku strony wydruku można po cichu wyłączyć nawigację bez konieczności tworzenia strony przyjaznej dla Drukarki.

Jedna tabela dla layoutu nie byłaby taka zła. Ale nie możesz uzyskać układu, którego potrzebujesz, z tylko jedną tabelą przez większość czasu. Wkrótce masz 2 lub 3 zagnieżdżone tabele. To staje się bardzo uciążliwe.

• Jest dużo trudniejsza do odczytania. To nie zależy od opinii. Jest więcej zagnieżdżonych tagów bez znaków identyfikacyjnych.

• Oddzielanie treści od prezentacji jest dobrą rzeczą, ponieważ pozwala skupić się na tym, co robisz. Mieszanie dwóch przewodów za nadęte strony, które są trudne do odczytania.

• CSS dla stylów pozwala przeglądarce buforować pliki, a kolejne żądania są znacznie szybsze. To coś wielkiego.

• Stoły zamykają cię w projekcie. Oczywiście, nie każdy potrzebuje elastyczności CSS Zen Garden, ale nigdy nie pracowałem nad stroną, w której nie musiałem zmieniać trochę projektu tu i tam. Z CSS jest o wiele łatwiej.

• Stoły są trudne do stylizacji. Nie masz zbyt dużej elastyczności z nimi (tzn. nadal musisz dodać atrybuty HTML, aby w pełni kontrolować style tabeli)

Nie używałem tabel dla danych nie-tabelarycznych od chyba 4 lat. Nie oglądałem się za siebie.

Naprawdę chciałbym zasugerować czytanie opanowanie CSS przez Andy ' ego Budda. To fantastyczne.

Obraz na 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

Dobrze jest oddzielić zawartość od layoutu
Ale to jest błędny argument; banalne myślenie

To błędny argument, ponieważ tabele HTML są układami! Zawartość to DANE w tabeli, prezentacja to sama tabela. Dlatego oddzielenie CSS od HTML może być czasami bardzo trudne. Nie oddzielasz treści od prezentacji, oddzielasz prezentację od prezentacji! Stos zagnieżdżonych div nie różni się niczym od tabela - to tylko inny zestaw tagów.

Innym problemem z oddzieleniem HTML od CSS jest to, że potrzebują intymnej wiedzy o sobie nawzajem - naprawdę nie można ich całkowicie rozdzielić. Układ znaczników w HTML jest ściśle powiązany z plikiem CSS bez względu na to, co robisz.

Myślę, że tables vs divs sprowadza się do potrzeb Twojej aplikacji.

W aplikacji, którą tworzymy w pracy, potrzebowaliśmy układu strony, w którym elementy będą dynamicznie się powiększały do ich treści. Spędziłem dni, próbując uruchomić to w przeglądarce z CSS i Div-ami i był to kompletny koszmar. Przełączyliśmy się na stoły i wszystko po prostu zadziałało .

Mamy jednak bardzo zamkniętą publiczność dla naszego produktu (sprzedajemy sprzęt z interfejsem WWW) i problemy z dostępnością nie są dla nas problemem. Nie wiem, dlaczego czytniki ekranu nie radzą sobie dobrze z tabelami, ale myślę, że jeśli tak jest, to programiści muszą sobie z tym poradzić.

CSS / DIV - to tylko praca dla designerów, prawda? Setki godzin spędzonych na debugowaniu problemów DIV / CSS, przeszukiwaniu internetu, aby uzyskać część znaczników pracujących z niejasną przeglądarką-doprowadza mnie to do szaleństwa. Dokonujesz jednej małej zmiany i cały layout idzie okropnie źle-gdzie na eath jest logika w tym. Spędzanie godzin przesuwając coś 3 piksele w ten sposób, a następnie coś innego 2 piksele w inny, aby je wszystkie wyrównać. To wydaje mi się w jakiś sposób złe. Tylko dlatego, że jesteś purystą i coś jest "nie w porządku", nie oznacza, że powinieneś z tego korzystać do n-tego stopnia i w każdych okolicznościach, zwłaszcza jeśli to sprawia, że Twoje życie jest 1000 razy łatwiejsze.

Więc w końcu zdecydowałem, czysto komercyjnie, chociaż używam do minimum, jeśli przewiduję 20 godzin pracy, aby poprawnie umieścić DIV, będę trzymać się tabeli. To złe, denerwuje purystów, ale w większości przypadków kosztuje mniej czasu i jest tańsze w zarządzaniu. I następnie może skoncentrować się na tym, aby aplikacja działała zgodnie z życzeniem klienta, a nie zadowalać purystów. Mimo wszystko płacą rachunki i mój argument do menedżera wymuszającego korzystanie z CSS / DIV - chciałbym tylko zwrócić uwagę, że klienci płacą jego wynagrodzenie, jak również!

Jedyny powód, dla którego wszystkie te argumenty CSS/DIV występują, jest spowodowany wadą CSS w pierwszej kolejności i dlatego, że przeglądarki nie są ze sobą kompatybilne, a jeśli były, połowa projektantów stron internetowych w świat byłby bez pracy.

Kiedy projektujesz formularz windows, nie próbujesz przesuwać kontrolek po ich ułożeniu, więc wydaje mi się, że to dziwne, dlaczego chcesz to zrobić za pomocą formularza internetowego. Po prostu nie mogę zrozumieć tej logiki. Popraw układ na początek i w czym problem. Myślę, że to dlatego, że projektanci lubią flirtować z kreatywnością, podczas gdy twórcy aplikacji są bardziej zainteresowani uruchomieniem aplikacji, tworzeniem obiekty biznesowe, implementacja zasad biznesowych, wypracowanie, w jaki sposób bity danych klientów odnoszą się do siebie, zapewnienie, że rzecz spełnia wymagania klientów - wiesz - jak w prawdziwym świecie rzeczy.

Nie zrozum mnie źle, oba argumenty są poprawne, ale proszę nie krytykować programistów za wybór łatwiejszego, bardziej logicznego podejścia do projektowania formularzy. Często mamy ważniejsze rzeczy do zmartwienia niż poprawna semantyka użycia tabeli nad div.

Case in point - na podstawie tej dyskusji przekonwertowałem kilka istniejących tds i trs na divy. 45 minut, próbując ustawić wszystko obok siebie, poddałem się. TDs z powrotem w 10 sekund później-działa - od razu-na wszystkich przeglądarkach, nic więcej do zrobienia. Proszę, Postaraj się, abym zrozumiał - jakie masz usprawiedliwienie, że chcesz, abym zrobił to w inny sposób!

Układ powinien być łatwy. Fakt, że istnieją artykuły napisane o tym, jak osiągnąć dynamiczny układ trzech kolumn z nagłówkiem i stopką w CSS pokazuje, że jest to słaby system układu. Oczywiście możesz go uruchomić, ale w Internecie są dosłownie setki artykułów o tym, jak to zrobić. Nie ma prawie takich artykułów dla podobnego układu z tabelami, ponieważ jest to oczywiste. Bez względu na to, co mówisz przeciwko tabelom i na rzecz CSS, ten jeden fakt unieważnia to wszystko: trzy podstawowe układ kolumn w CSS jest często nazywany "Świętym Graalem".

Jeśli to nie sprawia, że mówisz "WTF", to naprawdę musisz odłożyć kool-aid teraz.

Kocham CSS. Oferuje niesamowite opcje stylizacji i fajne narzędzia do pozycjonowania, ale jako silnik układu jest wadliwy. Musi istnieć jakiś rodzaj dynamicznego systemu pozycjonowania siatki. Prosty sposób wyrównywania pól na wielu osiach bez uprzedniej znajomości ich rozmiarów. Nie obchodzi mnie, czy nazywasz to

Zgodnie z normą 508 (w przypadku czytników ekranów dla wyświetlaczy), tabele powinny być używane tylko do przechowywania danych, a nie do układania, ponieważ powoduje to, że czytniki ekranów tracą przytomność. Tak mi powiedziano.

Jeśli przypiszesz nazwy do każdego z div - ów, możesz je zeskalować za pomocą CSS. Są po prostu trochę bardziej bolesne, aby siedzieć tak, jak ich potrzebujesz.

Oto sekcja html z najnowszego projektu:

<?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>

I oto ten sam kod co układ oparty na tabeli.

<?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>

Jedyną czystością, jaką widzę w tym układzie opartym na tabeli, jest fakt, że jestem nadgorliwy z moim wcięciem. Jestem pewien, że sekcja treści będzie miała kolejne dwie osadzone tabele.

Kolejna rzecz do przemyślenia: filesizes . Odkryłem, że układy oparte na tabelach są dwa razy większe od ich odpowiedników CSS. Na naszej hig-speed szerokopasmowy, który nie jest wielkim problemem, ale jest na tych z modemami dial up.

Chciałbym dodać, że układy oparte na div są łatwiejsze do mantain, evolve i refactor. Tylko kilka zmian w CSS do zmiany kolejności elementów i to jest zrobione. Z mojego doświadczenia wynika, że przeprojektowanie układu wykorzystującego tabele jest koszmarem (więcej, jeśli są tabele zagnieżdżone).

Twój kod ma również znaczenie z semantycznego punktu widzenia.

Brak argumentów za Div.

Powiedziałbym: jeśli but pasuje, załóż go.

Warto zauważyć, że znalezienie dobrej metody renderowania zawartości w dwóch lub trzech kolumnach DIV+CSS jest trudne, jeśli nie niemożliwe, która jest spójna we wszystkich przeglądarkach i nadal wygląda tak, jak zamierzałem.

To wskazuje trochę równowagę w kierunku tabel w większości moich układów, i alough czuję się winny korzystania z nich (dunny dlaczego, ludzie po prostu mówią, że to złe, więc staram się ich słuchać), w końcu pragmatyczny widok jest po prostu łatwiej i szybciej używać tabel. Nie płacą mi za godzinę, więc stoliki są dla mnie tańsze.

Układy CSS są ogólnie dużo lepsze pod względem dostępności, pod warunkiem, że zawartość jest w naturalnej kolejności i ma sens bez arkusza stylów. I nie tylko czytniki ekranu borykają się z układami bazującymi na tabelach: znacznie utrudniają również przeglądarkom mobilnym poprawne renderowanie strony.

Ponadto, dzięki układowi opartemu na div możesz bardzo łatwo zrobić fajne rzeczy z arkuszem stylów drukowania, takie jak wykluczenie nagłówków, stopek i nawigacji z drukowanych stron - myślę, że byłoby to niemożliwe, a przynajmniej znacznie trudniejsze, aby to zrobić z układem opartym na tabeli.

Jeśli wątpisz, że oddzielenie zawartości od układu jest łatwiejsze dzięki div niż tabelom, spójrz na HTML oparty na div w CSS Zen Garden , Zobacz, jak zmiana arkuszy stylów może drastycznie zmienić układ i zastanów się, czy możesz osiągnąć taką samą różnorodność układów, jeśli HTML był oparty na tabelach... Jeśli tworzysz układ oparty na tabelach, prawdopodobnie nie będziesz używać CSS do kontroluj wszystkie odstępy i wyściółki w komórkach (gdybyś był, prawie na pewno łatwiej byłoby używać pływających div itp. w pierwszej kolejności). Bez używania CSS do kontrolowania tego wszystkiego i ze względu na fakt, że tabele określają kolejność od lewej do prawej i od góry do dołu w HTML, tabele zwykle oznaczają, że układ staje się bardzo stały w HTML.

Realistycznie myślę, że bardzo trudno jest całkowicie zmienić układ projektu opartego na div I CSS bez zmiany trochę divów. Jednak dzięki układowi opartemu na div I CSS znacznie łatwiej jest dostosować odstępy między różnymi blokami i ich względne rozmiary.

Fakt, że jest to gorąco dyskutowane pytanie, jest świadectwem niepowodzenia W3C w przewidywaniu różnorodności projektów układu, które byłyby próbowane. Używanie divs+css dla semantycznie przyjaznego layoutu to świetna koncepcja, ale szczegóły implementacji są na tyle wadliwe, że faktycznie ograniczają swobodę twórczą.

Próbowałem przełączyć jedną ze stron naszej firmy z tabel na div-y i to był taki ból głowy, że całkowicie zmarnowałem godziny pracy, które w to włożyłem i wrócił do stolików. Próba zmagania się z moimi divami w celu uzyskania kontroli nad wyrównaniem pionowym przeklęła mnie poważnymi problemami psychologicznymi, których nigdy nie będę wstrząsał, dopóki ta debata szaleje.

Fakt, że ludzie muszą często wymyślać skomplikowane i brzydkie obejścia, aby osiągnąć proste cele projektowe (takie jak wyrównanie pionowe) silnie sugeruje, że zasady nie są wystarczająco elastyczne. Jeśli specyfikacje są wystarczające, to dlaczego witryny o wysokim profilu (jak tak) znajdują konieczne jest nagięcie zasad za pomocą tabel i innych obejść?

Myślę, że to prawda, że użycie elementu table dla układu ma niewiele wspólnego z danymi tabelarycznymi. I co z tego? Czy mój szef się tym przejmuje? Czy moi użytkownicy dbają?

Google i inne zautomatyzowane systemy dbają o to i są równie ważne w wielu sytuacjach. Kod semantyczny jest łatwiejszy dla nieinteligentnego systemu do parsowania i przetwarzania.

Po pracy z witryną internetową, która obejmowała 6 warstw zagnieżdżonych tabel wygenerowanych przez jakąś aplikację, i po wygenerowaniu nieprawidłowego HTML, naprawienie go było w rzeczywistości 3-godzinnym zadaniem, aby go naprawić.

Jest to oczywiście przypadek edge, ale konstrukcja oparta na tabelach jest niemożliwa do utrzymania. Jeśli używasz css, oddzielasz styl, więc przy naprawianiu HTML masz mniej zmartwień o złamanie.

Spróbuj również użyć JavaScript. Przenieś pojedynczą komórkę tabeli z jednej miejsce w innej tabeli. Dość skomplikowane do wykonania, gdzie div / span działa tylko kopiuj-wklej-wise.

"does my boss care"

Gdybym był twoim szefem. Obchodzi cię to. ;) Jeśli cenisz swoje życie.

Elastyczność układu
Wyobraź sobie, że tworzysz stronę z dużą liczbą miniaturek.
DIVs :
Jeśli umieścisz każdą miniaturkę w DIV-ie, to może 10 z nich zmieści się w rzędzie. Zrób okno węższe, i BAM-to jest 6 w rzędzie, lub 2, lub jak wiele pasuje.
Tabela:
Musisz wyraźnie powiedzieć, ile komórek jest w rzędzie. Jeśli okno jest zbyt wąskie, użytkownik musi przewijać w poziomie.

Maintainability
Ta sama sytuacja jak wyżej. Teraz chcesz dodać trzy miniatury do trzeciego rzędu.
DIVs:
Dodaj je. Układ zostanie automatycznie dopasowany.
Tabela: Wklej nowe komórki do trzeciego rzędu. Oops! Teraz jest tam zbyt wiele przedmiotów. Wytnij trochę z tego rzędu i umieść je w czwartym rzędzie. Teraz jest tam zbyt wiele przedmiotów. Wytnij trochę z tego rzędu... (etc)
( oczywiście, jeśli generujesz wiersze i komórki za pomocą skryptów po stronie serwera, prawdopodobnie nie będzie to problem.)

Myślę, że ta łódź już odpłynęła. Jeśli spojrzysz na kierunek, w którym obrała się branża, zauważysz, że CSS i otwarte standardy są zwycięzcami tej dyskusji. Co z kolei oznacza, że dla większości prac html, z wyjątkiem formularzy, projektanci będą używać divs zamiast tabel. Ciężko mi z tym, ponieważ nie jestem guru CSS, ale tak jest.

Nie zapominaj również, że tabele nie renderują się dobrze w przeglądarkach mobilnych. Oczywiście, iPhone ma kick-ass przeglądarki, ale każdy nie ma iPhone. Renderowanie tabel może być orzeszki ziemne dla nowoczesnych przeglądarek, ale jest to kilka arbuzów dla przeglądarek mobilnych.

Osobiście odkryłem, że wiele osób używa zbyt wielu tagów <div>, ale z umiarem może być niezwykle czysty i łatwy do odczytania. Wspominasz, że ludzie mają trudniej czytać CSS niż tabele; jeśli chodzi o "kod" to może to prawda, ale jeśli chodzi o czytanie treści (widok > źródło), o wiele łatwiej jest zrozumieć strukturę arkuszy stylów niż tabel.

Wygląda na to, że jesteś przyzwyczajony do tabel i tyle. Umieszczenie układu w tabeli ogranicza cię tylko do tego układu. Dzięki CSS możesz przenosić bity, spójrz na http://csszengarden.com/ I nie, Układ zwykle nie wymaga wielu zagnieżdżonych div.

Bez tabel dla układu i odpowiedniej semantyki HTML jest dużo czystszy, przez co łatwiejszy do odczytania. Dlaczego ktoś, kto nie rozumie CSS, powinien spróbować go przeczytać? A jeśli ktoś uważa się za webdevelopera to dobrze opanowanie CSS jest koniecznością.

Korzyści SEO wynikają z możliwości posiadania najważniejszych treści wyżej na stronie i lepsze proporcje treści do znaczników.

Http://www.hotdesign.com/seybold/

• 508 Zgodność - zdolność czytnika ekranu, aby zrozumieć Twoje znaczniki.
• oczekiwanie na renderowanie-tabele nie renderują się w przeglądarce, dopóki nie dotrze do końca elementu </table>.

Cała idea wokół znaczników semantycznych polega na rozdzieleniu znaczników i prezentacji, która obejmuje układ.

Div nie zastępują tabel, mają własne zastosowanie w rozdzielaniu treści na bloki powiązanych treści (, ). Jeśli nie masz umiejętności i polegasz na tabelach, często będziesz musiał oddzielić zawartość do komórek, aby uzyskać pożądany układ, ale nie musisz dotykać znaczników, aby uzyskać prezentację podczas korzystania ze znaczników semantycznych. To jest naprawdę ważne, gdy znaczniki są generowane, a nie statyczne strony.

Deweloperzy muszą przestać dostarczać znaczniki, które implikują układ, aby ci z nas, którzy mają umiejętności prezentowania treści, mogli zająć się naszymi zadaniami, a deweloperzy nie muszą wracać do swojego kodu, aby wprowadzać zmiany, gdy prezentacja wymaga zmiany.

Tu tak naprawdę nie chodzi o to, czy 'div są lepsze niż tabele dla układu'. Ktoś, kto rozumie CSS, może powielić dowolny projekt za pomocą "tabel układu" całkiem prosto. Prawdziwą wygraną jest używanie elementów HTML do tego, do czego są potrzebne. Powodem, dla którego nie używasz tabel dla danych nie-tabularnych, jest ten sam powód, dla którego nie przechowujesz liczb całkowitych jako ciągów znaków - technologia działa znacznie łatwiej, gdy używasz jej do celów, dla których jest zaprojektowana. Jeśli kiedykolwiek konieczne było użycie tabele dla layoutu (z powodu braków w przeglądarce na początku lat 90.) na pewno nie jest teraz.

Narzędzia wykorzystujące układy tabel mogą stać się wyjątkowo ciężkie ze względu na ilość kodu wymaganego do utworzenia układu. Portal Netweaver firmy SAP domyślnie używa tabeli do układania stron.

Portal SAP produkcji na moim obecnym koncercie ma stronę główną, której HTML waży ponad 60K i przechodzi siedem tabel głęboko, trzy razy w obrębie strony. Dodaj do tego Javascript, niewłaściwe użycie 16 ramek iFrame z podobnymi problemami z tabelami wewnątrz nich, zbyt ciężki CSS itp., a strona waży ponad 5MB.

Poświęcenie czasu, aby obniżyć wagę strony, abyś mógł wykorzystać swoją przepustowość do wykonywania angażujących działań z użytkownikami, jest warte wysiłku.

Warto zastanowić się nad CSS i divs, aby centralna kolumna treści ładowała się i renderowała przed paskiem bocznym w układzie strony. Ale jeśli masz problemy z używaniem pływających div do pionowego wyrównania logo z tekstem sponsoringu, po prostu Użyj tabeli i ruszaj z życiem. Religia ogrodów Zen nie daje za wygraną.

Ideą oddzielania treści od prezentacji jest podział aplikacji tak, aby różne rodzaje pracy wpływały na różne bloki kodu. To chodzi o zarządzanie zmianami. Ale standardy kodowania mogą badać obecny stan kodu tylko powierzchownie.

Dziennik zmian dla aplikacji, która zależy od standardów kodowania w celu "oddzielenia treści od prezentacji", pokaże wzór równoległych zmian w pionowych silosach. Jeśli zmianie Na "treść" zawsze towarzyszy zmiana na "prezentację", jak skuteczne jest partycjonowanie?

Jeśli naprawdę chcesz partycjonować swój kod, użyj Subversion i przejrzyj dzienniki zmian. Następnie użyj najprostszych technik kodowania-divs, tables, JavaScript, includes, functions, objects, continuations, whatever-aby uporządkować aplikację tak, aby zmiany pasowały w prosty i wygodny sposób.

Ponieważ utrzymanie strony, która używa tabel, to piekło, a kodowanie zajmuje dużo więcej czasu. Jeśli boisz się pływających div, idź na kurs w nich. Nie są trudne do zrozumienia i są około 100 razy bardziej wydajne i milion razy mniej upierdliwe (chyba, że ich nie rozumiesz-ale Witaj w świecie komputerów).

Ktoś, kto rozważa wykonanie układu z tabelą, lepiej nie oczekiwać, że będę go utrzymywać. To najbardziej tyłkowy sposób do renderowania strony internetowej. Dzięki Bogu mamy teraz lepszą alternatywę. Nigdy bym nie wrócił.

To przerażające, że niektórzy ludzie mogą nie być świadomi korzyści czasu i energii z tworzenia witryny przy użyciu nowoczesnych narzędzi.

Tabele nie są ogólnie łatwiejsze lub łatwiejsze do utrzymania niż CSS. Istnieje jednak kilka specyficznych układów , w których tabele są rzeczywiście najprostszym i najbardziej elastycznym rozwiązaniem.

CSS jest wyraźnie korzystniejszy w przypadkach, gdy znaczniki prezentacyjne i CSS wspierają ten sam rodzaj projektu, nikt przy zdrowych zmysłach nie argumentowałby, że font - tagi są lepsze niż określanie typografii w CSS, ponieważ CSS daje taką samą moc jak font - tagi, ale w znacznie czystszym stylu sposób.

Problem z tabelami polega jednak zasadniczo na tym, że model układu tabel w CSS nie jest obsługiwany w programie Microsoft Internet Explorer. Tabele i CSS są więc nie równoważne w mocy. Brakującą częścią jest zachowanie siatkowe tabel, gdzie krawędzie komórek wyrównują się zarówno w pionie, jak i w poziomie, podczas gdy komórki nadal rozszerzają się, aby zawierać swoją zawartość. To zachowanie nie jest łatwe do osiągnięcia w czystym CSS bez twardego kodowania niektórych wymiarów, co sprawia, że projekt sztywne i kruche (o ile musimy wspierać Internet Explorer - w innych przeglądarkach jest to łatwe do osiągnięcia przez użycie display:table-cell).

Więc tak naprawdę nie chodzi o to, czy tabele czy CSS są lepsze, ale o rozpoznanie konkretnych przypadków, w których użycie tabel może uczynić układ bardziej elastycznym.

Najważniejszym powodem, dla którego nie używa tabel jest dostępność. Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10 / porady nie używaj tabel do układania. Jeśli martwisz się o dostępność (a w niektórych przypadkach możesz być do tego prawnie zobowiązany), powinieneś używać CSS nawet jeśli tabele są prostsze. Zauważ, że możesz Zawsze utworzyć ten sam układ za pomocą CSS, co w przypadku tabel, może to wymagać więcej pracy.

Byłem zaskoczony, że niektóre kwestie nie zostały jeszcze omówione, więc oto moje 2 centy, oprócz wszystkich ważnych punktów przedstawionych wcześniej:

.1. CSS & SEO:

A) CSS miał bardzo istotny wpływ na SEO, pozwalając na pozycjonowanie treści na stronie w dowolnym miejscu. Kilka lat temu Wyszukiwarki kładły duży nacisk na czynniki "na stronie". Coś na górze strony uznano za bardziej istotne dla strony niż coś znajdującego się na dno. "Góra strony" dla pająka oznacza "na początku kodu". Korzystając z CSS, możesz uporządkować zawartość bogatą w słowa kluczowe na początku kodu i nadal umieszczać ją w dowolnym miejscu na stronie. Jest to nadal dość istotne, ale czynniki na stronie są coraz mniej ważne dla rankingu stron.

B) po przeniesieniu układu do CSS, strona HTML jest lżejsza i dlatego ładuje się szybciej dla pająka Wyszukiwarki. (pająki nie przejmują się pobieraniem zewnętrznego css plików). Szybkie ładowanie stron jest ważnym czynnikiem rankingowym dla kilku wyszukiwarek, w tym Google

C) praca SEO często wymaga testowania i zmiany rzeczy, co jest znacznie wygodniejsze w przypadku układu opartego na CSS

.2. wygenerowana treść:

Tabela jest znacznie łatwiejsza do wygenerowania programowo niż równoważny układ CSS.

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

Generowanie tabeli jest proste i bezpieczne. Jest samowystarczalny i dobrze integruje się z dowolnym szablonem. Na zrób to samo z CSS jest znacznie trudniejsze i może nie przynieść żadnych korzyści: trudno edytować arkusz stylów CSS w locie, a dodanie stylu inline nie różni się od korzystania z tabeli (zawartość nie jest oddzielona od układu).

Ponadto, gdy tabela jest generowana, zawartość (w zmiennych) jest już oddzielona od układu (w kodzie), dzięki czemu można ją łatwo modyfikować.

Jest to jeden z powodów, dla których niektóre bardzo dobrze zaprojektowane strony internetowe (tak na przykład) nadal używają tabeli układy.

Oczywiście, jeśli wyniki muszą być obsługiwane przez JavaScript, divs są warte zachodu.

.3. testowanie szybkiej konwersji

Gdy zastanawiamy się, co działa dla konkretnej grupy odbiorców, warto mieć możliwość zmiany układu na różne sposoby, aby dowiedzieć się, co daje najlepsze wyniki. Układ oparty na CSS znacznie ułatwia

.4. różne rozwiązania różnych problemów

Tabele układu są zwykle dissowane ponieważ "wszyscy wiedzą, że divs & CSS" to najlepsza droga.

Faktem jest jednak, że tabele są szybsze w tworzeniu, łatwiejsze do zrozumienia i bardziej wytrzymałe niż większość układów CSS. (Tak, CSS może być równie solidny, ale szybkie spojrzenie przez sieć w różnych przeglądarkach i rozdzielczościach ekranu pokazuje, że nie jest to często przypadek)

Istnieje wiele wad tabel, w tym konserwacja, brak elastyczności... ale nie wyrzucajmy dziecka z wodą do kąpieli. Jest mnóstwo profesjonalne Zastosowania dla rozwiązania, które jest szybkie i niezawodne.

Jakiś czas temu musiałem przepisać czysty i prosty układ CSS za pomocą tabel, ponieważ znaczna część użytkowników używałaby starszej wersji IE z naprawdę złym wsparciem dla CSS

Jeśli chodzi o tłum "to nie było przeznaczone do tego celu i dlatego nie powinieneś tego używać w ten sposób", czyż nie jest to hipokryzja? Co sądzisz o wszystkich sztuczkach CSS, których musisz użyć, aby to cholerstwo działało w większości przeglądarek? Czy były one przeznaczone do tego celu?