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.

[DeyV]

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.

Zdecydowanie się nie zgadzam.
Praktycznie nie używam position:absolute w designach, co wcale nie sprawia, że nie mogę rozmieścić bloków po różnych stronach ekranu.
Prawdę mówiąc - nie wiem, do czego zostal wymyślony znacznik float, ale w układaniu bloków sprawdza się całkiem nieźle. Tak samo, jak wykorzystanie margin w celu określenie, że coś ma być np. po prawej, lub w pewnym odstępie od czegoś innego. Zresztą - margin: auto, w celu wyśrodkowania pewnych bloków też nieźle się sprawdza.
Pozwala to na bardzo wygodne rozmieszczenie dynamicznych bloków, bez sztywnego określenia, gdzie każdy z nich ma się zaczynać i kończyć.

[bigZbig]

Praktycznie nie używam position:absolute w designach, co wcale nie sprawia, że nie mogę rozmieścić bloków po różnych stronach ekranu.

OK, ale czy chcesz przez to powiedziec, ze mozesz bez zmiany struktury dowolnie zamieniac je miejscami uczynić z marginesu nagłówek, a z nagłówka stopkę? Nie twierdzę, że tabele dają większą możliwość manipulacji bo tak nie jest. Nie pisz mi jednak, że wszystko jest tak mobilne i elastyczne.

Prawdę mówiąc - nie wiem, do czego zostal wymyślony znacznik float, ale w układaniu bloków sprawdza się całkiem nieźle.

No i czego to dowodzi? Jedynie tego, że młotka możemy użyć zamiast tłuczka do mięsa. Więc argument, że table nie zostało stworzone do konstruowania struktury strony jest słaby.

Element będzie oblewany z lewej lub prawej strony, nie jest nigdzie napisane że tylko przez tekst, może to być inny element tego samego typu (dwa divy)

A czy ja tak napisałem? Twierdze jedynie ze ten kto wymyslil oblewanie nie przewidzial ze w elemencie oblewajacym moze byc kolejny element oblewany i wiążące się z tym problemy. Może to przeoczenie, ale jednak. revyag akurat Ty powinienes wiedziec co mam na mysli bo pomagales mi rozwiazywac problem - ograniczony clear

A co do tego tematu, to wydaje mi się że chcesz się komuś wyżalić ;-)

A mnie się wydaje, że czasami lepiej nic nie pisac bo wtedy nikt się nie dowie, że nie masz w sprawie nic mądrego do powiedzenia. A tak od razu wiadomo.

@nasto - zgadam się z Tobą dlatego pokusze się o małe podsumowanie.

Panowie przekonaliscie mnie do tego ze pomysl konstruowania stron w oparciu o tabele nie jest najszczęśliwszy. Z drugiej jednak strony używanie pływania równierz ma swoje wady. Pytanie moje zatem brzmi czy pomijając pozycjonowanie i pływanie są jeszcze jakieś inne tworcze sposoby rozmieszczania blokow na stronie lub przynajmniej czy są jakies widoki na udoskonalenie tej czynnosci?