Witam..
mam w szkole specjalizacje w ramach dofinansowania Unii Europejskiej i wybrałem sobie specjalizacje Aplikacje Internetowe i tam uczy nas koleś żebyśmy swoje strony budowali na tabelach .. a teraz chcę zrobić swoją stronę i nie wiem czy ten pan ma racje?

tabele służą do wyświetlania danych tabelarycznych, nigdy - poza jednym wyjątkiem - do layoutu.

a co polecasz do prezentacji layoutu

ŁF napisał(a)

nigdy - poza jednym wyjątkiem - do layoutu.

Jakim jednym wyjątkiem?

tak tak to ja napisał(a)

a co polecasz do prezentacji layoutu

Odpowiednie elementy HTML.

http://osiolki.net/tabelki/

Aż dziwne, że w tych kilku postach jeszcze go nie oświeciliście ;).

Do prezentacji używa się kaskadowych arkuszy stylów -- CSS. Wciąż trzeba używać HTML-a, ale należy to robić w sposób semantyczny. Co to znaczy? Ano to, że dobierasz elementy (tagi) HTML nie ze względu na to, jak wyglądają, tylko na to, jak opisują daną zawartość.

Np. masz na stronie krótki, kilkowyrazowy "tekścik" podsumowujący dłuższy tekst na kilka paragrafów. Te kilka wyrazów umieszczonych jest w kodzie przed tekstem. Zwykle chcesz, by ten króciutki tekścik był pisany większymi literami, ale to nie ma aż takiego znaczenia. Czym jest ten krótki tekścik? Nagłówkiem. Więc dajesz mu tag

,

lub inny z tagów oznaczających nagłówki.</p>

Albo masz menu nawigacyjne. Czyli serię związanych ze sobą linków. Co to jest? Lista linków. Otaczasz więc całe menu tagiem

• (unordered list -- lista), każdy link otaczasz
• (list item -- element listy).</p>

  W obu przypadkach nie martwisz się na tym etapie o WYGLĄD nagłówka czy menu nawigacyjnego. Używasz tych tagów HTML, które odpowiadają danej zawartości znaczeniowo, a nie "wyglądowo". Lista domyślnie wygląda jak wypunktowanie w Wordzie, jeden element listy jest pod drugim i przy każdym jest jakiś znacznik wypunktowania (np. taka spora kropka). Tymczasem Twoje menu może na stronie wyglądać zupełnie inaczej! Pewnie nie będzie miało znaków wypunktowania, no i może nawet będzie poziome -- jeden link obok drugiego, a nie jeden pod drugim jak to domyślnie jest w przypadku listy!

  I tu właśnie wkraczasz z CSS. Używając CSS zmieniasz wygląd nagłówka (tagu

  ) i zmieniasz wygląd tej jednej konkretnej listy

  • , która robi u Ciebie za menu. W CSS mówisz, by ta lista nie wyświetlała znaków wypunktowania i by poszczególne elementy wyświetlane były koło siebie, a nie jeden pod drugim. W ten sposób "ostylowujesz" swoje menu nawigacyjne.</p>

  To koncepcja tzw. rozdzielenia warstw. HTML skupia się na znaczeniu, CSS skupia się na prezentacji.

  Zauważ proszę, że umieszczenie np. menu nawigacyjnego w jednej tabeli, a nagłówka w drugiej, to pomieszanie warstw. HTML służy w tej starej koncepcji jako coś do wyrażania prezentacji, zresztą robi to nieudolnie -- ma generalnie mniejsze możliwości niż CSS. No i menu wcale nie jest tabelą, nagłówek też nie jest tabelą!

  Plusów z rozdzielania warstw jest wiele i nie chcę tu ich teraz zbyt dogłębnie wyjaśniać, bo to temat na ciut dłuższą dyskusję. Generalnie strony oparte o HTML-u oraz CSS łatwiej się utrzymuje, łatwiej jest zmodyfikować wygląd strony. Ponieważ HTML dobrze opisuje treść strony, roboty wyszukiwarek (np. Googlebot) chętnie taki HTML zjadają i rozumieją i strona ląduje wyżej na stronie z wynikami wyszukiwania. Dodatkowo, kod HTML strony z podzielonymi warstwami jest znacznie mniejszy niż kod HTML z tabelkami i inną prezentacją. Dzięki temu strona ładuje się szybciej. Fakt, do rozmiaru strony dochodzi jeszcze rozmiar CSS, ale pliki CSS mogą być znacznie lepiej buforowane przez przeglądarkę niż dokumenty HTML i przez to przeglądarka ściąga arkusze CSS strony tylko raz. Potem, podczas dalszego chodzenia po stronie, ładowane są tylko kompaktowe dokumenty HTML. Poza tym jeśli w HTML-u miałeś jakieś złożone, udekorowane, powtarzające się elementy -- jak np. poszczególne znaleziska na Wykopie lub Diggu, albo komentarze na blogu -- to w przypadku wsadzania prezentacji do HTML-a musiałeś ciągle powtarzać ten sam HTML prezentacyjny. Czyli jeśli na stronie było 100 komentarzy, to musiałeś mieć 100 tabelek z różnymi atrybutami, elementami , < font > itd. W przypadku rozdzielania warstw poszczególne komentarze mają bardzo prosty, kompaktowy kod HTML -- kilka znaczników

  , czy jakiś nagłówek. Żadnych < font color ..> i innych skomplikowanych rzeczy. Potem w arkuszu CSS mówisz po prostu: niech WSZYSTKIE komentarze wyglądają tak i tak. Mówisz to RAZ, a nie 100x, jak przy użyciu samego HTML-a. Tutaj można zyskać sporo na mniejszym rozmiarze strony.</p>

  Warto wiedzieć, że to, co mówi Wam nauczyciel, to nie jest docelowa praktyka. Profesjonaliści nie tworzą stron www na tabelach. KIEDYŚ tak się robiło, ale już od jakichś 10 lat można i NALEŻY spokojnie stosować CSS. Dziś już nie zatrudnia się webdeveloperów, którzy CSS nie znają.

  Może nauczyciel jest starszej daty i nie odświeżył swojej wiedzy, może ma starą książkę ;), może jest na tym polu niekompetentny, a może po prostu chce na tym poziomie pokazać Wam coś prostszego. Generalnie na początku łatwiej zrozumieć budowanie strony na tabelkach i w ogóle przy użyciu samego HTML-a. Wiesz, HTML i CSS to już dwa języki, co z początku jest troszkę skomplikowane. Dodatkowo, jeśli chodzi o samo układanie elementów (pozycjonowanie), to CSS jest tutaj akurat stosunkowo słaby i niepotrzebnie skomplikowany w użyciu i nauce. CSS jest bardzo dobry, gdy trzeba udekorować jakieś elementy. Ma o wiele większe możliwości niż HTML. Ale samo pozycjonowanie jest dość skomplikowane dla początkujących i łatwiej jest wytłumaczyć i zrozumieć tabele.

  W szkole może brakować czasu na porządne wytłumaczenie współczesnych, rzeczywistych technologii i nauczyciel na te ograniczenia niestety nie ma wielkiego wpływu. Uczniowie także muszą przysiąść i muszą chcieć zrozumieć CSS i HTML, bo na pałę, w przerwie przed informą, się tego nie ogarnie.

  Ważna jest jedna rzecz: profesjonaliści w naszej branży nie są ludźmi, którzy nauczyli się swojego fachu w kilka tygodni czy nawet miesięcy. Nie są też ludźmi, którzy nauczyli się tego w szkole, czy nawet na studiach (!). Każdy dobry koder powie Ci, że do większości rzeczy doszedł pracując samodzielnie, w domu. Szkoła daje dobre impulsy do nauki, ale jeśli chcesz być dobry, to ostatecznie nie będziesz mógł polegać wyłącznie na szkole. Na razie jesteś młody i nie musisz zbyt hardcorowo się zajeżdżać własnymi projektami, ale wiele osób w szkole średniej już sporo kombinuje samodzielnie. Na studiach zaś TRZEBA to robić, jeśli chce się być po tych 3-4-5 latach gotowym do profesjonalnej pracy zawodowej.

  Nie chcę krytykować nauczyciela, nie znając kontekstu i powódek, które nim kierują. Jeśli jednak twierdzi, że współcześnie (od kilku lat!) tworzy się strony "na tabelkach", to nie, nie ma racji. Może jednak nie ma czasu na nauczenie CSS, czy coś. Uważam, że jeśli dałbyś radę samodzielnie ogarnąć CSS na tyle, by wykonać dawane Ci przez nauczyciela zadania bez tabel, to powinien Cię ocenić bardzo wysoko. To jednak tak naprawdę nie ma wielkiego znaczenia. Nauczenie się CSS zaprocentuje Ci w przyszłości. U nas w branży liczą się umiejętności, nawet nie oceny. Choć w zdobyciu umiejętności pomaga pójście na dobre studia (one dają dużo dobrych impulsów do nauki, no i sporo znajomości), a żeby się na nie dostać, to jakieś tam oceny trzeba mieć ;).

bswierczynski napisał(a)

Aż dziwne, że w tych kilku postach jeszcze go nie oświeciliście ;).

Niektórzy jeszcze studiują i nie mają czasu na pisanie takich esejów, jak Ty. ;)
Poza tym myślę, że warto przeczytać stronę z mojego linku. Pomaga zmienić punkt widzenia na pewne sprawy.

somekind napisał(a)

Jakim jednym wyjątkiem?
są takie sposoby ułożenia elementów obok siebie, że bez tabel idzie je dopasować tylko przez js. przykład jesteś w stanie znaleźć sam.

bswierczynski napisał(a)

Każdy dobry koder powie Ci, że do większości rzeczy doszedł pracując samodzielnie
yep. chociaż niekoniecznie w domu.

@bswierczynski

bardzo dobrze i z ciekawością czyta się twoje wypowiedzi :)

Polecam Ci przeczytać:

Projektowanie serwisów WWW. Standardy sieciowe - J.Zeldman

Poznasz dlaczego stosowanie się do standardów jest ważne i jakie są tego zalety

http://www.456bereastreet.com/archive/200410/bring_on_the_tables/

Większość najczęściej potrzebnej wiedzy o tabelach

HTML Mastery - Semantics, Standards, and Styling

najlepsza książka do HTML jaką przeczytałem.

Jeśli potrzebujesz na szybko zrobić stronę i niezbyt dobrze rozumiesz robienie tego w całości w CSS, możesz zastosować bardzo prostą strukturę tabeli, tzn używać tylko podstawowych tagów takich jak td, tr i atrybutów colspan, rowspan do stworzenia podstawowego szkieletu strony. Resztę postaraj się już wykonać CSS. IMHO najgorsze w starym stylu było stosowanie tagu font co bardzo zwiększało ciężar strony.

Jak już się nauczysz łatwo zmienisz taki layout na czyste CSS.

Puryści wpadną w święte oburzenie, ale z początku nie przejmuj się.</span>

ŁF - odpowiedni css i obejdzie sie bez znacznika

tak tak to ja napisał(a)

Witam..
mam w szkole specjalizacje w ramach dofinansowania Unii Europejskiej i wybrałem sobie specjalizacje Aplikacje Internetowe i tam uczy nas koleś żebyśmy swoje strony budowali na tabelach .. a teraz chcę zrobić swoją stronę i nie wiem czy ten pan ma racje?

Jeśli aplikacja ma tylko pięć okien to nie warto uczyć się stylów div i następnie pamiętać o organizowaniu tych wszystkich znaczników, bo głównie chodzi o zaoszczędzenie niewielkiej ilości miejsca w kodowaniu. Oczywiście, jeśli masz nadzieję, że dostaniesz jednak pracę przy robieniu aplikacji internetowych na zamówienie, to musisz się dostosować do wymagań klienta. Ja robię inaczej. Projektuję własne aplikacje, które dostarczają różnych usług po zalogowaniu i za te dostęp do zalogowania w aplikacji pobieram pieniądze. Wtedy nikt ode mnie nie wymaga idealnego kodu html a i tak aplikacja działa prawidłowo. [???]

głównie chodzi o zaoszczędzenie niewielkiej ilości miejsca w kodowaniu

chyba żartujesz. css nie ma nic wspólnego z oszczędzaniem miejsca. jeśli coś oszczędza, to czas, bo dzięki rozdzieleniu warstwy "danych" (html) od warstwy "prezentacji" (css) masz wszystkie definicje dotyczące wyglądu strony w jednym, osobnym miejscu. najczęściej jest to statyczny plik, który może modyfikować ktoś, kto nie ma pojęcia o programowaniu, a przez to, że każdy styl jest zdefiniowany tylko raz, nie trzeba biegać po dziesiątkach plików i w każdym poprawiać layout, a potem jeszcze każdą zmianę z osobna testować, czy coś się nie rozjechało.

Jeśli jest tylko kilka okien do zaprojektowania to oszczędności nie ma żadnej, bo uczenie się stylów, oddzielanie ich w pliku stylów i skakanie do nich, żeby zobaczyć co styl robi, akurat zajmie tyle czasu co umieszczenie ich bezpośrednio w kodzie strony. Poza tym trzeba wziąć pod uwagę ważną rzecz. Style są związane z układem czyli szablonem strony a rzadko się zdarza żeby programista miał jednocześnie zdolności artystyczne. Taką robotę należy zostawić grafikowi komputerowemu. Specjalizacja jest niezbędna! Często zdarza się że artysta grafik (AG) robi szablon w wielowarstwowym pliku photoshop i grafik komputerowy (GK) tnie to do html. Więc GK już się zajmie tymi stylami. Programista z powodzeniem może użyć takiego szablonu zrobionego przez inne osoby na zamówienie. AG i GK są więc podwykonawcami i takie układy się często zdarzają. Jeśli programista będzie tracić czas na samodzielne zrobienie szablonu, zamiast go zlecić podwykonawcy, to straci masę czasu, na którym mógłby zarobić robiąc w tym czasie back-end do innej aplikacji, więc to się mu nie opłaci a i tak samodzielnie robiony szablon wyjdzie mu gorzej.

ŁF napisał(a)

css nie ma nic wspólnego z oszczędzaniem miejsca.

To za mocne stwierdzenie. CSS często jak najbardziej pomaga oszczędzić miejsce. Raz, dzięki buforowaniu po stronie przeglądarki (CSS łatwo zbuforować, HTML nie), przez co rozmiar ściąganych danych jest de facto mniejszy. Dwa, dzięki wyeliminowaniu powtarzających się, skomplikowanych fragmentów kodu HTML (w CSS możemy powiedzieć, by te 100 komentarzy wyglądało tak i tak; w czystym HTML-u musimy to 100x powtarzać).

Nie znaczy to oczywiście, że CSS nie ma innych plusów, czy że zmniejszenie rozmiaru jest najważniejsze.

JP2 to pedo napisał(a)

bo uczenie się stylów, oddzielanie ich w pliku stylów i skakanie do nich, żeby zobaczyć co styl robi, akurat zajmie tyle czasu co umieszczenie ich bezpośrednio w kodzie strony

Skakać po różnych oknach i tak musisz (choćby: edytor kodu i przeglądarka). Generalnie, gdy kodujesz layout w CSS, to przeważnie nie przełączasz się ciągle pomiędzy plikiem HTML, plikiem CSS a przeglądarką, tylko najpierw piszesz czysty, mały HTML, a następnie dokładasz do niego style. Czyli zamiast skakania HTML-przeglądarka skaczesz po prostu CSS-przeglądarka. Z rzadka wprowadzasz jakieś zmiany do pliku HTML, przy czym często to nie jest w ogóle konieczne. Ilość skakania można ograniczyć dzięki doświadczeniu i używaniu odpowiednich narzędzi (np. dla Firefoxa Firebug i rozszerzenia, a także programik wykrywający, czy edytowałeś kod strony i automatycznie odświeżający kartę przeglądarki).

JP2 to pedo napisał(a)

Style są związane z układem czyli szablonem strony a rzadko się zdarza żeby programista miał jednocześnie zdolności artystyczne. Taką robotę należy zostawić grafikowi komputerowemu. Specjalizacja jest niezbędna!

Zdolności artystyczne nie mają tu wielkiego znaczenia. To design, nie sztuka. Designu można się nauczyć. Większość programistów rzeczywiście nie ma o nim bladego pojęcia i nie powinni projektować wyglądu stron www, czy nawet aplikacji.

JP2 to pedo napisał(a)

Często zdarza się że artysta grafik (AG) robi szablon w wielowarstwowym pliku photoshop i grafik komputerowy (GK) tnie to do html

Nie słyszałem jeszcze określenia "Grafik Komputerowy" w tym kontekście. Cóż, to by znaczyło, że przez pewien czas pracowałem jako grafik komputerowy. Pisząc kod. Ciekawe :).

Niektóre firmy faktycznie pozwalają designerom -- tym, którzy projektują wygląd witryny -- napisać również kod frontendowy (HTML, CSS i ew. jakiś bardzo prosty JavaScript). Niewielu designerów potrafi to jednak dobrze zrobić. Na Zachodzie tacy zdarzają się dość często. Twierdzi się, że znajomość technologii wyświetlającej stronę pomaga im w projektowaniu, daje dodatkowy kontekst i ograniczenia, dzięki którym nie projektują rzeczy, które w praktyce po prostu by nie działały. Ja w Polsce znam niewiele przypadków designerów, którzy potrafią napisać niezły HTML i CSS.

Ale zawsze można mieć po prostu programistę frontendowego (pozwolisz, że zastosuję to określenie zamiast "GK", ok?). Dostaje layout i tnie go do HTML-a, CSS, JavaScriptu i wszystko to umieszcza w plikach z szablonami strony (popularne Smarty lub coś innego). Taki programista frontendowy jest wręcz niezbędny, jeśli backendowcom brakuje kompetencji w pisaniu nowoczesnego kodu frontendowego. Tak jak to zdaje się być w Twoim przypadku.

Zauważ, że kod frontendowy z drugiej połowy lat 90., praktycznie pozbawiony CSS, nie ma plusów i uchodzi za kod niższej jakości. Oprócz tego nieszczęsnego wolniejszego wczytywania (co może mieć duże znaczenie, a może mieć marginalne), chodzi tu o naturalną przyjazność dla robotów wyszukiwarek (SEO przynosi wymierne zyski!), szybkość budowania kodu strony i łatwość utrzymania. To, że Tobie kodowanie w CSS idzie słabiej i wolniej nie oznacza, że jest gorsze. Brakuje Ci umiejętności i szybkości w posługiwaniu się przydatnym narzędziem, jakim są arkusze stylów.

Jeśli tutaj nie widzisz korzyści z rozdzielania warstw, to jak jest po stronie backendu? Czy tam też nigdy nie stosujesz MVC? CRUD/Active Record, czy w ogóle odwzorowanie obiektowo-relacyjne uważasz za zbędne przeszkadzajki w pisaniu porządnego, pisanego ciurkiem kodu PHP najeżonego zapytaniami do bazy danych i komendami echo wyświetlającymi HTML, oczywiście prezentacyjny HTML? I uważasz, że taka zupa z kodu jest fajna i wygodna, bo "wszystko jest w jednym miejscu i nie trzeba skakać po plikach"? :/ Testy jednostkowe też pewnie tylko zabierają czas?

Jeśli zaś kod po stronie serwera masz porządny, ładnie podzielony na niewielkie, logiczne, spójne fragmenty i przykładasz się do jakości, to pomyśl po prostu w ten sposób: programiści frontendowi mają podobne wymagania odnośnie czystości kodu, co Ty w backendzie. Jakby frontendowiec przyszedł i zaczął Ci klepać na pałę kod po stronie serwera, to też byś się za głowę złapał (chyba że sam tak piszesz :P).

bswierczynski napisał(a)

ŁF napisał(a)

css nie ma nic wspólnego z oszczędzaniem miejsca.

To za mocne stwierdzenie.

Nie wyraziłem się precyzyjnie: zmniejszenie ilości ściąganych danych przy przeglądaniu podstron uzyskane przez zastosowanie css jest poniekąd efektem ubocznym, często marginalnym (nieduża strona i/lub kompresja gz).

bo uczenie się stylów, oddzielanie ich w pliku stylów i skakanie do nich, żeby zobaczyć co styl robi
stylów uczysz się raz, wydzielenie do osobnego pliku to akurat wielki plus, a skoro to Ty piszesz ten css, to chyba nie musisz "skakać, żeby zobaczyć co styl robi". kiedyś się ze mną zgodzisz ;-)

ŁF napisał(a)

chyba żartujesz. css nie ma nic wspólnego z oszczędzaniem miejsca

A usunięcie z kodu znacznika font, to nie jest oszczędzanie miejsca? Bez przesady.

Obecnie to już może nie jest tak istotna, ale to też zaleta CSS.

@JP2 to pedo - z Twoich wypowiedzi wynika, że g**no wiesz o tworzeniu ston i utrzymaniu większych niż 2/3 podstrony.

font? to ktoś jeszcze z tego korzysta?
usunięcie z kodu znacznika font i zamienienie go na span - ile bajtów zyskasz?
zgadzam się, że CSS zwykle pozwala zmniejszyć rozmiar ściąganych danych, szczególnie jeśli użytkownik przemieszcza się pomiędzy podstronami i napisałem to już wcześniej, więc nie wiem do czego uderzasz. z drugiej strony przez to, że w pliku css lądują zwykle wszystkie style dla całej strony, to użytkownik wchodząc tylko na stronę główną ściąga także style, które nie zostaną użyte i są tylko nadmiarowymi danymi, co w szczególnych przypadkach może doprowadzić do zwiększenia objętości strony.
proszę czytać cały powyższy akapit ze zrozumieniem, żeby potem nie cytować kawałka zdania wyrwanego z kontekstu.

ŁF napisał(a)

usunięcie z kodu znacznika font i zamienienie go na span - ile bajtów zyskasz?

Jeśli się ponownie dokopię do źródła z którego czerpię info to zobaczysz jak bardzo dużo.
A jeśli kod wyglądał w stylu:

<font ....</p>

Ja o żadnych span'ach nie pisałem, to miał być przykład jak to dawniej CSS odciążało łącze.

Poza tym przeoczyłem Twoje wyjaśnienie, przepraszam.