Dlaczego nie użyć tabel do układu w HTML? [Zamknięte]

Wydaje się być ogólną opinią, że tabele nie powinny być używane do układu w HTML.

Dlaczego?

Nigdy nie widziałem (lub rzadko szczerze mówiąc) dobrych argumentów na to. Typowe odpowiedzi to:

• Dobrze jest oddzielić zawartość od układu,
  ale jest to błędny argument; Myślenie stereotypowe . Wydaje mi się, że to prawda, że ​​użycie elementu tabeli do układu ma niewiele wspólnego z danymi tabelarycznymi. Więc co? Czy mój szef się przejmuje? Czy obchodzą mnie użytkownicy?
  
  Być może ja lub moi programiści, którzy muszą dbać o stronę internetową ... Czy stół jest mniej konserwowalny? Myślę, że używanie tabeli jest łatwiejsze niż używanie div i CSS.
  
  Nawiasem mówiąc ... dlaczego używanie div lub span nie jest dobrym oddzieleniem treści od układu i tabeli? Uzyskanie dobrego układu tylko z divami często wymaga dużej ilości zagnieżdżonych div.

• Czytelność kodu
  Myślę, że jest na odwrót. Większość ludzi rozumie HTML, niewielu rozumie CSS.

• Lepiej dla SEO nie używać tabel
  Dlaczego? Czy ktoś może udowodnić, że tak jest? Lub oświadczenie Google, że stoły są zniechęcane z punktu widzenia SEO?

• Tabele są wolniejsze.
  Należy wstawić dodatkowy element tbody. To jest orzeszki ziemne dla nowoczesnych przeglądarek internetowych. Pokaż mi niektóre testy porównawcze, w których użycie tabeli znacznie spowalnia stronę.

• Przegląd układu jest łatwiejszy bez tabel, patrz css Zen Garden .
  Większość stron internetowych, które wymagają aktualizacji, również potrzebuje nowej treści (HTML). Scenariusze, w których nowa wersja strony wymaga tylko nowego pliku CSS, są mało prawdopodobne. Zen Garden to fajna strona internetowa, ale trochę teoretyczna. Nie wspominając o niewłaściwym użyciu CSS.

Naprawdę interesują mnie dobre argumenty do używania div + CSS zamiast tabel.

Omówię kolejno wasze argumenty i spróbuję pokazać w nich błędy.

Dobrze jest oddzielić zawartość od układu, ale jest to błędny argument; Myślenie stereotypowe.

To wcale nie jest błędne, ponieważ HTML został zaprojektowany celowo. Niewłaściwe użycie elementu może nie być całkowicie wykluczone (w końcu nowe idiomy rozwinęły się również w innych językach), ale możliwe negatywne implikacje muszą zostać zrównoważone. Dodatkowo, nawet jeśli nie było argumentów przeciwko niewłaściwemu użyciu tego <table>elementu dzisiaj, może być jutro z powodu sposobu, w jaki dostawcy przeglądarki stosują specjalne traktowanie tego elementu. W końcu wiedzą, że „ <table>elementy są tylko dla danych tabelarycznych” i mogą wykorzystać ten fakt, aby poprawić silnik renderowania, w procesie subtelnie zmieniając <table>zachowanie się, a tym samym rozbijając przypadki, w których wcześniej był niewłaściwie wykorzystywany.

Więc co? Czy mój szef się przejmuje? Czy obchodzą mnie użytkownicy?

Zależy. Czy twój szef jest spiczasty? Wtedy może go to nie obchodzi. Jeśli jest kompetentna, będzie ją to obchodzić, ponieważ użytkownicy będą .

Być może ja lub moi programiści, którzy muszą dbać o stronę internetową ... Czy stół jest mniej konserwowalny? Myślę, że używanie tabeli jest łatwiejsze niż używanie divs i css.

Większość profesjonalnych programistów wydaje się być przeciwna^{[ potrzebne źródło ]} . To, że tabele są mniej konserwowalne, powinno być oczywiste. Użycie tabel do układu oznacza, że ​​zmiana układu korporacyjnego w rzeczywistości oznacza zmianę każdej pojedynczej strony. To może być bardzo drogie. Z drugiej strony rozsądne użycie semantycznie znaczącego HTML w połączeniu z CSS może ograniczyć takie zmiany do CSS i użytych zdjęć.

Nawiasem mówiąc ... dlaczego używanie div lub span nie jest dobrym oddzieleniem treści od układu i tabeli? Uzyskanie dobrego układu tylko z divami często wymaga dużej ilości zagnieżdżonych div.

Głęboko zagnieżdżone <div>s są anty-wzorami, podobnie jak układy tabel. Dobrzy projektanci stron internetowych nie potrzebują wielu z nich. Z drugiej strony, nawet tak głęboko zagnieżdżone divy nie mają wielu problemów z układami tabel. W rzeczywistości mogą nawet przyczynić się do struktury semantycznej, logicznie dzieląc zawartość na części.

Czytelność kodu Myślę, że jest na odwrót. Większość ludzi rozumie html, mało rozumie css. To jest prostsze.

„Większość ludzi” nie ma znaczenia. Specjaliści mają znaczenie. Dla profesjonalistów układy tabel powodują znacznie więcej problemów niż HTML + CSS. To tak, jakby powiedzieć, że nie powinienem używać GVima ani Emacsa, ponieważ Notatnik jest prostszy dla większości ludzi. Albo że nie powinienem używać LaTeXa, ponieważ MS Word jest prostszy dla większości ludzi.

SEO lepiej nie używać tabel

Nie wiem, czy to prawda i nie użyłbym tego jako argumentu, ale byłoby to logiczne. Wyszukiwarki wyszukują odpowiednie dane. Chociaż dane tabelaryczne mogą być oczywiście istotne, rzadko szukają tego użytkownicy. Użytkownicy szukają terminów użytych w tytule strony lub podobnie widocznych pozycjach. Logiczne byłoby zatem wykluczenie filtrowania treści tabelarycznych, a tym samym znaczne skrócenie czasu przetwarzania (i kosztów!).

Tabele są wolniejsze. Należy wstawić dodatkowy element tbody. To jest orzeszki ziemne dla nowoczesnych przeglądarek internetowych.

Dodatkowy element nie ma nic wspólnego z wolniejszymi tabelami. Z drugiej strony algorytm układu tabel jest znacznie trudniejszy, przeglądarka często musi czekać na załadowanie całej tabeli, zanim zacznie układać zawartość. Dodatkowo buforowanie układu nie będzie działać (CSS można łatwo buforować). Wszystko to zostało wspomniane wcześniej.

Pokaż mi niektóre testy porównawcze, w których użycie tabeli znacznie spowalnia stronę.

Niestety nie mam żadnych danych porównawczych. Byłbym zainteresowany tym sam, ponieważ to prawda, że ​​ten argument nie ma pewnego rygoru naukowego.

Większość stron internetowych, które wymagają aktualizacji, również potrzebuje nowej zawartości (HTML). Scenariusze, w których nowa wersja strony wymaga tylko nowego pliku css, są mało prawdopodobne.

Ani trochę. Pracowałem nad kilkoma przypadkami, w których zmiana projektu została uproszczona przez rozdzielenie treści i projektu. Często nadal konieczna jest zmiana kodu HTML, ale zmiany zawsze będą znacznie bardziej ograniczone. Ponadto zmiany konstrukcyjne muszą być czasami wprowadzane dynamicznie. Zastanów się nad silnikami szablonów, takimi jak ten wykorzystywany przez system blogowy WordPress. Układy tabel dosłownie zabiłyby ten system. Pracowałem nad podobną sprawą dla oprogramowania komercyjnego. Możliwość zmiany projektu bez zmiany kodu HTML była jednym z wymagań biznesowych.

Inna rzecz. Układ tabeli znacznie utrudnia automatyczne analizowanie stron internetowych (zgarnianie ekranu). To może brzmieć trywialnie, bo przecież kto to robi? Sam byłem zaskoczony. Skrobanie ekranu może bardzo pomóc, jeśli dana usługa nie oferuje alternatywy dla WebService dostępu do jej danych. Pracuję w bioinformatyce, gdzie jest to smutna rzeczywistość. Nowoczesne techniki sieciowe i usługi sieciowe nie dotarły do ​​większości programistów i często skrobanie ekranu jest jedynym sposobem zautomatyzowania procesu pozyskiwania danych. Nic dziwnego, że wielu biologów wciąż wykonuje takie zadania ręcznie. Dla tysięcy zestawów danych.

Oto odpowiedź mojego programisty z podobnego wątku

Semantyka 101

Najpierw spójrz na ten kod i zastanów się, co tu jest nie tak ...

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

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

Problem polega oczywiście na tym, że rower nie jest samochodem. Klasa samochodu jest nieodpowiednia dla instancji roweru. Kod jest wolny od błędów, ale jest semantycznie niepoprawny. To źle odbija się na programatorze.

Semantyka 102

Teraz zastosuj to do znaczników dokumentów. Jeśli twój dokument musi zawierać dane tabelaryczne, odpowiednim znacznikiem będzie <table>. Jeśli jednak umieścisz nawigację w tabeli, niewłaściwie wykorzystasz zamierzony cel <table>elementu. W drugim przypadku nie prezentujesz danych tabelarycznych - (nie) używasz <table>elementu do osiągnięcia celu prezentacji.

Wniosek

Czy odwiedzający to zauważą? Nie. Czy twój szef się przejmuje? Może. Czy czasami skracamy rogi jako programiści? Pewnie. Ale powinniśmy? Nie. Kto skorzysta, jeśli użyjesz znaczników semantycznych? Ty - i twoja profesjonalna reputacja. Teraz idź i zrób właściwą rzecz.

Oczywista odpowiedź: patrz 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 na pewno użyj tabel do układu.

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

Obie dbają o to, w jakiej kolejności prezentowane są informacje. Nie możesz łatwo zaprezentować nawigacji na górze strony, jeśli układ oparty na tabeli umieszcza ją w 3. komórce 2. rzędu 2. zagnieżdżonej tabeli na stronie.

Więc twoje odpowiedzi to łatwość konserwacji, 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ą nieco trudniejsze do nauczenia się.

Zobacz to zduplikowane pytanie.

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

Myślę też, że nie doceniasz wpływu niektórych rzeczy wymienionych w pytaniu. Na przykład, jeśli jesteś zarówno projektantem, jak i programistą, możesz nie w pełni docenić, jak dobrze oddziela prezentację od treści. Ale kiedy wejdziesz do sklepu, w którym pełnią dwie różne role, zalety stają się coraz wyraźniejsze.

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

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

W związku z tym strona internetowa, której celem jest wykazanie korzyści z utrzymywania projektu poza treścią, obecnie regularnie popełnia NIEZWYKŁANY GRZEWSTWO wprowadzenia treści do projektu. (Jeśli nagłówek sekcji w pliku HTML miałby się zmienić, wyświetlany nagłówek sekcji nie zmieniłby się).

Co tylko pokazuje, że nawet ci, którzy opowiadają się za ścisłą religią DIV i CSS, nie mogą przestrzegać własnych zasad. Możesz wykorzystać to jako wskazówkę, jak ściśle ich przestrzegasz.

W żadnym wypadku nie jest to ostateczny argument, ale dzięki CSS możesz wziąć ten sam znacznik i zmienić układ w zależności od medium, co jest niezłą zaletą. W przypadku strony do wydruku możesz cicho ukryć nawigację bez konieczności tworzenia na przykład strony do wydruku.

Jeden stół do układu nie byłby taki zły. Ale nie możesz uzyskać potrzebnego układu tylko przy jednym stole. Wkrótce masz 2 lub 3 zagnieżdżone tabele. To staje się bardzo kłopotliwe.

• O wiele trudniej jest czytać. To nie zależy od opinii. Jest tylko więcej zagnieżdżonych tagów bez oznaczeń identyfikujących.

• Oddzielanie treści od prezentacji jest dobrą rzeczą, ponieważ pozwala skupić się na tym, co robisz. Mieszanie tych dwóch prowadzi do nadętych, trudnych do odczytania stron.

• CSS dla stylów pozwala twojej przeglądarce buforować pliki, a kolejne żądania są znacznie szybsze. To jest ogromne.

• Tabele zamykają cię w projekt. Jasne, nie każdy potrzebuje elastyczności Zen Garden CSS, ale nigdy nie pracowałem na stronie, na której nie musiałem tu i ówdzie trochę zmieniać projektu. Z CSS jest znacznie łatwiej.

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

Nie korzystałem z tabel dla danych nie tabelarycznych od prawdopodobnie 4 lat. Nie oglądałem się za siebie.

Naprawdę chciałbym zasugerować przeczytanie CSS Mastery autorstwa Andy'ego Budd'a. To jest fantastyczne.

Zdjęcie 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 układu,
ale jest to błędny argument; Myślenie stereotypowe

To błędny argument, ponieważ tabele HTML mają układ! Treść 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 elementów div nie różni się od tabeli - to po prostu inny zestaw tagów.

Innym problemem związanym z oddzielaniem kodu HTML od CSS jest to, że potrzebują one wzajemnej znajomości - naprawdę nie można ich całkowicie oddzielić. Układ znaczników w kodzie HTML jest ściśle powiązany z plikiem CSS bez względu na to, co robisz.

Myślę, że tabele vs. div sprowadzają się do potrzeb twojej aplikacji.

W aplikacji, którą tworzymy w pracy, potrzebowaliśmy układu strony, w którym elementy dynamicznie dostosowywałyby się do swojej zawartości. Spędziłem dni próbując sprawić, by działało w różnych przeglądarkach z CSS i DIV i był to kompletny koszmar. Przeszliśmy do stolików i wszystko po prostu działało .

Mamy jednak bardzo zamkniętą grupę odbiorców naszego produktu (sprzedajemy sprzęt z interfejsem sieciowym), a problemy z dostępnością nie są dla nas problemem. Nie wiem, dlaczego czytniki ekranu nie radzą sobie dobrze z tabelami, ale chyba tak to jest, to programiści muszą sobie z tym poradzić.

CSS / DIV - to tylko praca dla projektantów, prawda? Setki godzin, które spędziłem na debugowaniu problemów DIV / CSS, przeszukiwaniu Internetu, aby uzyskać część znaczników podczas pracy z niejasną przeglądarką - doprowadza mnie to do szału. Dokonujesz jednej drobnej zmiany, a cały układ idzie strasznie źle - logika w tym jest zła. Spędzanie godzin na przenoszeniu czegoś o 3 piksele w ten sposób, a następnie o coś innego o 2 piksele w drugą stronę, aby je wszystkie wyrównać. Wydaje mi się to po prostu błędne. To, że jesteś purystą, a coś jest „niewłaściwe”, nie oznacza, że ​​powinieneś z niego korzystać w stopniu n-tym i we wszystkich okolicznościach, szczególnie jeśli to uczyni twoje życie 1000 razy łatwiejszym.

W końcu zdecydowałem, czysto komercyjnie, chociaż ograniczam się do minimum, jeśli spodziewam się 20 godzin pracy na poprawne umieszczenie DIV, pozostanę przy stole. To źle, denerwuje purystów, ale w większości przypadków kosztuje mniej czasu i jest tańszy w zarządzaniu. Następnie mogę skoncentrować się na tym, aby aplikacja działała tak, jak chce klient, zamiast zadowolić purystów. W końcu płacą rachunki, a mój argument skierowany do menedżera, który egzekwuje stosowanie CSS / DIV - chciałbym jedynie wskazać, że klienci płacą również jego pensję!

Jedynym powodem, dla którego występują wszystkie te argumenty CSS / DIV, jest przede wszystkim niedociągnięcie CSS i ponieważ przeglądarki nie są ze sobą kompatybilne, a gdyby tak było, połowa projektantów stron internetowych na świecie byłaby bez pracy .

Podczas projektowania formularza systemu Windows nie próbujesz przesuwać elementów sterujących po ich rozmieszczeniu, więc myślę, że to dziwne, dlaczego chcesz to zrobić za pomocą formularza internetowego. Po prostu nie rozumiem tej logiki. Ułóż układ od samego początku i na czym polega problem. Myślę, że to dlatego, że projektanci lubią flirtować z kreatywnością, podczas gdy twórcy aplikacji są bardziej zainteresowani faktycznym uruchomieniem aplikacji, tworzeniem obiektów biznesowych, wdrażaniem reguł biznesowych, sprawdzaniem, w jaki sposób fragmenty danych klientów odnoszą się do siebie, zapewniając, że rzecz spełnia klientów wymagania - wiesz - jak rzeczy z prawdziwego świata.

Nie zrozum mnie źle, oba argumenty są prawidłowe, ale proszę nie krytykuj programistów za wybranie łatwiejszego, bardziej logicznego podejścia do projektowania formularzy. Często musimy martwić się ważniejszymi kwestiami niż poprawna semantyka używania tabeli nad div.

Przypadek - na podstawie tej dyskusji przekonwertowałem kilka istniejących tds i trs na div. 45 minut bawiąc się tym, próbując ustawić wszystko obok siebie, a ja się poddałem. TD z powrotem w 10 sekund później - działa - od razu - we wszystkich przeglądarkach, nic więcej do roboty. Proszę, spróbuj mnie zrozumieć - jakie masz uzasadnienie, że chcesz, abym zrobił to w inny sposób!

Układ powinien być łatwy. Fakt, że w CSS napisano artykuły o tym, jak osiągnąć dynamiczny układ trzech kolumn z nagłówkiem i stopką, świadczy o tym, że jest to zły układ. Oczywiście możesz go uruchomić, ale istnieją dosłownie setki artykułów online o tym, jak to zrobić. Nie ma prawie żadnych 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 korzyść CSS, ten jeden fakt odwraca to wszystko: podstawowy układ trzech kolumn w CSS jest często nazywany „Świętym Graalem”.

Jeśli to nie oznacza, że ​​mówisz „WTF”, to naprawdę musisz teraz odłożyć pomoc kool.

Uwielbiam CSS. Oferuje niesamowite opcje stylizacji i kilka fajnych narzędzi do pozycjonowania, ale jako silnik układu jest niewystarczający. Potrzebny jest jakiś rodzaj dynamicznego systemu pozycjonowania siatki. Prosty sposób na wyrównanie ramek na wielu osiach bez uprzedniej znajomości ich rozmiarów. Nie obchodzi mnie to, jeśli nazwiesz to <tabela> lub <gridlayout> czy cokolwiek innego, ale jest to podstawowa funkcja układu, której brakuje w CSS.

Większy problem polega na tym, że nie przyznając się do brakujących funkcji, fanatycy CSS powstrzymują CSS od wszystkiego, co mogłoby być. Byłbym bardzo szczęśliwy, mogąc przestać używać tabel, jeśli CSS zapewnia przyzwoite pozycjonowanie siatki w wielu osiach, jak w zasadzie każdy inny silnik układu na świecie. (Zdajesz sobie sprawę, że ten problem został już rozwiązany wiele razy w wielu językach przez wszystkich oprócz W3C, prawda? I nikt inny nie zaprzeczył, że taka funkcja była przydatna).

Westchnienie. Dość wentylacji. Śmiało i wbij głowę w piasek.

Zgodnie ze zgodnością 508 (w przypadku czytników ekranu dla osób niedowidzących) tabele powinny być używane wyłącznie do przechowywania danych, a nie do układu, ponieważ powoduje to dziwne zachowanie czytników ekranu. A przynajmniej tak mi powiedziano.

Jeśli przypiszesz nazwy do każdego z div, możesz je wszystkie skórować razem za pomocą CSS. To tylko trochę trudniej usiąść tak, jak potrzebujesz.

Oto sekcja html z ostatniego 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>

A 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 stole, jest to, że jestem nadgorliwy z powodu mojego wcięcia. Jestem pewien, że sekcja zawartości będzie miała jeszcze dwie osadzone tabele.

Kolejna rzecz do przemyślenia: rozmiary plików . Przekonałem się, że układy tabel są zwykle dwa razy większe niż ich odpowiedniki CSS. W naszym szybkim łączu szerokopasmowym nie jest to duży problem, ale dotyczy to modemów telefonicznych.

Chciałbym dodać, że układy oparte na div są łatwiejsze do zarządzania, ewolucji i refaktoryzacji. Tylko kilka zmian w CSS, aby zmienić kolejność elementów i gotowe. Z mojego doświadczenia wynika, że ​​przeprojektowanie układu wykorzystującego tabele to koszmar (więcej, jeśli istnieją tabele zagnieżdżone).

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

Żadne argumenty w DIV nie sprzyjają mi.

Powiedziałbym: jeśli but pasuje, noś go.

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

To trochę przesuwa równowagę w stronę tabel w większości moich układów i chociaż czuję się winny z ich używania (nie wiem dlaczego, ludzie po prostu mówią, że to źle, więc próbuję ich słuchać), w końcu pragmatyczny pogląd jest taki, że to po prostu łatwiej i szybciej korzystam z TABEL. Nie płacą mi godziny, więc stoliki są dla mnie tańsze.

Układy CSS są ogólnie o wiele lepsze pod względem dostępności, pod warunkiem, że treść jest w naturalnej kolejności i ma sens bez arkusza stylów. I nie tylko czytniki ekranu mają problemy z układami opartymi na tabelach: znacznie utrudniają również prawidłowe wyświetlanie strony przez przeglądarki mobilne.

Ponadto dzięki układowi opartemu na div możesz bardzo łatwo robić fajne rzeczy za pomocą arkusza stylów drukowania, takiego jak wykluczanie nagłówków, stopek i nawigacji z drukowanych stron - myślę, że byłoby to niemożliwe, a przynajmniej znacznie trudniejsze, aby to zrobić za pomocą układ oparty na tabeli.

Jeśli masz wątpliwości, że oddzielenie treści od układu jest łatwiejsze w przypadku div niż w tabelach, spójrz na HTML oparty na div w CSS Zen Garden , zobacz, jak zmiana arkuszy stylów może radykalnie 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 tabeli ... Jeśli robisz układ oparty na tabeli, prawdopodobnie nie używasz CSS do kontrolowania wszystkich odstępów i wypełnienia w komórkach (jeśli tak, to prawie na pewno łatwiej będzie użyć pływających div itp.). Bez użycia CSS do kontrolowania tego wszystkiego, a także z uwagi na fakt, że tabele określają kolejność elementów od lewej do prawej i od góry do dołu w tabelach, tabele zwykle oznaczają, że układ bardzo się poprawia w HTML.

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

Fakt, że jest to gorąco dyskutowane pytanie, świadczy o tym, że W3C nie przewidział różnorodności projektów układu, które byłyby podejmowane. Używanie divs + css do semantycznie przyjaznego układu jest świetną koncepcją, ale szczegóły implementacji są tak błędne, że faktycznie ograniczają swobodę twórczą.

Próbowałem zamienić jedną z witryn naszej firmy ze stolików na divy i było to tak bolesne, że całkowicie zmarnowałem godziny pracy, które w nie włożyłem i wróciłem do stolików. Próba zmagania się z moimi divami w celu uzyskania kontroli nad pionowym wyrównaniem przeklęła mnie głównymi problemami psychologicznymi, których nigdy nie będę się trząść, dopóki trwa ta debata.

Fakt, że ludzie często muszą wymyślać złożone i brzydkie obejścia, aby osiągnąć proste cele projektowe (takie jak wyrównanie pionowe), zdecydowanie sugeruje, że reguły nie są wystarczająco elastyczne. Jeśli specyfikacje są wystarczające, dlaczego witryny o wysokim profilu (takie jak SO) uważają za konieczne naginanie reguł za pomocą tabel i innych obejść?

Wydaje mi się, że to prawda, że ​​użycie elementu tabeli do układu ma niewiele wspólnego z danymi tabelarycznymi. Więc co? Czy mój szef się przejmuje? Czy obchodzą mnie użytkownicy?

Google i inne zautomatyzowane systemy zrobić opieki, i są one tak samo ważne w wielu sytuacjach. Kod semantyczny jest łatwiejszy do przeanalizowania i przetworzenia przez nie-inteligentny system.

Musiałem współpracować ze stroną internetową, która obejmowała 6 warstw zagnieżdżonych tabel wygenerowanych przez jakąś aplikację, i po wygenerowaniu niepoprawnego HTML-a, w rzeczywistości było 3 godziny pracy, aby naprawić to zepsucie dla drobnej zmiany.

Jest to oczywiście przypadek na krawędzi, ale konstrukcja oparta na stole jest nie do utrzymania. Jeśli używasz css, rozdzielasz styl, więc przy naprawianiu HTML nie musisz się już martwić o złamanie.

Spróbuj również z JavaScript. Przenieś pojedynczą komórkę tabeli z jednego miejsca do innego miejsca w innym stole. Raczej skomplikowane wykonywanie tam, gdzie div / span działałoby po prostu kopiuj-wklej.

„Czy mój szef się przejmuje”

Gdybym był twoim szefem. Zależy ci na tym. ;) Jeśli cenisz swoje życie.

Elastyczność układu
Wyobraź sobie, że tworzysz stronę z dużą liczbą miniatur.
DIV :
Jeśli umieścisz każdą miniaturę w DIV, uniesie się w lewo, może 10 z nich zmieści się w rzędzie. Uczyń okno węższym, a BAM - to 6 w rzędzie lub 2, lub jakkolwiek 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.

Konserwowalność Taka
sama sytuacja jak powyżej. Teraz chcesz dodać trzy miniatury do trzeciego rzędu.
DIV:
dodaj je. Układ dostosuje się automatycznie.
TABELA: Wklej nowe komórki do trzeciego rzędu. Ups! 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 wiersza ... (itp.)
( Oczywiście, jeśli generujesz wiersze i komórki za pomocą skryptów po stronie serwera, prawdopodobnie nie będzie to problemem ).

Myślę, że ta łódź wypłynęła. Jeśli spojrzysz na kierunek, w którym podążyła branża, zauważysz, że CSS i otwarte standardy są zwycięzcami tej dyskusji. Co z kolei oznacza większość prac HTML, z wyjątkiem formularzy, projektanci użyją div zamiast tabel. Mam z tym problem, ponieważ nie jestem guru CSS, ale tak już jest.

Nie zapominaj też, że tabele nie wyświetlają się dobrze w przeglądarkach mobilnych. Jasne, iPhone ma przeglądarkę typu kick-ass, ale nie każdy ma iPhone'a. Renderowanie tabel może być orzeszkami ziemnymi w nowoczesnych przeglądarkach, ale jest to arbuz dla przeglądarek mobilnych.

Osobiście odkryłem, że wiele osób używa zbyt wielu <div>tagów, ale z umiarem może być wyjątkowo czyste i łatwe do odczytania. Wspominasz, że ludziom trudniej jest czytać CSS niż tabele; w kategoriach „kodu” to może być prawda; ale pod względem czytania treści (widok> źródło) jest o wiele łatwiej zrozumieć strukturę za pomocą arkuszy stylów niż tabel.

Wygląda na to, że jesteś przyzwyczajony do stołów i to wszystko. 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 właściwej semantyki HTML jest znacznie czystszy, a zatem łatwiejszy do odczytania. Dlaczego ktoś, kto nie rozumie CSS, powinien go przeczytać? A jeśli ktoś uważa się za programistę stron internetowych, konieczne jest dobre zrozumienie CSS.

Korzyści z SEO wynikają z możliwości umieszczania najważniejszych treści na górze strony i lepszego stosunku treści do znaczników.

http://www.hotdesign.com/seybold/

• 508 Zgodność - zdolność czytnika ekranu do zrozumienia znaczenia znaczników.
• Oczekiwanie na renderowanie - tabele nie renderują się w przeglądarce, dopóki nie dojdzie do końca </table>elementu.

Cały pomysł wokół znaczników semantycznych polega na oddzieleniu znaczników i prezentacji, które obejmują układ.

Div nie zastępują tabel, mają swój własny użytek 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ł podzielić zawartość na komórki, aby uzyskać pożądany układ, ale nie będziesz musiał dotykać znaczników, aby uzyskać prezentację podczas korzystania ze znaczników semantycznych. Jest to naprawdę ważne, gdy generowane są znaczniki, a nie strony statyczne.

Programiści muszą przestać udostępniać znaczniki implikujące układ, aby ci z nas, którzy mają umiejętności prezentowania treści, mogli zająć się naszymi zadaniami, a programiści nie muszą wracać do kodu, aby wprowadzać zmiany, gdy konieczna jest zmiana prezentacji.

Tak naprawdę nie chodzi o to, czy „div są lepsze niż tabele do układu”. Ktoś, kto rozumie CSS, może powielić dowolny projekt za pomocą „tabel układu” całkiem prosto. Prawdziwą wygraną jest użycie elementów HTML do tego, do czego służą. Powodem, dla którego nie korzystasz z tabel dla danych niepostosowanych do tablic, jest ten sam powód, dla którego nie przechowujesz liczb całkowitych jako ciągów znaków - technologia działa o wiele łatwiej, gdy używasz jej do celu, dla którego jest przeznaczona. Jeśli kiedykolwiek konieczne było użycie tabel do układu (z powodu niedociągnięć przeglądarki na początku lat 90.), z pewnością nie jest to teraz.

Narzędzia korzystające z układów tabel mogą stać się wyjątkowo ciężkie z powodu ilości kodu wymaganego do utworzenia układu. SAP Netweaver Portal domyślnie używa TABELI do układania swoich stron.

Produkcyjny portal SAP na moim obecnym koncercie ma stronę główną, której HTML waży ponad 60 KB i ma głębokość siedmiu tabel, trzy razy na stronie. Dodaj Javascript, niewłaściwe użycie 16 ramek iframe z podobnymi problemami z tabelami, nadmiernie duży CSS itp., A strona waży ponad 5 MB.

Warto poświęcić czas na zmniejszenie wagi strony, abyś mógł wykorzystać swoje pasmo do angażowania użytkowników w działania.

Warto wymyślić CSS i div, aby środkowa kolumna treści ładowała się i renderowała przed paskiem bocznym w układzie strony. Ale jeśli masz problem z użyciem pływających elementów div do pionowego wyrównania logo z tekstem sponsora, po prostu skorzystaj ze stołu i idź dalej z życiem. Religia ogrodowa Zen po prostu nie daje wielkiego zysku.

Ideą oddzielenia treści od prezentacji jest podział aplikacji na partycje, aby różne rodzaje pracy wpływały na różne bloki kodu. W rzeczywistości chodzi o zarządzanie zmianami. Jednak standardy kodowania mogą jedynie badać obecny stan kodu w sposób powierzchowny.

Dziennik zmian aplikacji zależnej od standardów kodowania w celu „oddzielenia treści od prezentacji” pokaże wzór równoległych zmian w silosach pionowych. Jeśli zmianie „treści” zawsze towarzyszy zmiana „prezentacji”, jak skuteczne jest dzielenie na partycje?

Jeśli naprawdę chcesz produktywnie podzielić swój kod na partycje, użyj Subversion i przejrzyj swoje dzienniki zmian. Następnie użyj najprostszych technik kodowania - div, tabele, JavaScript, obejmuje, funkcje, obiekty, kontynuacje, cokolwiek - aby ustrukturyzować aplikację, aby zmiany pasowały w prosty i wygodny sposób.

Ponieważ utrzymywanie witryny korzystającej z tabel jest PIEKŁO, a kodowanie zajmuje dużo czasu. Jeśli boisz się pływających div, idź na nich. Nie są trudne do zrozumienia i są około 100 razy bardziej wydajne i milion razy mniej boli w dupie (chyba że ich nie rozumiesz - ale hej, witaj w świecie komputerów).

Każdy, kto zastanawia się nad układem ze stołem, lepiej nie oczekuje, że go utrzymam. Jest to najbardziej zwrotny sposób renderowania strony internetowej. Dzięki Bogu mamy teraz znacznie lepszą alternatywę. NIGDY nie wrócę.

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

Tabele nie są na ogół łatwiejsze ani łatwiejsze w utrzymaniu niż CSS. Istnieje jednak kilka specyficznych problemów z układem, w których tabele są rzeczywiście najprostszym i najbardziej elastycznym rozwiązaniem.

CSS jest wyraźnie preferowany w przypadkach, gdy znaczniki prezentacji i CSS obsługują ten sam projekt, 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 niż font-tagi, ale w znacznie czystszy sposób.

Problem z tabelami polega jednak na tym, że model układu tabeli w CSS nie jest obsługiwany w przeglądarce Microsoft Internet Explorer. Tabele i CSS są zatem nie równowartość w mocy. Brakująca część to siatkowe zachowanie tabel, w których krawędzie komórek są wyrównane zarówno w pionie, jak iw poziomie, podczas gdy komórki nadal się rozszerzają, aby zawierać ich zawartość. To zachowanie nie jest łatwe do osiągnięcia w czystym CSS bez twardego kodowania niektórych wymiarów, co czyni projekt sztywnym i kruchym (o ile musimy obsługiwać Internet Explorera - w innych przeglądarkach można to łatwo osiągnąć za pomocą display:table-cell).

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

Najważniejszym powodem nieużywania tabel jest dostępność. Wytyczne dotyczące dostępności treści internetowych http://www.w3.org/TR/WCAG10/ radzą ponownie, używając tabel do rozmieszczenia. Jeśli obawiasz się o dostępność (a w niektórych przypadkach możesz być prawnie zobowiązany), powinieneś używać CSS, nawet jeśli tabele są prostsze. Pamiętaj, że zawsze możesz stworzyć ten sam układ za pomocą CSS jak w przypadku tabel, może to wymagać więcej pracy.

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

.1. CSS i SEO:

a) CSS miał bardzo znaczący wpływ na SEO, umożliwiając pozycjonowanie treści na stronie, gdziekolwiek chcesz. Kilka lat temu wyszukiwarki kładły duży nacisk na czynniki „na stronie”. Coś na górze strony uznano za bardziej odpowiednie dla strony niż coś na dole. „Góra strony” dla pająka oznaczało „na początku kodu”. Za pomocą CSS możesz uporządkować treści bogate w słowa kluczowe na początku kodu i nadal umieszczać je w dowolnym miejscu na stronie. Jest to nadal dość istotne, ale czynniki na stronie są coraz mniej ważne dla rankingu strony.

b) Po przeniesieniu układu do CSS strona HTML jest jaśniejsza i dlatego ładuje się szybciej dla pająka wyszukiwarki. (pająki nie przejmują się pobieraniem zewnętrznych plików css). Szybkie ładowanie stron jest ważnym czynnikiem uwzględniającym ranking wielu 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 programowego 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 samodzielny i dobrze integruje się z dowolnym szablonem. Zrobić to samo z CSS jest znacznie trudniejsze i może w ogóle nie przynieść korzyści: trudno edytować arkusz stylów CSS podczas lotu, a dodanie wbudowanego stylu nie różni się od używania tabeli (treść nie jest oddzielona od układu).

Ponadto, gdy tabela jest generowana, zawartość (w zmiennych) jest już oddzielona od układu (w kodzie), co ułatwia modyfikację.

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

Oczywiście, jeśli wyniki muszą zostać przetworzone za pomocą JavaScript, div są warte kłopotu.

.3 Szybkie testowanie konwersji

Kiedy zastanawiasz się, co działa dla określonej grupy odbiorców, przydatna jest 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ładów są zwykle zbędne, ponieważ „wszyscy wiedzą, że div i CSS” są właściwą drogą.

Jednak faktem jest, że tworzenie tabel jest szybsze, łatwiejsze do zrozumienia i bardziej niezawodne niż większość układów CSS. (Tak, CSS może być równie niezawodny, ale szybki przegląd sieci w różnych przeglądarkach i rozdzielczościach ekranu pokazuje, że nie jest to często przypadek)

Stoły mają wiele wad, w tym konserwację, brak elastyczności ... ale nie wlewajmy dziecka z kąpielą. Istnieje wiele profesjonalnych zastosowań rozwiązania, które jest zarówno szybkie, jak 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ę słabą obsługą CSS

Ja, na przykład, mam już dość szarpniętej kolanem reakcji „O nie! Tabele do układu!”

Jeśli chodzi o „tłum nie był przeznaczony do tego celu i dlatego nie należy go używać w ten sposób”, czy to nie hipokryzja? Co sądzisz o wszystkich sztuczkach CSS, których musisz użyć, aby ta cholerna rzecz działała w większości przeglądarek? Czy były przeznaczone do tego celu?