Programowanie webowe | 02. Float left vs. Display inline-block

Struktura oparta na tabelach?

Mirosław Zelent

Jak tworzymy strukturę witryny internetowej? Pozwólcie, że odpowiem na tak postawione pytanie parafrazując graficznie – na obrazku poniżej – piramidę potrzeb Abrahama Maslowa, zamieniając ją w piramidę sposobów tworzenia szkieletu sekcji body dokumentu HTML. Przedstawiam naturalną ewolucję metod rozmieszczania elementów na wirtualnym płótnie przeglądarki internetowej:

Podstawę piramidy stanowi powstrzymanie się od intuicji użycia tabeli do planowania rozmieszczenia elementów witryny. Jakkolwiek samo stosowanie tabel to zdecydowanie w web developerce relikt przeszłości, to jednak ludzie po dziś dzień wykazują naturalną chęć użycia wierszy i kolumn do planowania ciała dokumentu HTML i to raczej nigdy się nie zmieni – czytamy gazety, książki, ulotki – jesteśmy przyzwyczajeni do kolumnowego rozkładu tekstu i grafik.

Tabela wydaje się być idealna – przy jej pomocy łatwo zorganizować sobie szpalty tekstu i na tej podstawie rozplanować content artykułu. Często tak zresztą postępujemy w edytorach typu Word, Libre Office Writer, WordPad. Arkusze kalkulacyjne (Excel, Libre Office Calc) także zachowują strukturę wierszy i kolumn, podobnie jak bazy danych, faktury VAT, potwierdzenia przelewu czy nawet paragony.

Nie należy więc ganić siebie (albo innej osoby) za intuicję użycia tabeli do rozmieszczenia zawartości witryny – często taką bezpardonową, wręcz prześmiewczą wobec innych manierę, wykazują młodzi entuzjaści tworzenia stron internetowych (którzy nauczyli się już dlaczego to podejście akceptowalne nie jest). Zapominają oni wówczas, iż sami także taką chęć na początkowym etapie nauki wykazywali, albo może pamiętają o tym w głębi podświadomości, ale chcąc podkreślić jak wiele już wiedzą o tworzeniu witryn, namiętnie piętnują innych za choćby zwykłe zadanie pytania o możliwość wykorzystania tabel.

Dlaczego więc tabele nie nadają się do tworzenia struktury witryny? Poniżej zestawiłem siedem "grzechów głównych" stosowania w tym celu znacznika table:

1. Niepełne rozdzielenie zawartości witryny od opisu jej wyglądu (problemy ze stylizowaniem tabel w CSS).
2. Komórka w tabeli nie jest autonomicznym elementem takim jak blok (div albo nowy kontener w HTML5).
3. Tag <table> nie jest pomyślany jako znacznik strukturalny – ma służyć do tabelarycznego prezentowania informacji.
4. Stosowanie tabel skutkuje powstawaniem nadmiarowego kodu opisującego strukturę witryny.
5. Przeglądarka wolniej ładuje i renderuje zawartość strony, której szkielet zbudowano na tabeli.
6. Tabele nie są SEO friendly (ang. Search Engine Optimization – optymalizacja w wyszukiwarkach internetowych).
7. Szkielet tabelaryczny uniemożliwia zastosowanie responsywności (różnego układania bloków w zależności od aktualnego rozmiaru ekranu).

Samo posiadanie intuicji do stworzenia swoistej siatki wierszy i kolumn jest dobre i naturalne. Później zresztą, pracując już na stronach responsywnych, przekonasz się, iż takie myślenie tabelaryczne stało się także podstawą responsywnych frameworków, takich jak np. Bootstrap. W Bootstrapie posługujemy się siatką (tzw. gridem) divów (albo innych elementów blokowych znanych z HTML5) złożoną z maksymalnie dwunastu kolumn:

I oczywiście to nadal są struktury blokowe, a nie tabele, niemniej jednak to myślenie o stronie jako o siatce wierszy i kolumn, ewidentnie tam występuje. Dodatkowo, w Bootstrapie określamy także dostępne w witrynie, predefiniowane rozmiary ekranu:

W zależności od obecnego rozmiaru okna przeglądarki, witryna potrafi zatem odpowiednio dostosować swoją strukturę do zaistniałych okoliczności (z użyciem JavaScript i CSS). Trudno więc nazwać Bootstrapa dokładną realizacją tabelarycznej intuicji, niemniej jednak sama idea wierszowo-kolumnowej budowy szkieletu witryny, idea posiadania układu kartezjańskiego o dwunastu jednostkach, rzeczywiście w gridzie występuje.

Zatem fakt, iż posiadamy taką “tabelaryczną” intuicję i że w pewien sposób kusi nas użyć znacznika <table> przestaje nas dziwić – w końcu ekran przeglądarki to płaszczyzna, a położenie elementu na płaszczyźnie opisujemy zazwyczaj dwiema współrzędnymi.

Trzeba jednak poskromić tę pokusę ze względu na poważne, negatywne implikacje użycia <table> jako fundamentu witryny. A najlepiej przekuć tę pokusę w miłość do autonomicznych elementów blokowych, które rzeczywiście lepiej nadają się do frywolnego bazgrania po wirtualnym płótnie okna przeglądarki. Więcej o wadach tabel w drugim odcinku serii HTML.