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]

@ens0re - czy chcesz przez to powiedzieć, że <table> nie jest znacznikiem semantycznie zgodnym np. z XHTMLem. Diva czy spana możesz użyć do czegokolwiek. Jak nie masz wyspecjalizowanego znacznika to uzywasz takiego substytutu, a to czy zbudujesz stronę w oparciu o tabele czy o nic nie mowiace tagi jest kwestia przyjetej konwencji lub jak w tym wypadku mody. Znajdz mi zapis na stronach W3C, ze uzywanie tabel w celu budowy struktury strony jest nie zgodne ze standardami, a osobiście poproszę moderatora o zamknięcie tego tematu.

Zgadzam się z mike-mechem że design strony nigdy nie jest tabelą, ale struktura większości witryn tak.

[mike]

(...) Znajdz mi zapis na stronach W3C, ze uzywanie tabel w celu budowy struktury strony jest nie zgodne ze standardami, (...)

To nie o to chodzi.
Chodzi o to że nie jest zalecane stosowanie tagów wbret temu do czego zostały stworzone.
Jeśli by stosować tagi jak chcieć to czemu nie zaczniemy budowac stron na znaczniku <dd>?
Odpowiedni CSS i wszstko się uda.

Zgadzam się z mike-mechem że design strony nigdy nie jest tabelą, ale struktura większości witryn tak.

Nie zgodzę się z tym.
A dokładnie nie musiałby być tabelą gdyby developerzy nie zamnknęli tego designu w klatce.
Design składa się z bloków, czy to niesymetrycznych, większych, mniejszych, leżących obok siebie czy nakładających się na siebie ... ale zawsze z bloków.
I dlatego najwłaściwszym i jednocześniej najprostszym sposobem jest zastosowanie ... bloku, do budowy tej struktury.

[bigZbig]

Jeśli by stosować tagi jak chcieć to czemu nie zaczniemy budowac stron na znaczniku <dd>?

Z takich samych powodów z jakich menu buduje się przy pomocy listy. Jeśli chciałbym uzyskać efekt zbliżony do listy definiowanej to nie wykluczam, że sięgnąłbym po <dl>.

Design składa się z bloków, czy to niesymetrycznych, większych, mniejszych, leżących obok siebie czy nakładających się na siebie ... ale zawsze z bloków.
I dlatego najwłaściwszym i jednocześniej najprostszym sposobem jest zastosowanie ... bloku, do budowy tej struktury.

Może i najwłaściwszym. Gdyby w każdej przeglądarce działały poniższe style ...

Kod

.table    { display: table }
.tr       { display: table-row }
.thead    { display: table-header-group }
.tbody    { display: table-row-group }
.tfoot    { display: table-footer-group }
.col      { display: table-column }
.colgroup { display: table-column-group }
.td, .th   { display: table-cell }
.caption  { display: table-caption }

to bym się też zgodził, że najprostszym.

-- edit --

@dr_bonzo - a propos synetyzatora. Jak piszesz kod tabelki to tez umieszczasz poszczegolne wiersze i kolumny w okreslonej kolejnosci i powiedzilabym ze jest to latwiejsze do odczytania dla syntetyzatoda niz bloki, ktorych kolejnosc pozamieniana jest za pomoca pozycjonowania absolutnego. No zgodze sie z toba jedynie w kontekscie specjalnie przygotowywanych pod tym katem arkuszy styli, ale czy domyslnego formatowania tabeli nie mozna w ten sposob rowniez zmienic?

Ten post edytował bigZbig 21.06.2006, 13:13:23

[mike]

Może i najwłaściwszym. Gdyby w każdej przeglądarce działały poniższe style ...

Kod

.table    { display: table }
.tr       { display: table-row }
.thead    { display: table-header-group }
.tbody    { display: table-row-group }
.tfoot    { display: table-footer-group }
.col      { display: table-column }
.colgroup { display: table-column-group }
.td, .th   { display: table-cell }
.caption  { display: table-caption }

to bym się też zgodził, że najprostszym.

Przecież to jest niepotrzebne.
W życiu nie stosowałem tych styli bo po co? Mozna stosowac same bloki bez robienia z nich fragmentów tabeli.

No dobra, ale znów spadliśmy w torię i dyskuję że "moje kung-fu jest lepsze niż Twoje kung-fu"

Zabierzmy się za praktykę.
Ułuż taki design, jak wspomniany przeze mnie na tabelach i po prostu porównamy jest ksztalt, zawartość, skalowalność, przejrzystość.

Moje bez problemu działa na IE, FF (M$, Linux), Opera (M$, Linux), Konqueror. Nie widze problemu.

Chcesz definitywnie rowiązać dyskuję poprzyj ją przykładami, ja to cały czas robię.


---update---
Własnie instaluje Lynx'a.