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.

[bigZbig]

A co do div vs table, mam takie samo zdanie jak osoby wyżej wymienione - trzeba używać narzędzi do tego, do czego zostały zaprojektowane - młotkiem NIE odkręcać śrubki i śrubokrętem NIE wbijać gwoździ...

No a czy float zostalo zaprojektowane do budowy szkieletu strony? Do ustalania pozycji danego bloku na stronie zostało wymyslona dyrektywa position, ale sami wiecie jaka jest uzytecznosc pozycjonowania kiedy nie wiadomo jak duługi bedzie tekst w bloku, jak szeroki bedzie blok bo to zalezy od rozdzielczosci ekranu i wielkosci okna przegladarki?

A zalet jest naprawdę sporo, i nie raz były już wymieniane.
Dla mnie jedną z ważniejszych jest kolejność ładowania się bloków treści. Bardzo podoba mi się, gdy najpierw ładuje się tekst podstawowy, a potem dodatkowe bloki, menusy itp.
A jest to możliwe tylko dzięki temu, że niezależnie od tego, gdzie ten tekst ma zostać wyświetlony, w html'u znajduje się na początku. Ma to bardzo duży wpływ na wygodę korzystania ze strony.

Wybacz, ale to o czym Tu napisales jest możliwe do realizacji tylko przy uzyciu pozycjonowania absolutnego, a taki rodzaj rozmieszczania blokow ma niestety na tyle duzo wad, ze w wiekszosci projektowj jest po prostu nieuzyteczne.

bigZbig wspomniał tu jednak o tym, że ponoć zalecane jest odejście od wszystkich zdefiniowanych tagów.

Nie pisalem, ze jest to zalecane tylko, ze zaczynam dostrzegac taka tendencje wsrod webmasterow. Pisalem natomiast, ze w przyszlosci zamierza sie odejsc od XHTMLa na rzecz XMLa w ktorym bedzie mozna nadawac znacznikom dowolne nazwy i przypisywać im dowolne style uniezależniając w ten sposób warstwe tresci od warstwy prezentacji.

@athabus - jesli program werbalizujacy tresc nie potrafi czytac tabelek - w czasam, w ktorych wiekszosc stron jest w oparciu o nie skonstruowana to znaczy ze to jest kiepski program, a argument, że sam fakt umieszczenia tekstu w bloku niweluje roznice pomiedzy wizualnym odbiorem tresci a słuchowym jest absurdalny

Mike'owi o to chodzi, że masz MODEM TPSA i wchodzisz na strone i ładuje Ci się Bóg wie ile. W tabelkach - czekasz aż Ci się CAŁA załaduje, a w divach - kolejno każdy blok się ładuje. Tak to zrozumiałem

Tego argumentu nie obale. Niestety to prawda.

Pozatym wiem ze na divach zrobie latwiej trudne rzeczy, badz tez takie ktorych wogole sie nie zrobi na tabelkach

@hwao - wiadomo, ze pewnych rzeczy nie da sie zrobic przy pomocy <table> np. modelu kuli ziemskiej w 3D, ale tez nie do tego zamierzam go używać. Co masz na myśli pisząc, że łatwiej zrobisz trudne rzeczy?

[hwao]

@hwao - wiadomo, ze pewnych rzeczy nie da sie zrobic przy pomocy <table> np. modelu kuli ziemskiej w 3D, ale tez nie do tego zamierzam go używać. Co masz na myśli pisząc, że łatwiej zrobisz trudne rzeczy?

http://www.csszengarden.com/
http://www.mezzoblue.com/zengarden/alldesigns/
Zrob tak z tabelkami (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)