Wracajmy do tabelek! Opcje

[bigZbig]

Siedziałeś, męczyłeś się starając się usilnie przebudować swoją stronę opartą o tabele zgodnie z najnowszymi trendami zalecającymi używanie do konstruowania struktury strony divów. I co? Przeciętny użytkownik nie doceni Twojej pracy bo się na tym nie zna, a witryna w najlepszym wypadku wygląda tak samo.

Ile razy słyszałeś, że strukturę strony nie powinno się konstruować w oparciu o tabelki:

• bo to nie jest tabelka,
• bo produkujesz nadmiarowy kod,
• bo to jest rozwiązanie nieelastyczne i trudne do przebudowy,
• bo tagi tabeli są preformatowane.

Ile razy słyszałeś te argumenty? Zapewne wiele - no i w końcu uwierzyłeś. Ja też uwierzyłem. Zatriumfowała stara Goebbelowskiej zasada, że często powtarzane kłamstwo w końcu staje się prawdą.

Zadajmy sobie pytanie, czy struktura strony faktycznie nie ma nic wspólnego z tabelką? Zapewne są takie strony, w odniesieniu do których powyższe zdanie jest prawdziwe, ale zdecydowana większość szkieletów stron jest mniej lub bardziej złożoną tabelą i choć nie widać granic poszczególnych komórek nie dajcie sobie wmówić, że tak nie jest. Utalentowany designer potrafi w swoim projekcie wyjść poza ramy tabeli sięgając w przypadku wybranych elementów do pozycjonowania tudzież innych technik umożliwiających uzyskanie efektu niemożliwego do osiągnięcia przy zastosowaniu tradycyjnych tabel, ale czy te przemyślne techniki powinny być używane do emulowania struktury tabelarycznej?

Ponoć wraz ze stosowaniem tabel zmniejsza się czytelność kodu i produkuje się nadmiarowe tagi. Pomijając to, że w przypadku stosowania divów część formatująca kodu zostaje przeniesiona do arkusza styli mógłbym się zgodzić z poglądem, że na wczesnym etapie projektu kod strony opartej o divy jest czytelniejszy. Proszę zwrócić szczególną uwagę na sformułowanie „na wczesnym etapie projektu”. Z czasem projekt zaczyna się komplikować, rozrastać – szkielet strony wypełniany jest treścią, która również często zorganizowana jest w jakąś hierarchię, jakiś układ. Divy się zagnieżdżają. Z czasem zaczynasz odkrywać potrzebę stosowania dodatkowych kontenerów i nim się spostrzeżesz Twój kod staje się śmietnikiem, który trzyma się kupy dzięki różnego rodzaju trikom, hakom i obejściom. A miało być tak przyjaźnie i elastycznie.

Przesadziłem. Nikt nie twierdzi – przynajmniej ja się z taką opinią nie spotkałem – że używanie divów do budowy układu tabelarycznego jest prostsze od bezpośredniego zastosowania tabel. Co do elastyczności i łatwości ewentualnej przebudowy struktury strony opartej o divy to ja się proponuję zastanowić indywidualnie każdemu, kto taki twór stworzył. Prosty przykład. Masz klasyczny trójkolumnowy podział strony z nagłówkiem na górze i stopką jak sama nazwa wskazuje na dole. Zrób tak aby tak skonstruowana tabela zajmowała określoną szerokość, i aby szerokość każdej z kolumn był z góry określony. Proste prawda? No to teraz przerób ten układ w ten sposób aby tabela dostosowywała się do wielkości okna przeglądarki poprzez poszerzenie środkowej kolumny. Jeśli przewidziałeś taki manewr to obeszło się bez ingerencji we wzajemne położenie divów. Ok. to teraz zamień kolumny miejscami ;). Czy robisz to przy pomocy tabel czy divów musisz przebudować strukturę strony. Możesz co prawda zastosować pozycjonowanie i w sposób dowolny przemieszczać elementy w oknie przeglądarki, ale tylko pod warunkiem ustalenia z góry ich szerokości i wysokości. W innym przypadku nie ma to większego sensu.

Podążając w stronę słusznie lansowanej idei by oddzielić treść strony od sposobu jej prezentowania konsorcjum W3C stworzyło XHTMLa, jako standard przejściowy pomiędzy HTMLem a czystym XMLem, w którym nie ma z góry zdefiniowanych tagów, a sposób ich formatowania zależy tylko i wyłącznie od definicji zawartych w arkuszach styli CSS czy XSL. Chcąc być jak najbardziej po drodze z wyżej wspomnianą ideą powinniśmy unikać predefiniowanych tagów, a więc na dobre wszystkiego oprócz divów i znaczników span (choć i te są predefiniowane – w końcu jedne są wyświetlane blokowo a drugie liniowo. Bądźmy konsekwentni – skoro unikamy <table> do konstruowania struktur tabelarycznych to powinniśmy także wystrzegać się <ul> do konstruowania list, a <p> do oznaczania paragrafów. Dlaczego łamiemy tekst przy pomocy znacznika <br> a wyróżniamy go tagiem <strong>. Miłośników divów chciałbym zapytać dlaczego do tworzenia horyzontalnego menu używają listy? Przecież menu nie jest listą.

Nie jestem zagorzałym przeciwnikiem techniki opływania czy pozycjonowania, ale uważam, że w chwili obecnej są one nadużywane. W końcu ideą opływania miało być otoczenie obrazka lub niewielkiego bloku tekstem, a nie konstruowanie układów tabelarycznych. Myślę, że nie do tego zostało również wymyślone pozycjonowanie. To prawda, że kreatywny programista, czy designer nie zawsze używa technologii zgodnie z ich pierwotnym przeznaczeniem, tylko znajduje dla niech zastosowanie tam gdzie nikt by się nie spodziewał, ale w tym wypadku opływanie i pozycjonowanie to nie łyżka stołowa, która nadaje się do kopania równie dobrze jak łopatka.