Dlaczego ludzie robią tabele z divami?

We współczesnym tworzeniu stron internetowych coraz częściej spotykam się z tym wzorcem. To wygląda tak:

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

A w CSS jest coś takiego:

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

^{* (Nazwa klasy ma jedynie charakter poglądowy; w rzeczywistości są to normalne nazwy klas odzwierciedlające to, o czym jest element)}

Nawet ostatnio próbowałem to zrobić sam, ponieważ ... no wiesz, wszyscy to robią.

Ale wciąż tego nie rozumiem. Dlaczego to robimy? Jeśli potrzebujesz stolika, po prostu zrób coś wielkiego <table>i gotowe. Tak, nawet jeśli chodzi o układ. Do tego służą tabele - układanie rzeczy w formie tabelarycznej.

Najlepszym wyjaśnieniem, jakie mam, jest to, że do tej pory wszyscy słyszeli mantrę „nie używaj tabel do układania”, więc postępują zgodnie z nią na ślepo. Ale nadal potrzebują tabeli do układu (ponieważ nic więcej nie ma możliwości rozszerzania tabeli), więc tworzą <div>(ponieważ to nie jest tabela!), A następnie dodają CSS, który czyni ją tabelą.

Dla całego świata wygląda mi to na stawianie arbitralnych niepotrzebnych przeszkód na twojej drodze, a następnie wykonywanie dodatkowej pracy, aby je ominąć.

Pierwotny argument przemawiający za odejściem od tabel dla układu był taki, że później trudno jest zmienić układ tabelaryczny. Ale modyfikacja układu „faux-table” jest równie trudna i z tych samych powodów. W rzeczywistości modyfikowanie układu jest zawsze trudne i prawie nigdy nie wystarczy po prostu zmienić CSS, jeśli chcesz zrobić coś poważniejszego niż drobne poprawki. Ci będzie potrzebne, aby zrozumieć i zmienić strukturę HTML do poważnych zmian projektowych. A tabele nie sprawiają, że praca jest trudniejsza lub łatwiejsza niż div.

W rzeczywistości, jedynym sposobem, widzę, że tabele mógłby zrobić układ trudny do modyfikowania, to jeśli ab wykorzystywali je i stworzył bezbożnego bałagan. Możesz to zrobić również za pomocą div.

Więc ... próbując zmienić to z rantu w spójne pytanie: czego mi brakuje? Jakie są rzeczywiste zalety używania „faux-table” w porównaniu z prawdziwym?

Informacje o duplikacie linku: To nie jest sugestia użycia innego tagu lub czegoś takiego. Jest to pytanie o użyciu <table>VS display:table.

Jest to powszechny wzorzec tworzenia responsywnych tabel. Dane tabelaryczne są trudne do wyświetlenia na telefonach komórkowych, ponieważ strona zostanie albo powiększona, aby czytać tekst, co oznacza, że ​​tabele wychodzą z boku strony, a użytkownik musi przewijać w tył i w przód, aby przeczytać tabelę, lub strona zostanie pomniejszona , co zwykle oznacza, że ​​tabela jest zbyt mała, aby można ją było odczytać.

Elastyczne tabele zmieniają układ na mniejszych ekranach - czasami niektóre kolumny są ukryte lub kolumny są połączone, np. Imię i adres e-mail mogą być oddzielne na dużych ekranach, ale zwinięte w jedną komórkę na małych ekranach, aby informacje były czytelne bez konieczności przewijania.

<div>s są używane do tworzenia tabel zamiast <table>znaczników z kilku powodów. Jeśli <table>używane są tagi, musisz nadpisać domyślne style i układ przeglądarki przed dodaniem własnego kodu, więc w tym przypadku <div>tagi oszczędzają na wielu płytkach CSS. Ponadto starsze wersje IE nie pozwalają na przesłonięcie domyślnych stylów tabel, więc użycie <div>s również usprawnia rozwój w różnych przeglądarkach.

W CSS-Tricks jest całkiem dobry przegląd responsywnych tabel .

Edycja: Powinienem zaznaczyć, że nie popieram tego wzorca - wpada w pułapkę divitis i nie jest semantyczny - ale właśnie dlatego znajdziesz tabele wykonane z divs.

Pytanie brzmi, czy dane są semantycznie tabelą (tj. Zestawem danych lub jednostkami informacji logicznie zorganizowanymi w dwóch wymiarach), czy po prostu używasz siatki do wizualnego układu, np. Dlatego, że chcesz rozwinąć pasek boczny lub coś w tym rodzaju.

Jeśli twoja informacja jest semantycznie tabelą, używasz <table>-tag. Jeśli chcesz siatkę do celów układu, użyj innych odpowiednich elementów HTML i użyj jej display:tablew arkuszu stylów.

Kiedy dane semantycznie są tabelą? Gdy dane są logicznie zorganizowane wzdłuż dwóch osi. Jeśli ma to sens w przypadku nagłówków wierszy lub kolumn, możesz mieć tabelę semantyczną. Przykładem czegoś, co nie jest semantycznie tabelą, jest prezentowanie tekstu w kolumnach jak w gazecie. To nie jest semantycznie tabela, ponieważ nadal czytalibyśmy ją liniowo i żadne znaczenie nie zostałoby utracone, gdyby prezentacja została usunięta.

OK, dlaczego nie użyć <table>do wszystkiego, a nie tylko do czegoś, co jest semantycznie tabelą? Wizualnie jest oczywiście taki sam (ponieważ element tabeli ma po prostu display:elementdomyślny arkusz stylów).

Różnica polega na tym, że informacje semantyczne mogą pomóc alternatywnym aplikacjom użytkowników. Na przykład czytnik ekranu może umożliwiać nawigację w tabeli w dwóch wymiarach i czytać nagłówki komórki dla obu osi, jeśli zapomnisz, gdzie jesteś. Byłoby to mylące, gdyby stół nie był semantycznie stołem, ale służył tylko do wizualnego układu.

<table>Kontra display:tabledyskusja jest tylko przypadkiem bardziej ogólnej zasady korzystania semantycznych znaczników. Zobacz na przykład: Dlaczego ktoś miałby zawracać sobie głowę oznaczaniem poprawnie i semantycznie? lub Dlaczego znaczniki semantyczne mają większą wagę dla wyszukiwarek?

W niektórych miejscach może być prawnie wymagane użycie znaczników semantycznych ze względu na dostępność, aw każdym razie nie ma powodu, aby celowo zmniejszać dostępność strony.

Nawet jeśli nie troszczysz się o niepełnosprawnych użytkowników, prezentacja niezależna od treści daje korzyści. Na przykład układ trzech kolumn można przedstawić w pojedynczych kolumnach na telefonie komórkowym za pomocą alternatywnego arkusza stylów.

Właściwie powiedziałbym, że użycie nazw klas takich jak „table” w twoim przykładzie pokazuje, jak ludzie nie rozumieją, co robią, kiedy próbują znaczników semantycznych. Dostają oceny za próbę wykazania, że treść nie jest danymi tabelarycznymi , ale tracą oceny za złe nazwy klas.

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

Wszystko, co zrobił ten programista, to replikacja oryginalnego <table>znacznika przy użyciu nazw klas CSS. Oznacza to, że gdy tylko ten układ nie jest tabelą, nazwy klas są sprzeczne.

To, co ten programista powinien zrobić, to zastanowić się, jakie informacje są w tabeli - czy jest to galeria miniatur? No więc:

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

Teraz mogę stworzyć adaptacyjny CSS:

@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%;
  }
}

Dlaczego div, a nie tabele

Tabela zawiera dane tabelaryczne - prezentacja tabeli jest nierozerwalnie związana ze strukturą tabeli. Dane tabelaryczne zawsze będą musiały mieć formę tabelaryczną, bez względu na to, gdzie umieścisz tę treść lub na jakim ekranie / urządzeniu chcesz ją wyświetlić.

Galeria miniaturek (lub wiele innych rzeczy, takich jak formularz rejestracyjny, menu itp.) Nie jest danymi tabelarycznymi. W niektórych układach projektowych może być prezentowany jak tabela, ale w innych przypadkach, takich jak wąskie ekrany telefonu, chcesz go używać przy użyciu bardziej tradycyjnych układów bloków. A może chcesz wyświetlać miniatury na pasku bocznym zamiast w głównym obszarze zawartości.

Twoim wyborem jest teraz wyświetlanie różnych znaczników dla zawartości szerokiego ekranu (tabele) i paska bocznego lub zawartości wąskiego ekranu (div) - co oznacza, że ​​skrypty po stronie serwera będą musiały wiedzieć, dokąd zmierza treść, jeśli budujesz to programowo - lub twój skrypt po stronie serwera wyświetla ten sam znacznik (ponieważ nie powinno to mieć znaczenia, gdzie to umieszczasz) i używasz różnych reguł CSS dla różnych sytuacji.

Masz więc wybór, zawsze wypisując tabele, a następnie nadpisując naturalne reguły wyświetlania tabel za pomocą bloku (który naprawdę powinien szlifować niektóre biegi w głowie każdego programisty), lub wybierając dobrze oznaczone divy, które pozwalają na bardziej elastyczne podejście do stylizacji.

A najlepszymi praktykami od kilku lat jest unikanie tabel, gdy nie trzeba przedstawiać danych tabelarycznych.

W dawnych czasach silnik renderowania tabeli „ pojawiał się ” wolniej, gdy używałeś wartości procentowych dla szerokości kolumn. Silnik w zasadzie musiał pobrać cały zestaw danych, zanim zaczął zastanawiać się, jak duże jest wszystko, aby narysować go na ekranie.

Silnik DIV był inny. Gdy przeglądarka napotka DIV, umieści go i zacznie wypełniać zawartość bezpośrednio. Oczywiście div może przeskakiwać, gdy dane są ładowane. Dlatego pojawiłem się w cytatach powyżej. Ramy czasowe ukończenia obu były takie same, jednak tabele nie były rysowane do końca, co oznaczało, że użytkownik nie był pewien, czy się ładuje, czy nie przez sekundę lub dwie.

Sytuacja pogorszyła się wraz z zagnieżdżeniem tabel.

Istniały wtedy (i nadal istnieją) sposoby na szybsze renderowanie FAR FAR. Zasadniczo, dając wskazówkę, że rozmiary kolumn się nie zmieniają, przeglądarka natychmiast zaczyna renderować dane tabelaryczne. Ostatecznie oznacza to, że tabele mogą faktycznie wyświetlać się w prawidłowej pozycji szybciej niż div, dzięki czemu wyglądają lepiej.

Ale to nie jest cała historia. Reszta jest taka, że ​​większość deweloperów po prostu nie zadaje sobie trudu, aby nauczyć się swojego rzemiosła wystarczająco dobrze, aby o tym wiedzieć. Zamiast tego wskakują na różne bandwagony i używają kodu, z którego mogą kopiować / wklejać. Nawet dzisiaj stwierdzam, że bardzo niewielu twórców stron internetowych zna różnicę między poszczególnymi typami dokumentów - i jest to główny powód, dla którego różne witryny mają różnego rodzaju obejścia obejmujące różne przeglądarki.

Daj więc +1 do zadania pytania.

Jeśli uda mi się tutaj uzyskać trochę „meta”, przychodzą mi na myśl dwa problemy:

Po pierwsze: ktoś proponuje regułę z jakiegoś dobrego powodu, a ludzie całkowicie nie rozumieją sensu, przestrzegając technicznej litery reguły, ignorując ducha. Znajdują sposób, aby osiągnąć wszystkie złe rzeczy, którym reguła próbowała zapobiec, a jednocześnie technicznie przestrzegać reguły w brzmieniu.

Po drugie: ktoś widzi problem i proponuje regułę, aby temu zapobiec. Inni widzą wartość tej reguły. Następnie nalegają na ślepe poświęcenie się tej zasadzie bez względu na pierwotny problem, który miał rozwiązać i / lub niezależnie od tego, jakie inne problemy stwarza. Przeprowadziłem wiele rozmów, w których ktoś mówi: „Musisz zrobić X, bo taka jest reguła”, a potem pytam: „Ale dlaczego powinniśmy robić X?”, A oni patrzą na mnie z zaskoczeniem i rozdrażnieniem i mówią: „Ale Właśnie ci powiedziałem! Bo to reguła! ” Odpowiadam: „Ale wydaje się, że powoduje więcej problemów niż rozwiązuje. Myślę, że lepiej byłoby zrobić Y.” A potem osoba mówi: „Nie, spójrz, pokażę ci. Widzisz, jest tutaj, w tej książce. X jest regułą”.

W tym przypadku mamy problem: Tag tabeli ma dwie rzeczy: po pierwsze, kontroluje układ dokumentu. Po drugie, przekazuje ideę, że zamknięte dane składają się z wierszy i kolumn liczb lub innych danych.

Tak wiele osób zaproponowało rozwiązanie: nie używaj znaczników tabeli do kontrolowania układu rzeczy, które nie są logicznie „tabelami”. Użyj CSS.

Ale z tym rozwiązaniem jest problem. Znacznik tabeli i jego podtagi wykonują wiele bardzo przydatnych funkcji układu, które nie są łatwe do osiągnięcia przy użyciu CSS, a gdy można je osiągnąć, kod niezbędny do tego jest często uciążliwy - trudny do odczytania i trudny do utrzymania. Dlaczego powinniśmy robić rzeczy w niezdarny, trudny sposób, skoro istnieje czysty, łatwy sposób?

Osobiście uważam, że lepiej byłoby po prostu zadeklarować: „Fakt, że coś znajduje się w znaczniku tabeli, niekoniecznie oznacza, że ​​reprezentuje on wiersze i kolumny liczb”. To nie byłby skandaliczny wyrok. Nigdy nie słyszałem, żeby ktoś powiedział, że znacznika „p” można używać tylko do rzeczy, które są tak naprawdę akapitami poprawnych gramatycznie, logicznie skonstruowanych angielskich zdań. Nigdy nie słyszałem, żeby ktoś powiedział, że źle jest używać znacznika „ul” do listy, która w rzeczywistości ma logiczną kolejność, tylko dlatego, że chciałeś punktorów, a nie numerów porządkowych. Itp.

Tutaj jest już mnóstwo świetnych odpowiedzi. Chciałem jednak dodać, że tableelementy mają ograniczenia renderowania, które nie istnieją dla divelementów. Spróbuj stworzyć tabelę, która będzie wirtualnie przewijać (jak: SlickGrid , DataTables i inne), a będziesz bardzo rozczarowany. To po prostu nie działa. Większość (wszystkich?) Nowoczesnych siatek JavaScript używa divs, ponieważ css pozwala na znacznie bardziej elastyczne renderowanie.

Istnieją również inne ograniczenia. Moją ogólną zasadą jest to, że jeśli mam zobaczyć całą tabelę na jednym ekranie i nie chcę żadnego niestandardowego renderowania, używam tableelementu, w przeciwnym razie korzystam z div, ponieważ mogę dużo kontrolować wyniki , o wiele łatwiej.

HTML i CSS rozwinęły się w pewnym stopniu elastyczności, co oznacza, że ​​nawet koncepcyjnie elementy blokujące, takie jak <div>(najstarsza i najbardziej ogólna forma HTML treści) nie muszą być wyświetlane jako bloki:

div { display: inline; }

Jak można zauważyć, <div>można go zmienić w celu naśladowania <table>i innych podróżników. W rzeczywistości większość tagów może. Biorąc pod uwagę ich specjalne role, wątpię można użytecznie przemapować tagi makro jak <html>, <head>, <body>i <script>, ale „wspólnych” tagów takich jak <div>, <p>, <b>, <em>, <span>, i <pre>? Do zgarnięcia. Ustaw bloki znaczników w linii, bloki w linii, przepływy wstępnie sformatowanych znaczników, pływające stacjonarne. Zaszalej, jeśli chcesz!

To możliwe . Być może zechcesz opowiedzieć o tym, w jaki sposób wszyscy powinniśmy używać „znaczników semantycznych”, bla, bla, bla , bla , bla bla bla , lub wierzyć w Pythonistas, że „Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób na to”. Jednak Tim Toady jest sprytnym i ciekawskim facetem. Mając wolną rękę, zbada je wszystkie. Obejmuje to wykorzystanie dostępnej elastyczności do dokonywania podstawień. Niektóre są mądre, inne zostaną udowodnione w inny sposób. Ale próba, błąd i doświadczenie to jedyny sposób, aby się tego dowiedzieć. Występują więc wystarczające warunki do zastąpienia.

Nie sądzę, aby przesadne było stwierdzenie, że podstawienie jest również konieczne. Jest to co najmniej niezwykle wygodne . Przez długi czas, HTML nie mają <menu>, <section>albo <aside>elementy. Jednak strony internetowe i aplikacje wszędzie mają menu, sekcje i paski boczne. W jaki sposób? Ponieważ elementy listy HTML ( <ul>, <ol>i <li>) można łatwo zmienić przeznaczenie, a niektóre zastosowania zostały ponownie sklasyfikowane jako kontenery i części menu. <div>mógłby stanąć na <article>, <section>, <aside>, <figure>, i <summary>. HTML5 nadrobił zaległości i dodał niestandardowe elementy dla niektórych wcześniej nieadresowanych przypadków użycia. Jest to świetna aktualizacja i korekta pozwalająca na dostosowanie do powszechnego użytku w świecie rzeczywistym.

Mimo to wciąż istnieje wiele popularnych idiomów, które nie mają niestandardowych tagów ani modeli semantycznych . Rzeczy takie jak strony, przypisy, cytaty, strumienie komentarzy, powiązane awatary, „polubienia”, podtytuły i napisy, których ja i wielu innych używam każdego dnia. Co mamy robić? Co możemy Zmień przeznaczenie elementów „bliskich, ale niedokładnych” za pomocą klas i identyfikatorów, aby stać w miejscu i wspierać naszą pracę przez następne pięć lub dziesięć, a nawet wiele lat, aż HTML6 lub HTML7 nadrobią zaległości. Teoretycznie HTML / CSS „tak, to X, ale oznaczymy to tagiem i będziemy pracować z nim jako Y”, jest to niezwykle wygodne. Niezbędne, naprawdę. Sprawia, że ​​zawartość sieci Web jest elastyczna i nie krucha.

Idąc dalej, „znacznik semantyczny” ma nieredukowalne ograniczenia . Dotyczy to każdego rodzaju rygorystycznej struktury, jaką można sobie wyobrazić dla treści.

Standardowe formaty nie mogą obejmować całego bogactwa ludzkich potrzeb, pragnień i różnorodności. Zawsze będą „za zakrętem” tego, co ludzie robią teraz . Jak są innowacyjne. Do licha, HTML5 wciąż pozostaje poza zakresem przypisów, podtytułów i innych innowacji drukarskich XVII wieku. Brakuje funkcji niezbędnych dla wielu pracowników informacji i twórców treści. Improwizujemy.

Jeszcze bardziej niezmienne jest to, że informacje nie podlegają jednemu zestawowi reguł. Jasne, zaczyna się od stołu. Ale może chcesz tylko podsumowanie - wypowiedz tytuł każdego wiersza jako listę. Może zajmuje zbyt dużo miejsca i chciałbyś, aby była to wbudowana lista zajmująca mało miejsca. Być może masz rekordy, których chcesz tylko tytuł, a następnie kliknięcie spowoduje wyświetlenie podstawowych informacji. Lub chcesz, aby elementy ze złożonej listy lub tabeli były grupowane i kategoryzowane. Och, teraz chcesz to przetransponować i skategoryzować w inny sposób. Lub wartości wykreślone jako wykres słupkowy. Są to czynności wykonywane codziennie w aplikacjach, arkuszach kalkulacyjnych i wizualizacji danych. Są nieodłączną częścią naszego krajobrazu informacyjnego i tego, co chcemy i musimy robić w Internecie. Ludzie stale reorganizują formę i prezentację naszych danych. To nie jest tylko jedna rzecz lub jeden format / układ, lub jedna koncepcja. Jest zamienny, z semantyką zależną od okoliczności i wyborów dokonywanych interaktywnie przez użytkowników. Tak, zaznacz tekst jako „wyróżniony” (<em>), ale to tylko konwencja. Pracowałem nad dokumentami z co najmniej kilkoma różnymi rodzajami „akcentów”. My potrzebujemy , aby móc dostosować i przemapować że dla różnych zastosowań, różne interpretacje. Jeden rodzaj podkreślenia HTML? Zaskakująco redukcjonistyczny. Ograniczanie Kruchy. To samo odnosi się do <table>, <p>itp

Wspaniale jest mieć tagi / elementy, które pomagają uporządkować myślenie całej społeczności o tym, co się dzieje. Pomaga to w ustalaniu konwencji i idiomów oraz sprawia, że ​​jesteśmy bardziej wydajni. Ale zdolność do zmiany map, przeprojektowania i zmiany przeznaczenia tych struktur? To nieodłączna część integralności sieci i jej sukcesu.

Przypadki użycia mają znaczenie. Istnieje duża różnica między układem / prezentacją na stronie treści a aplikacją. W treści semantyka ma ogromne znaczenie dla świadomości SEO i użyteczności. W takich przypadkach użycie tabel do prezentacji danych tabelarycznych jest ogólnie rzecz biorąc właściwe. Jak zauważyli inni, wyszukiwarki będą cię karać, a nawet możesz przestrzegać przepisów dotyczących użyteczności, jeśli ustawa wymaga od ciebie przestrzegania rządowych wytycznych dotyczących użyteczności.

W aplikacji internetowej programiści mogą zdecydować się na tworzenie całkowicie oddzielnych widoków dla celów SEO i użyteczności. Elastyczne projektowanie doprowadziło ludzi do tworzenia widoków, które mogą obsługiwać układy stacjonarne i mobilne, a div są lepsze niż tabele w tych przypadkach użycia.

Weźmy na przykład witryny e-commerce. Przeglądanie listy produktów w wynikach przeglądania lub wyszukiwania pokazuje, ogólnie rzecz biorąc, listę produktów w formacie tabelarycznym, ale widoki te mogą być generowane przy użyciu div (które zapewniają bardziej ogólne i elastyczne opcje układu i stylizacji) niż tabel. Amazon i eBay są dobrymi przykładami tego podejścia. Sprawdź wynik wyszukiwania w dowolnej witrynie, a zobaczysz głęboko zagnieżdżony zestaw div.