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.

[Kuziu]

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>.

Unikamy <table> do tworzenia struktur NIE tabelarycznych raczej ? :roll2:


I dlaczego menu nie jest listą ?

[sf]

Dla mnie budowanie na divach jest tak oczywista jak programowanie obiektowe... już bym nie mógł wrócić do struktralnego, tak samo nie wyobrażam sobie bym się cofał w rozwoju i wracał do tabelek. Jak widze kod oparty na tabelkach i musze coś poprawiać to klne jak nie wiem co na tego kto to pisał

To, że przeciętny użytkownik nie doceni to heh ;] Nawet mój szef nie doceni mojego kodu php i to znaczy, że mam pisać niestarannie? Pisze tak bo mnie to fascynuje, bo to lubie, a nie to, że ktoś ma to podziwiać - zresztą wybranemu gronu i tak się pochwale, a jak nie załapią to wytłumacze swoje idee

[bigZbig]

I dlaczego menu nie jest listą ?

Z takiego samego powodu z jakiego trujkolumnowy podział strony nie jest tabelką.

[mike]

Przenoszę na Hydepark. Jak zjem śniadanie to odpiszę

Design, strony nie jest tabelą. NIDGY!

Najważniejsze argumenty stosowania czystego kodu bagatelizujesz bo ich nie rozumiesz.
Wczoraj pomagałem ~Sethowi: http://michalmech.pl/projects/seth/
Zerknij w źródło i napisz to na tabelach. A potem oceń która wersja jest śmietnikiem.

[bigZbig]

@mike_mech - zerknalem w źródło strony, dodałem do tego źródło cssa - wyszedł dość pokaźny plik. Układ strony jest faktycznie przejrzysty i nie ma siętu nad czym zastanawiac. Czytanie cssa wymaga już skupienia. Poza tym to jest projekt dosc surowy. Z czasem tego kodu przybedzie. Być może będziesz chciał zastosować opływanie wewnątrz bloku który już coś opływa. Potem bedziesz chciał to wewnetrzne opływanie przerwać i się okaże, że wyszedłeś nie tylko z opływania elementu zagnieżdzonego, ale ze zakłuciłeś całą strukturę. Zresztą już na tym etapie widać ze jestes zmuszony do pisania osobnego kodu dla poszczególnych przeglądarek.

To co na początku wydaje Ci się takie proste ładne i przejrzyste z czasem straci swoje walory na rzecz topornego układu tabel. Być może kod strony w jakiś sposób zachowa prostote, ale arkusz styli nie. Już teraz jest trudniejszy w odbiorze niż kod strony. Nie dostrzegasz klopotow, ktore Cie czekaja, a moze dostrzegasz tylko nauczyles sie je zwalczac, ale czy zastanowiles sie nad tym, ze wielu problemow zwyczajnie moglbys uniknac?

Pewnie już nawet przestales sie nad tym zastanawiac, jak sf, ktory nawet nie analizuje zasadnosci uzycia tabel tylko zwyczajnie siada i przerabia na divy i sie wscieka - kazdy by sie wsciekal gdyby musial robic nipotrzebna robote.

[mike]

Nawet stosując tabelki trzeba pisać dla bardzIEwia oddzielnie.
A poza tym kod dedykowany dla niego do raptem 10 linijek.

Kolejna sprawa, narzekasz na wielkość CSS'a. tylko zwróc uwagę, ze taki CSS jest przesyłany do użytkownika tylko raz, podczas pierwszego żądania. Potem juz użytkownik zasysa lekkiego HTML'a a to wydajność bardzo duża nie zasługująca na bagatelizowanie.

Mówisz że to tylko zarys.
Masz razję, i zobacz jak na zaryz przystało jest dość mały.

A teraz pokaż dokładnie to samo na tabelkach. Twój zarys będzie tak zaśmiecony jak mój wfekt końcowy.

Więc argument, ze i tak coś dojdzie jest totalnie z kosmou. Co z tego, że coś dojdzie? To oznacza że mam od razu partaczyć?
To że może mnie samochód przejechać to znaczy że mam siedziec w domu?

To co na początku wydaje Ci się takie proste ładne i przejrzyste z czasem straci swoje walory na rzecz topornego układu tabel. Być może kod strony w jakiś sposób zachowa prostote, ale arkusz styli nie. Już teraz jest trudniejszy w odbiorze niż kod strony. Nie dostrzegasz klopotow, ktore Cie czekaja, a moze dostrzegasz tylko nauczyles sie je zwalczac, ale czy zastanowiles sie nad tym, ze wielu problemow zwyczajnie moglbys uniknac?

Bardzo krótkowzrocznie myślisz.
Napisz ten design na tabelach a potem go zmodyfikuj, dodaj kolejnego sidebara. Przerób na %. Zwiększ o 20 px.
Na tabelkach praca na gotowym kodzie to kara od Boga.
A co do problemów, pisząc XHTML do tej pory natrafiłem może na 3 problemy, których nie rozwiązałem w ciągu 10 min.

Pewnie już nawet przestales sie nad tym zastanawiac, jak sf, ktory nawet nie analizuje zasadnosci uzycia tabel tylko zwyczajnie siada i przerabia na divy i sie wscieka - kazdy by sie wsciekal gdyby musial robic nipotrzebna robote.

To jest standardowe podejście kodoś kto nie potrafi.
Nie znam OOP więc jest do niczego.
Nie opanowałem CSS więc bezzasadne jest jego stosowanie.
Nie mam prawa jazdy, więc samochody sa glupie.

[revyag]

http://osiolki.net/tabelki/index.html

[bigZbig]

@revyag - znam ten artykul bardzo dobrze.

To jest standardowe podejście kodoś kto nie potrafi.
Nie znam OOP więc jest do niczego.
Nie opanowałem CSS więc bezzasadne jest jego stosowanie.
Nie mam prawa jazdy, więc samochody sa glupie.

@mike_mech - znam OOP więc go stosuję, mam prawojazdy i chętnie prowadzę samochód, opanowalem też CSSa więc też go stosuję, co więcej od dawna już nie tworzę stron na tablekach, ale właśnie dlatego, że nauczyłem się to robić na divach i nabrałem troszkę doświadczenia w rozbudowie tak skonstruowanych struktur zacząłem się ponownie nad tym zastanawiać.

Z ideowego punktu widzenia ja się z Tobą mike-mech całkowicie zgadzam, powiem więcej jestem za tym aby faktycznie kod strony nie determinował jej wyglądu, a to możliwe jest do osiągnięcia np. przy połączeniu takich technologii jak XML, XSLT i XSL, ale na dzień dzisiejszy to wciąż pozostaje jedynie w sferze marzeń. Standardy obsługiwane obecnie przez przynajmniej najpopularniejsze przeglądarki sprawia, że praca designera w chwili obecnej nie jest bynajmniej łatwa, a budowanie tabelkowych ukladów bez tabelek jeszcze dodatkowo daną pracę komplikuje, a chodzi przecież o to aby sobie pracę ułatwiać.

Tabelki nie są jedynym deprecjonowanym sposobem projektowania stron wrzuconym do wora archaizmów. Podobnie jest z ramkami pływającymi. Fakt, że te zostały zastąpione przez Ajaxa i choć ta technologia zachowała podstawowe wady iframów to dała też dodatkowe możliwości, które jeśli są potrzebne uzasadniają użycie Ajaxa zamiast ramek pływających.

Osobiście uważam, że używanie float do budowy trójkolumnowego układu zamiast tabelek nie jest funkcjonalnie uzasadnione, a wręcz przeciwnie stwarza jedynie niepotrzebne problemy. Uzycie pływania w takim celu jest moim zdaniem naduzyciem - przerostem formy nad trescią.

Co do wielkości kodu. Ile kodu więcej generują tabele od divów? Zakładam że formatowanie tabeli jest przeniesione do cssa, nie stosujesz <col> i <tbody>. Dla trzech kolumn są to trzy tagi <tr> plus oczywiście tagi zamykające. Być może dla Ciebie mike-mech jest to wielka oszczędność. Dla mnie nie.

[ens0re]

I podsumowując to wszystko, nie stosuje sie tabelek do tworzenia układów stron, bo to nie jest przeznaczenie tabelek. Oczywiście można zrobić na tabelkach, tak samo jak i na znaczniku <b> ( http://delta.lebkowski.info/delta/99). Chodzi o semantyke. I mike_mech powiedział już dużo dobrego i poprostu nie ma sie co rozczulać nad tabelkami i rozkminiać, tylko wyeliminować je na zawsze(w sensie tworzenia układów stron). A ludzie nie tworzą stron opartych na standardach, bo albo sa początkujacy i nie wiedza, albo poprostu mają klapki na oczach i nie chca nabyć nowej, lepszej wiedzy. Swoja droga, wszyscy trąbią o stronach na DIVach. A tu nie chodzi o tworzeniu stron na DIVach, tylko na semantycznych znacznikach, dostepnych dla wsszystkich uzytkownikow i przegladarek. <div /> to jeden ze znaczników do budowania strony. Nie 'strony na divach', lecz strony zgodne ze standardami sieciowymi.

[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.

[ens0re]

czy chcesz przez to powiedzieć, że <table> nie jest znacznikiem semantycznie zgodnym np. z XHTMLem.

Jest ale nie do tworzenia układu stron www.

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.

O nic nie mowiące tagi? <div />, <p>, <span />, <ul /> itd nic nie mowią? I to nie kwestia przyjetej konwencji czy mody, tylko kwestia pisania semantycznych stron, uzywając tagów przeznaczonych do odpowiednich zadań. Menu nie robisz na tabeli lub divie tylko na <ul>.

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

Czegos takiego Ci nie znajdę, bo nie ma takiego zapisu, natomiast jest napisana funkcja jaką pełnią tabele. I nie ma tam napisane, że moze być tworzona dzieki niej strona, a jest tylko napisane, że słuzy do prezentacji danych tabelarycznych.

[ActivePlayer]

ja przypomne ze dane tabelaryczne, to dane prezentowane w wierszach i kolumnach, kolumny zazwyczaj posiadają nagłówki, podobnie moze się dziać jeśli chodzi o wiersze...

no, to popatrzmy na layouty...

[mike]

A jeszcze jedno dodam, uczę tworzenia stron od jakiegoś czasu kolege mojego mlodszego brata.
Łepek nie miał nigdy z tym styczności, więc mogłem mu przekazać w zasadzie wszystko, bez walki z jakimiś jego nawykami.

Zacząłem go uczyć odrazu XHTML/CSS w takim pojęciu jak ja znam i uważam a poprawny. Budowanie na Box Modelu wysyłanie dokumentu jako XML z nagłówkiem application/rss+xml i wiecie co: koleś teraz nieźle tnie designy i musze powiedzieć że jest calkiem niezły.

Od jakiegoś czasu pokazuje mu czego nauczyłby się w śmiesznych kursach, czyli pokazuję mu jak się kiedyś budowało designy. I widzę jak ciężko mu to idzie w ogóle ogarnąć, mało sobie rąk na klawiaturze nie połamie.

Więc to że jest łatwiej i prościej zostać przy tabelach i inne takie bzdury to nie wynika z trudności tylko z niechęci do nauki i kształcenia się tych wszystkich łebmajsterów co krzyczą najgłośniej tabelki! tabelki! tabelki! (tutaj bynajmniej nie man na myśli Ciebie ~bigZbig).

To tyle jeśli chodzi o argument trudności przestawiana się.

[ens0re]

Dokładnie, gdyby wszyscy od samego poczatku uczyli sie robić strony zgodne z XHTML + CSS, nie tabelki i w ogole tak, jak powinno sie robić strony, to teraz nie byłoby problemów 'tabelki vs. divy' i jeszcze wielu innych. A ludzie stosowali tabele, bo w programie 3 posunięcia kursorem i mamy gotowy layout <= prostsze tworzenie stron, bo po co pomyślec i zrobić poprawną strone. I to nie sztuką jest zrobienie tabelki i kilku kolumn i wierszy, ale sztuką jest zaprojektować strone tak, żeby była dostepna we wszystkich przeglądarkach, dla sprawnych i niepełnosprawnych, dla różnych urządzeń itp. A gdzie ludzie sie najczescie ucza tworzyć strony? W szkołach (pozdrowienia dla nauczycieli informatyki )

P.S. Kolejny topic typu 'tabelki vs.divy', eh

Ten post edytował ens0re 21.06.2006, 13:19:06

[dr_bonzo]

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

http://www.w3.org/2002/03/csslayout-howto

It has been advocated many times that tables shouldn't be use in HTML for layout purposes.

<table> ma znaczenie semantyczne -- sluzy do organizowania danych, jak dane statystyczne: zuzycie wegla w poszczegolntych krajach itp.

Zgodnosc ze standardami:
* (litera prawa) jak sie bedziesz trzymal zasad skladni to strona z layoutem zbudowanym na tabelkach zwaliduje sie poprawnie
* (duch prawa) <table> nie jest przeznaczone do budowy stron, osoby niepelnosprawne (np. niewidome) maja klopoty z dostepem do tresci na stronie gdy layout jest tabelkowy, bo jak taka strone ma odczytac syntezator mowy: najpierw kolumnami czy wierszami, najpierw logo, potem banery, menu, stopka , ... itd.

[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.

[bigZbig]

Przykład problemu z jakim się spotkałem przy projektowaniu w sposob przez Ciebie preferowany.

Ograniczony clear

Wspomnę tylko, że przytoczony problem skłonił mnie do zastanowienia - czy lepiej użyć float na etapie konstruowania ukladu strony i później kombinować jak kon pod górkę czy też szkielet potraktować lepiej jak tabelkę a pływania użyć rzeczywiście tam gdzie to jest uzasadnione.