Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Wracajmy do tabelek!
Forum PHP.pl > Inne > Hydepark
Stron: 1, 2, 3, 4, 5
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
Cytat(bigZbig @ 21.06.2006, 09:25 ) *
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ł smile.gif

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? tongue.gif 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 tongue.gif
bigZbig
Cytat
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ę smile.gif

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?

Cytat(bigZbig @ 21.06.2006, 10:06 ) *
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.

Cytat(bigZbig @ 21.06.2006, 10:06 ) *
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.

Cytat
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
Cytat(bigZbig @ 21.06.2006, 13:37 ) *
(...) 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.

Cytat(bigZbig @ 21.06.2006, 13:37 ) *
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
Cytat
czy chcesz przez to powiedzieć, że <table> nie jest znacznikiem semantycznie zgodnym np. z XHTMLem.

Jest ale nie do tworzenia układu stron www.
Cytat
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>.
Cytat
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 tongue.gif (pozdrowienia dla nauczycieli informatyki tongue.gif)

P.S. Kolejny topic typu 'tabelki vs.divy', eh
dr_bonzo
Cytat
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
Cytat
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
Cytat(mike_mech @ 21.06.2006, 13:42 ) *
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>.
Cytat(mike_mech @ 21.06.2006, 13:42 ) *
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?
mike
Cytat(bigZbig @ 21.06.2006, 14:05 ) *
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.
athabus
No to i ja dorzuce swoje 3 grosze.

Nie będę nikogo na siłę przekonywał, że z oddzielenie struktury od prezentacji jest łatwiejsze - jak dla mnie to jest po prostu naturalne - tak samo jak dążenie do oddzielenia różncyh warstw w programowaniu - wydaje mi się, że po zrozumieniu ideii każdy do tego dąży.

Dla mnie jednak inny argument jest dość ważny - dostępność strony. Jeśli strona jest napisana w HTML + CSS, przy oddzieleniu struktury od prezentacji to jest ona dostępna dla każdego - np. łatwiej poruszać się w niej niewidomemu. Z tego samego powodu używam np. alt przy wstawianiu obrazków, czy rezygnuję z flasha. Internet jest/powinien być jak Ubuntu - dostępny dla każdego biggrin.gif
bigZbig
@athabus - ja sie z Tobą w zupełności zgadzam. Wczytaj się jeszcze raz dokładnie w to co napisałem.
athabus
@bigZbig - to nie było do Ciebie bezpośrednio - to taka ogólna moja refleksa i odpowiedź dlaczego lepiej z wytycznymi W3C niż bez nich.
mike
http://michalmech.pl/projects/seth/lynx.gif

~bigZbig wieczorem jak będę miach chwilkę i podoga da pomyśleć to zerkną na wątkek który podałeś wyżej.
Master Miko
bigZbig... Twój post jest cholernie długi tongue.gif

ja skomentuje to tak...

Uczyłem się od samego początku robić strony na tablekach, patrząc na "profesjonalne" desginy innych... potem gdy dowiedziałem się o divach zupełnie zmieniłem nastawienie...

Strona (szablon top i down) na tabelkach która kiedyś zajmowała mi 12kb + 5kb CSS, zajmowała teraz 5kb + 3kb CSS... jest różnica :/

Cytat
Ponoć wraz ze stosowaniem tabel zmniejsza się czytelność kodu i produkuje się nadmiarowe tagi

To jest zły argument. Każdy programista robi kod lepiej, drugi gorzej. Jeden daje spacje przy zagnieżdrzeniu, drugi nie. Nie zależy to (moim zdaniem) zupełnie od technologii - div czy table, choć trzeba przyznać, że table jest czasem więcej do pisania.

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

To moim zdaniem też zależy tylko od programisty - czy to jest table, czy div. W moich projektach tylko raz zdarzyło mi się żeby dać aż 3 zagnieżdrzone divy...

Cytat
menu nie jest listą.

W moim odczuciu menu jest listą wyborów... każdy link to osobna pozycja - połączenie osobnych pozycji może być listą... (może źle rozumuje ale takie mam odczucie)


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...
Table służy do danych tabularycznych...

Moim zdaniem, jeżeli w projektowaniu w DIVach spotyka się problem, gdzie trzeba użyć hacków, to wtedy niestety trzeba zacząć pisać kod OD NOWA inaczej...


Mam nadzieję, że dobrze zrozumiałem ten temat, choć do końca nie jestem tego pewien :/
Jeśli nie, to sorry.
DeyV
Hmm - faktem jest, że na tabelach prosty rozkład jest zrobić łatwiej.
Jest też większe prawdopowobieństwo, że już na początku design będzie wyświetlał się poprawnie w różnych przeglądarkach. Problem z clear jest znany, i wcale nie zawsze łatwo go obejść, nie raz się naplulem na zabawę z float i uciekaniem divów.

Ale... w końcu po to tu jesteśmy by się uczyć. A skoro mądrzejsi od nas ludzie z W3C stwierdzili, że lepiej jest od razu wykorzystywać bloki, to ja im wierzę.
Mało tego - gdy w praktyce mi sie to sprawdza, to z tego korzystam.

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.

Łatość modyfikacji odgrywa tu również spore znaczenie, choć nie dominujące - choć przyznam, że fajnie jest mieć wiki, które w zależności od podpiętego stylu wygląda na zupełnie inne projekty, praktycznie bez zmian w strukturze html. I nie ma znaczenia, czy jakiś blok ma być na górze, dole, po prawej czy lewej.

bigZbig wspomniał tu jednak o tym, że ponoć zalecane jest odejście od wszystkich zdefiniowanych tagów. A nie jest to prawdą. Ostatnio poczytalem sobie trochę porad na W3C dotyczących błędnych nawyków maniaków nowinek. I jedną z wymienionych tam manier było właśnie stosowanie DIV i SPAN wszędzie gdzie to tylko jest możliwe, w miejsce list, bloków, tabel, pogróbień i co tam jeszcze komuś do głowy przyszło.
A przecież użycie w takiej sytuacji specjalizowanego taga tylko upraszcza życie i zwiększa czytelność kodu.
Tak więc gdy chcemy listę (czy to będzie menu, czy tekst numerowany) warto korzystać z LI, a gdy chcemy tabelaryczne zestawienie danych - korzystamy z TABLE.

Ale gdy chcemy mieć ładny i dobrze ładujący się design - pracujemy na blokach... smile.gif
spenalzo
Nie znam sie na programach dla neiwidomych i nie wiem w jaki sposób przedstawiają im strony www. Ale szczerze to.. ilu niewidomych odwiedzi twoją stronę? Jeden lub dwóch? - zakładając, że nie robisz strony przeznaczonej dla niewidomych oczywiście...


Rozmiar.
Jak dla mnie argument również nietrafiony - no chyba, że masz setki tysiecy odwiedzin miesięcznie i masz maly limit transferu. Ale w takich wypadkach to raczej przydaje sie bardziej zmiana szaty graficznej na bardziej ubogą aniżeli odchudzanie kodu.

A czy ktoś stosuje warstwy czy tabele - to jego sprawa, ważnu jest efekt końcowy. Ja jakoś nigdy nie miałem problemu z różnie wygladajaca stroną na różnch przeglądarkach.

Ale fakt - niezaprzeczalną zaletą wartsw CSS jest to co napisał Deyv - możliwość łatwej zmiany designu całej strony. Na tabelkach też sie to da, ale nie w taki sposób jak na warstwach... Przykład CSS garden (albo jakas podobna nazwa).
athabus
Cytat
Nie znam sie na programach dla neiwidomych i nie wiem w jaki sposób przedstawiają im strony www. Ale szczerze to.. ilu niewidomych odwiedzi twoją stronę? Jeden lub dwóch? - zakładając, że nie robisz strony przeznaczonej dla niewidomych oczywiście...


Programy po prostu sczytują treść na głos. Problem w tym, że tabelki nie niosą żadnej treści, tak samo jak np. obrazki używane jako tło itp... Wszystko to sprawia, że śmietnik odpowiedzialny za prezentację utrudnia/uniemożliwia odczytanie strony.

Co do ilości odwiedzających - no cóż... a ile osób niepełnosprawnych dziennie korzysta z choodnika procentowo w stosunku do osób pełnosprawnych... może więc zrezygnujemy z podjazdów itp biggrin.gif IMHO nawet jeśli to będzie 5 osób na tydzień, to dla tych 5 osób to będzie ważne.

Ogólnie uważam że prezentację należy oddzielać od treści - między innymi rezygnując z tabelek. Tak samo jak rozdziela sie warstwy w MVC.
spenalzo
Cytat(athabus @ 21.06.2006, 19:46 ) *
Programy po prostu sczytują treść na głos. Problem w tym, że tabelki nie niosą żadnej treści, tak samo jak np. obrazki używane jako tło itp... Wszystko to sprawia, że śmietnik odpowiedzialny za prezentację utrudnia/uniemożliwia odczytanie strony.

No to w czym problem? Chyba że taki program czyta strone w taki sposob: "table, tr, menu główne, td, jakis link,td".... w co wątpie. Nie rozumiem przewagi divów nad tabelkami w tym miejscu.
athabus
Znam tylko z opowieści... mama zamiar sprawdzić w realu. Z tego co wiem to główny problem polega na tym, że te programy zacinają się na tabelkach i innych bajerach ponieważ to co Ty widzisz w przeglądarce jest logicznie dla Ciebie ułożone... ale w kodzie różne, często wizualnie spójne rzeczy, są "rozwalone". Dlatego właśnie chodzi o to aby struktura dokumentu (nagłowki, bloki tekstu itp) były wyodrębnione w html/xhtml a prezentacja w css.
Przykład: Programy czytając robią pauzę po akapicie, bloku tekstu, akcentuje wszystko co jest ważne (czyli np. znaczniki <b> lub <strong>) itp . Jeśli nawstawiasz jakichś <br>, <b>, <tr>, <td> itd tylko po to "aby ładnie wyglądało" to wyboraź sobie jak ten program to przeczyta. Pół biedy jeśli tabelki są poukładane tak, że tekst jest logicznie spójny... ale sam wiesz, że często zagnieżdza się tabele itp poto aby uzyskać odpowiedni efekt końcowy.

Ogólnie pewnie da się zrobić dobrą i przemyślaną stronę na tabelkach, którą niewidomi przeczytają, ale korzystając z wytycznych w3c to zadanie jest znacznie łatwiej osiągnąć.

Właśnie przymierzam się do instalaci jakiegoś czytnika, żeby zobaczyć jak to działa. Wnioskami na pewno się podzielę jeśli temat nadal będzie na topie biggrin.gif
Kuziu
Cytat(spenalzo @ 21.06.2006, 18:18 ) *
Rozmiar.
Jak dla mnie argument również nietrafiony - no chyba, że masz setki tysiecy odwiedzin miesięcznie i masz maly limit transferu. Ale w takich wypadkach to raczej przydaje sie bardziej zmiana szaty graficznej na bardziej ubogą aniżeli odchudzanie kodu.


Tak ale grafika pozostaje w Cache tak jak i CSS a treść nie.
mike
Cytat(spenalzo @ 21.06.2006, 18:18 ) *
Jak dla mnie argument również nietrafiony - no chyba, że masz setki tysiecy odwiedzin miesięcznie i masz maly limit transferu. Ale w takich wypadkach to raczej przydaje sie bardziej zmiana szaty graficznej na bardziej ubogą aniżeli odchudzanie kodu.

Nie trafiony bo nie rozumiesz.

Rozmiar jest bardzo istotny, nie byłby jeśli te dokumanty różniłyby sie minimalnie, ale różnią się znacznie. Często bardzo znacznie.
Masz rację że żeby różnice w transferze na serwerze były znaczne potrzebowalibyśmy wielu odsłon.

Ale tu chodzi o swobodę oglądania.
Dla pojedynczego użytkownika rozmiar ma znaczenie, bo to jelu strona ładuje sie wolniej lub szybciej. I nie do końca chodzi tu o pobranie dokumentu, choć i to są czasem setki kilo. Chodzi to o składanie tego do kupy.

Przeglądarka składając taki design z tabelek nie złoży go dopóki nie pobierze całości, natomiast bloki wyświetla po tym jak je przeczta a resztę dokłada.

Nie każdy ma super łącza, ja sam mam tylko 128kbps a to nie jest wiele.
Zmniejszając wielkość dokumentów przyczyniamy się do lepszego ruchu w sieci.
spenalzo
No właśnie o to mi chodzi - dopoki nie masz setek tysiuęcy odwiedzin przy bardzo niewielkim transferze, to różnica pomiedzy np. 5kB z CSS a 8kb z tabelkami to NIC nie znaczy.
mike
A jednak faktycznie nie rozumiesz.

Tak dla Ciebie nie.
Ale znaczy dla mnie kiedy oglądam Twoją stronę.
Master Miko
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
Seth
Nie przeczytalem calego tematu, ale zanim zgubie swoja mysl chcialem sie nia podzielic.

Sadze, ze rozumiem zarzuty bigZbiga co do DIVow bo tez wg. mnie nie sa to elementy, ktore bezproblemowo mozna wykrozystac.
Tabelki wydaja sie znacznie prostsze do konstruowania... no ale kosztem przejrzystosci i ilosci kodu.

Od ponad roku nie uzywalem tabelek do budowy szkieletu strony i zapewne nie wroce do takeigo podejscia. Jednak DIVy nie sa doskonale i czasami mam wrazenie, ze ich tworcy nie do tego je przeznaczyli - fakt tez jest taki, ze caly czas ucze sie nowy trickow (dzieki mike_mech winksmiley.jpg), ktore przyblizaja mnie do tego, ze powoli budowa struktury zaczyna mi isc latwiej.

Jednak strasznie brakuje tutaj jakichs tagow, ktore dzialaly by podobnie jak placeholdery w aplikacjach okienkowych czy chocizaby tak jak w XULu.
Brakuje tez standardow - dzisiaj sklalem IE juz setki razy... ale coz... nie ma co liczyc na to, ze w najblizszym czasie sie cos zmieni, wiec trzeba wybrac mniejsze zlo (chociaz to stwierdzenie jest chyba za mocne).
hwao
Ja buduje na div'ach poniewaz jest do dla mnie instynktowne. Swoja droga jak widze layout pociety w tabelkach i mam go wdrozyc to mnie szlak trafia.

Pozatym wiem ze na divach zrobie latwiej trudne rzeczy, badz tez takie ktorych wogole sie nie zrobi na tabelkach
bigZbig
Cytat(Master Miko @ 21.06.2006, 16:54 ) *
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?

Cytat(DeyV @ 21.06.2006, 16:58 ) *
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.

Cytat(DeyV @ 21.06.2006, 16:58 ) *
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

Cytat(Master Miko @ 21.06.2006, 23:01 ) *
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.

Cytat(hwao @ 22.06.2006, 07:52 ) *
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?
Vertical
IMHO lepiej jednak używać divów od tabelek. Na początku używałem tabel do layoutu strony, ale po wykonaniu 2-3 stron w ten sposób, przerzuciłem się na divy. Głównym problemem było to, że kod "tabelkowy" był dużo bardziej zagmatwany i mniej przejrzysty. Żeby uzyskać blok tekstowy za pomocą diva, wystarczy użyć w zasadzie tylko jednego znacznika (<div>); natomiast żeby stworzyć tabelkę musimy już użyć (<table>, <tr> oraz <td>). Może na pierwszy rzut oka nie wydaje się to duża różnica, ale po jakimś czasie, zwłaszcza kiedy zacznie się zagnieżdżanie tabelek, nie dość, że opóźni to w wielu przypadkach wyświetlanie strony, to w dodatku domyślenie się, o co właściwie chodzi w kodzie strony lub w którym momencie jest błąd, będzie o wiele trudniejsze.
ens0re
Cytat
(...)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

Raczej kiepski webmaster.
DeyV
Cytat(bigZbig @ 22.06.2006, 09:07 ) *
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ć.
athabus
@bigZbig - ja nie napisałem, ze odejscie od tabelek zalatwia sprawe. Chodzi o odejscie od poBaBRanego kodu ktory nie niesie struktury a prezentacje - a tabelki sa jednym z jego elementow. Jesli html/xhtml jest poprawnie uzyty to przypomina ksiazke i z takim kodem czytnikom jest sobie znacznie latwiej poradzic.
Ja potrafie zrozumiec czemu takie czytniki nie radza sobie ze stronami opartymi na zle napisanym kodzie. Po prostu trudno wymyslic algorytmy do odczytania tekstu, w ktorym uzyto znacznikow w sposob niezgodny z ich przeznaczeniem.
revyag
Cytat
No a czy float zostalo zaprojektowane do budowy szkieletu strony?

A powiedz do czego zostało zaprojektowane ? 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).
http://www.w3.org/TR/CSS21/visuren.html#propdef-float

Cytat
Do ustalania pozycji danego bloku na stronie zostało wymyslona dyrektywa position,

No a właśnie że nie snitch.gif
http://www.w3.org/TR/CSS21/visuren.html#positioning-scheme
mike
Cytat(Chewolf @ 22.06.2006, 10:47 ) *
(...) A po za tym i tak każdy wybierze to co mu będzie odpowiadać. (...)

I bardzo dobrze.
Taki wybór mowi też coś o wiedzy autora i o jego profesjonaliźmie. Ale niech wybiera co mu odpowiada jeśli za bardzo nie dba o swój rozwój winksmiley.jpg

Ja tam bardzo się cieszę, że są ludzie którzy projektują na tabelkach, kiepskie, przeciążone, nieskalowalne, trudbe do poprawy layouty.

Przy nich można nabrać kontrastu i dostać lepsze wynagrodzenia za swoją pracę. laugh.gif
stoprocent
To jest dyskusja ktora moze trwac na zawsze . Jesli pojawiaja sie nowe standarty i wiekszosc stara sie na nie przestawic to jednak cos znaczy.
Po co pisac w php5 kiedy php 4 dalej jest rozwijane, po co flash kiedy sa animowane gify (flash nie biorac pod uwage AS winksmiley.jpg ) po co nowe wersje photoshopa kiedy w starych mozna bylo stworzyc design i do tego mniej ramu zuzywalismy. Jesli staniemy w miejscu to nigdy do niczego nie dojdziemy. Divy i budowanie stron blokowo mozna traktowac jako rozwoj technologi.
bigZbig
Cytat(DeyV @ 22.06.2006, 09:57 ) *
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.

Cytat(DeyV @ 22.06.2006, 09:57 ) *
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.

Cytat(revyag @ 22.06.2006, 10:35 ) *
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

Cytat(Chewolf @ 22.06.2006, 10:47 ) *
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?
DeyV
Heh - przypomniało mi się, że ktoś ostatnio zarzucił mi, że w jednym ze swoich najnowszych projektów część layoutu mam umieszczony w 1 czy 2 tabelach.
I trochę głupio mi się zrobiło, bo jednej strony tak otwarcie w tym temacie popieram xhtml, a potem sam łamię jego zasady.

Ale fakt jest taki, że trzeba sobie umieć radzić, i decydować, kiedy można iść na kompromis, bo jest to uzasadnione, a kiedy po prostu jest to wynikiem lenistwa.
Ja staram się, by tego typu decyzje w moich pracach były decyzjami przemyślanymi, które potrafię uzasadnić.
I myślę, że taka powinna być konlkuzja rozmów o standardach i zaleceniach smile.gif
Pozdrawiam
ens0re
Trzeba też zwrócić uwage na to, że nie zawsze stosowanie XHTML i CSS uczyni stronę lepszą, bardziej dostępną , ktora bedzie mniej zuzywać łącza itp itd. XHTML i CSS można stosować także źle. Jednym z przykładów jest znana 'choroba' divitis bądz classitis.

I jeżeli ktoś stosuje tabelki badz tabelki połączone z divami, to niech pisze strony w układzie hybrydowym a nie ścisłym.
Sh4dow
Ja tutaj widze ciagnięcie jednej brzydkiej przypdałości poczatkującym programistom php i chyba wszystkich bardzo elastycznych i prostych jezykow.
Na poczatku kazdy proboje cos złozyc zeby cos sie stalo, a pozniej zostaje i wychodzi zalozenie po co to zmieniac skoro dziala. Zostawia sie stare smieci, pomimo ze sa wywalona za return. Po co uwazac na specyfikacje W3C skoro jakos to wyglada. o co sie przejmować ze cos może sie nie pojawic/wgrac/obliczyc skoro to jest tak prosto napisane ze musi dzialac. Jesli puki sam testujesz ogladasz to dziala, ale pozniej robi sie kupa. Z uzywaniem tabel do struktury strony to tez jest jakis sposob, na rozwiazanie tego "jak dziala to po co sie meczyc".
Robie wiekszosc rzeczy na divach, tabelki uzywam jak wyswtetlam tabelke. Jesli ktos powie ze robi sie bałagan w kodzie to moze z powodu nie umiejetnosci zoptymalizowania ? Nie wnikam. A czemu nie stworzyc narzedzia pomagającego w projektowaniu strony. jesli dobrze pamietam to 6 DIV'ow i masz strone 3 kolumny, head/foor skalowane w zaleznosci od wielkosci okna. a do tego moze 30-40 lini css'a.

Co do zasady 'jak to dziala to po co sie meczyc' nauczyl nas Gigant M$ i czescowo lenistwo. No bo zeby zrobic na blokasz szablon strony, to z IE sa problemy. Tricky hacki zeby to dzialalo. Pozniej ktos znalazl tabele i niby sie skonczyl problem. Niby bo czasmi jesli widze tabelke w tabelce i tak zagniezdzone 4 razy bo ktos zapomnial co to jest 'margin' w css'ie no to o czym my rozmawiamy. Braki w wiedzy, lenistwo i inne nie do konca przemyslane rozwiazania. Z jakiegos powodu konsorcjium W3C stworzylo taka a nie inna specyfikacje.

A jako ze wiekszosc ludzi tutaj jest programistami php powinni wiedziec jak ułatwic sobie sprawe w generowaniu takiego kodu html aby on jakos wygladal i byl prosty do edycji.

Dla mnie stworzenie standardowego wygladu strony przy pomocy div'ow jakos nie sprawia problemu. Wiec czemu mam sie bawic tabelkami ?

Tak, czy inaczej kazdy robi tak jak chce.
shpyo
Ludzie po co ta dyskusja? Już tyle się nadyskutowałem o tym "div'y VS tabelki" i nasuwają mi się tylko dwa wnioski.
1. Osoba, która robi (x)HTML nie ma o tym zielonego pojęcia i nie ma pomysłów.
2. (chyba najważniejsze) Grafik nie ma pojęcia o funkcjonalności serwisów - ma wizję zajebistego projektu graficznego (nawalone grafiki, gradientów, cieni, tekstur) to nawet najlepszy html-owiec padnie. Minimum podczas projektowania powinien minimum mieć pojęcie o html, jeżeli ma jakiś problem lub wątpliwość niech spyta się się html-owca czy da się tak, jeśli nie to w jaki sposób można to rozwiązać.

Więc takie dyskusje - tabelki czy div nie są warte zachodu.

pozdr,
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.