Wielu ludziom wydaje się, że jeśli potrafią narysować fajny
splash albo zbudować dynamiczne menu w JS, to są guru webdesignu. Błąd. Design to także projektowanie struktury dokumentu, semantyczne opisywanie danych, bo to właśnie dane stanowią podstawową część serwisu, a nie grafika i layout, przynajmniej w teorii.
XHTML rozpoczął wielką rewolucję w dziedzinie aplikacji i serwisów webowych. Z jednej strony wniósł wiele dobrego, bo ludzie zaczęli interesować się składnią, a nie tylko wyglądem stron. Z drugiej zaś strony zmienił stare złe nawyki w jeszcze gorsze nowe. Dla sporej liczby osób poprawna
konstrukcja serwisu to ikonka walidatora u dołu strony. Jest to wierutną bzdurą, bo walidacja z założenia jest narzędziem, a nie celem samym w sobie. Ma pomóc w odnajdywaniu błędów składniowych w serwisie, a nie definiować składnię jako taką. Jeśli zamianę tabeli na setkę absolutnie pozycjonowanych bądź precyzyjnie floatowanych divów można nazwać celem samym w sobie, to dla mnie to jest sport, a nie webdevelopment. div, podobnie jak span jest elementem przezroczystym z punktu widzenia semantycznego. Syntaktycznie jest jak najbardziej poprawny i walidator nie powie o nim złego słowa, ale z punktu widzenia struktury dokumentu nie niesie ze sobą absolutnie żadnego znaczenia.
I co z tego?
- ktoś zapyta. Choćby to, że strona nadaje się do oglądania tylko tak długo, jak długo skojarzony jest z nią arkusz CSS. Proponuję obejrzeć wynik swojej pracy w przeglądarce tekstowej. Nikt nie używa przeglądarek tekstowych!
Używa. Najlepszym przykładem jest wyszukiwarka Google. Roboty sieciowe i ich automatyka nie mają oczu, nie docenią wspaniale rozplanowanych boksów, idealnie wykadrowanego zdjęcia w tle, nie zwrócą uwagi na wyróżnienie tytułów za pomocą zgrabnych ikonek. Zobaczą długi listing tekstu, który po obraniu z wszelakiej maści divów posiada tyle informacji o strukturze, co dokument z notatnika.
Skutki? Niska pozycja w wyszukiwarkach, a na tym chyba wszystkim zależy najbardziej. Żyjemy w czasach, kiedy komputer stał się dla wielu ludzi podstawowym narzędziem pracy. Potrafią efektywnie wyszukiwać interesujące ich informacje w sieci. Pod jednym warunkiem, że informacje te chcą dać się znaleźć. Nie oszukujmy się, możesz wydrukować setki ulotek, rozesłać ogłoszenia, wywiesić plakaty. Większość odwiedzających trafi na twoje strony za pośrednictwem wyszukiwarek i odnośników z innych serwisów. Stąd potrzeba semantycznego opisu dokumentu, stosowania różnych poziomów nagłówków, opisywania paragrafów tekstu, walidacji kodu.
Druga po divitis ciężka choroba współczesnego internetu to classitis, jak żartobliwie określa się prewencyjne uklasowienie
każdego możliwego elementu na stronie. Klasy z definicji są kaskadowe, co oznacza dziedziczenie i propagację. Trzeba o tym pamiętać, żeby więcej nie tworzyć kwiatków w stylu:
<img class="img_no_frame" src="..." alt="" />
A zapewniam, że jest to przykład z życia wzięty. Jeśli większość elementów danego typu ma na stronie te same cechy, to należy je zdefiniować jako podstawowe cechy danego elementu, a klasami opisywać jedynie wyjątki:
img
{
border: 0;
}
.miniaturka
{
border: 1px solid #f00;
}
Klasy posiadają też selektory, które służą do kontekstowego wybierania elementów, do których odnoszą się reguły CSS. Stąd zamiast pisać:
<div id="menu"> <a class="menu_link" href="...">strona 1</a> | <a class="menu_link" href="...">strona 2</a> | <a class="menu_link" href="...">strona 3</a> </div>
#menu
{
...
}
.menu_link
{
color: #00f;
}
Lepiej napisać:
<div id="menu"> <a href="...">strona 1</a> | <a href="...">strona 2</a> | <a href="...">strona 3</a> </div>
#menu
{
...
}
#menu a
{
color: #00f;
}
Od razu robi się prościej i przejrzyściej. Należy tylko pamiętać o tym, że w kodzie jednego dokumentu nie mają prawa znaleźć się dwa elementy o takiej samej wartości atrybutu id.
Kolejna sprawa odnosi się do nazewnictwa klas. Grzechem powszednim jest nazywanie klas white_11
, td_top_red
, czy red_underline
. Wiąże się to z podejściem do kodu z perspektywy programów WYSIWYG, gdzie część prezentacyjna (wygląd) wymusza część strukturalną (kod). Powinno być dokładnie na odwrót, wygląd powinien być tylko dodatkiem do struktury, a klasy styli powinny mieć nazwy funkcjonalne. Jeśli postanowisz zmienić layout strony, klasa godzina_wyslania_posta
pozostanie godziną wysłania posta, natomiast white_11
może wyglądać nieco głupio, kiedy w rzeczywistości napisy będą miały czcionkę rozmiaru 25px i staną się czerwone.
Wiesz… pierwszy raz się z Tobą w stu procentach zgadzam ;-)
To czemu nigdy nic nie piszesz? ;]
Bo niestety, bardzo źle reagujesz na krytyke.
A można przykład jakiś konkretniej? Cokolwiek niezwiązanego z pewnym komunikatorem…
Niestety. Właśnie to o czym myślisz wpłynęło najbardziej na moją ocene, ze względu na skale tego 'wydarzenia'.
A SW3 mi się podobało ;-P
Tylko że tam większość krytyki dotyczyła mojego przyrodzenia, a połowa ludzi nawet nie przeczytała tego, o co chodzi. Ja krytykę przyjmuję bardzo chętnie, bo nie uważam się za JedynegoNieomylnego[tm].
Dobra, może masz racje [niestety, to, że kiepsko reagujesz na krytyke się potwierdza ;-)].
Ale podsumowując Twój wpis, to powiem tak:
Najpierw się powinno robić treść dokumentu, oznaczająć odpowiednie części odpowiednimi tagami, z wykluczeniem div'a, zakładając, że ta strona, to będzie zwykły czarnobiały dokument. Potem nakładać style grupując merytorycznie jednolite części div-ami, ale najlepiej jak najmniej. I strona powinna być dobra.
Dokładnie, dokument powinien opierać się na treści, która następnie ubierana jest w wygląd zgodny z projektem grafika, a nie projektem grafika, w który próbuje się poupychać treść.
No to powiedziałem to samo ;-)
BTW: trzeba reklamować: http://olejie.uaznia.net/ ;-)
Heh, mój jogger przez prawie rok był całkowicie nieosiągalny w IE ze względu na to, że złośliwie zaopatrzyłem go w czarne litery na czarnym tle i pseudoklasy :hover, których IE nie rozumie ;]
http://www.wydawnictwoamber.pl/ - podręcznikowy przykład divitis. W <body/> nie ma żadnego taga oprócz <div/>, <img/> i <a/>.
OMG! Padłem, to ja nieświadomie całkiem opisałem ich sajt tutaj właśnie. Też nie słyszeli wcale o kaskadzie, a najbardziej widocznym elementem u dołu strony są linki do walidacji, jakby któremukolwiek klientowi były do czegoś potrzebne. Ci, których to interesuje, nie potrzebują linka na stronie, żeby sprawdzić jej poprawność.
Menu jest boskie. Ile pan Bartłomiej Urban musiał się natrudzić, żeby z pomocą DIVów zasymulować idealnie wygląd typowego UL…
Nie można im odmówić tylko jednego, sensownie używają niełamliwych spacji.
Hmm… Ktoś powie mi, czemu nie można w CSSie tworzyć layoutów tabelkowatych? Czemu do robienia layoutu trzeba abusować floaty i kombinować jak koń pod górę, żeby ułożyło się tak jak my chcemy, zamiast semantyczne divy włożyć w prezentacyjną tabelkę?
No i czemu nie ma atrybutu, który tworzył by minipage z pudełka? Aby np. float zrobiony wewnątrz takowego nie oddziaływał z niczym będącym poza nim?
Prezentacyjna tabelka zabija ideę sematycznego kodu, gdzie oryginalny dokument jest drzewem o jawnym podziale na nagłówki i treść. Nie daje się też czytać przez screen readery. Poza tym jest koszmarem, jeśli chodzi o przygotowanie stylów dla wydruku.
"display: block" jest samowystarczalny, floatowane w nim elementy nie mają prawa oddziaływać z resztą strony. Wyjątkiem są te, które wystają poza box, ale zaradzić temu można nadając mu atrybut "overflow: auto" - wtedy box rozciąga się tak, aby pomieścić wszystkie floaty.
Nie zrozumiałeś mojego pierwszego pytania. Dlaczego nie można semantycznej strony poukładać według najbardziej naturalnej dla człowieka metody składu — podziału na kawałki o zadanych proporcjach?
Dokument jest nadal drzewem z nagłówkami i treścią, ale jest też miejsce na część prezentacyjną, menu itp.
Nie jest tak do końca… Nie można robić position: absolute względem nadrzędnego pudełka, niektóre inne pomyśły tez nie działają… Nie jestem Ci chyba w stanie podać w tej chwili konkretnego przykładu, ale wiem, że często musiałem niesamowicie kombinować, żeby to obejść (głównie wiązało się to z centrowaniem zawartości strony — tak jak u Ciebie na joggu).
jpc:
http://patrys.icenter.pl/test/2005-01-10-absolute-positioning/
http://liderkredyty.pl/pl/index
Bez problemu używam absolutnego pozycjonowania względem nadrzędnego boksa. Od tego jest "position: relative" między innymi - wszystkie dzieci danego elementu są wtedy pozycjonowane względem niego.
Tym mnie zaskoczyłeś — nie miałem pojęcia o takim ubocznym skutku position: relative. :)
Nadal odpowiedź na pytanie pierwsze pozostaje tajemnicą. ;]
Dziękuje ci za tą notke, wiele mi ona wyjaśniła. Będe tu częściej wpadał bo widzę, że mądrze piszesz ;)
jpc:
Ale ja przecież napisałem, że tam gdzie przejście robi się bez korzyści dla kodu ze względu na semantykę, tam robienie oceanu DIVów jest sportem.
Tak długo, jak dokument ma sens po wyłączeniu CSS, możesz używać tabelek do woli. Są rzeczy, których najlepiej zbudowanymi DIVami nie zrobisz - choćby dwukolumnowy układ z równaniem do dołu.
jpc:
ad 1: to jest do zrobienia; należy wykorzystać display: table; tylko, że to nie działa w IE, więc nikt tego nie używa. Kiedyś zrobiłem coś takiego: http://tnij.org/demo - same divy: niektóre jako table, niektóre jako table-row, i niektóre jako table-cell.
A w czym to jest lepsze od zwykłej tabeli, jeśli zajmuje 10 razy tyle kodu? Fakt, że może lepiej pasuje do wyświetlaczy komórek, ale wolałbym już użyć JS do tego celu i zachować czysty kod.
Myślałem o tym, zeby divy wcisnąc w wygenerowaną JSem tabelkę. Strona zachowałaby semantykę, ale wyświetlałaby się tak, jak chciałbym, by to robiła. :)
Chodzi mi właśnie nie o tabelki semantyczne, ale o tabelki mające na celu tylko i wyłącznie pozycjonowanie. Dlatego nieobecne w kodzie XHTMLowym, a jedynie w CSSie (lub innym pliku).
jpc:
http://www.hotdesign.com/seybold/everything.html
http://www.sitepoint.com/print/rounded-corners-css-javascript
@Nivertius: dobrze mowisz ;) SW3 jest swietne - dalej podtrzymuje moje zdanie, ze film mi sie podobal.
a co do posta - patrys - wiecej takich wynurzen - moze wreszcie zaczne lepiej jarzyc xhtml+css ;)
To pierwsze to chyba nie o tym: piszą czemu tabelki HTMLowe są złym narzędziem do pozycjonowania, ale nie piszą, czemu sama *idea* tabelki (albo raczej siatki) użytej do ustawiania wszystkiego gdzie trzeba jest zła…
To drugie całkiem fikuśne, ale takie rozwiązanie JSowe jakoś nie wydaje mi się dużo lepsze od 4 divów wrzuconych jak leci…
jpc: No właśnie. Jakiś "grid" (żeby nie mylic z HTMLowym <table/>) w CSS by się przydał.
jarv: Ja nie powiedziałem, że jest świetny, tylko, że mi się podobał ;-), tu raczej nie ma wiele więcej do powiedzenia.
Chociaż może jest:
Tagi są po to, aby ich używać. Ja nie wiem, ale chyba tylko zapaleńcy używają tagu <blockquote/>, bo przecież 'na prawdziwej stronie to jest niepotrzebne'. Nikt nie zabrania oznaczać tekstu przez <code/> <cite/> <dfn/>, <abbr/> itp. a jednak dużo twórców stron nie zna w ogóle takich tagów. A to jest wartosciowa sprawa, bo przeglądarki tekstowe, które może mogłyby rozumieć CSS, ale po co ;-), zaznaczą sobie tekst w odpowiedni sposób, np. zamiast tekstu grey będzie white.
Zastanawia mnie tylko jedno: dlaczego z XHTML1.1 wyrzucili <u/> a zostawili <i/> i <b/>. Owe tagi przecież ewidentnie oznaczają prezentacyjnie treść, nie logicznie, jak powinny. Jeden <b/> zamieniony na <em/> jest krokiem do przodu.
I jeszcze jedna rzecz do powiedzenia: menu po zawartości strony. Szczególnie dobrze napisane menu na ul-ach, które niestety niebotycznie się rozciągają na wysokość, gdy nie są stylowane. Pod przeglądarkami tekstowymi wygląda to tak, że treść dokumentu można dopiero zacząć czytać po przewinięciu dwóch 'ekranów', i tak co każdą strone. A problem to nie jest, bo w dobrze napisanej stronie przerzucenie menu pod treść to jest dosłowne przeniesienie kawałka kodu.
Z tego samego powodu właśnie tabelki są be, bo jak się chce mieć menu po lewej stronie, to ono musi być przed treścią strony…
XHTML1.1 to hybryda, podobnie jak CSS2.1 - coś pośredniego pomiędzy XHTML1.0 Transitional, a obecnym wsparciem przeglądarek.
Krótkie menu powinno być nad kodem strony. Tam też wyświetlają się odnośniki zdefiniowane przez <link/>.
Przy bardzo rozbudowanym menu lepszym rozwiązaniem jest "skip to content" niż kazanie komuś przewijać całej marketingowej papki długości książki w dół.
Wybacz: ale co ma Twoje pierwsze zdanie do nieusunięcia <b/>?
Bardzo krótkie menu dotyczące aktualnej strony owszem, ale nie cały linkowany konspekt portalu…
Zresztą tak naprawdę, to cała nawigacja, oprócz linków 'inline' powinna znajdować się w nagłówku strony, a przeglądarka powinna ją tworzyć jako zewnętrzne menu. Niestety, obecne rozwiązanie jakim jest <link/> jest do tego nie przystosowane…
Dla mnie XHTML1.1 nie nadaje się do zastosowania. Zawiera kupę śmiecia w postaci elementów, których tam być nie powinno, brakuje mu za to kilki rzeczy w drzewie DOM (np. opcjonalnym tagom nie można nadawać ID).
Ja tam jakoś nie narzekam, nigdy nie sprawił mi jakichś dziwnych problemów, robię strony tak jak chce i często 'od kopa' się validują.
Czekam na XHTML2.0, gdzie będzie [miejmy nadzieje] <section/> i <header/>, nie będzie problemu 'który nagłowek teraz'…
Ale bardziej czekam na CSS3 ;-)
A ja czekam, aż IE zacznie wspierać choć połowę z już obowiązujących standardów. Tworzenie setki nowych nic nie zmieni w świecie, gdzie 70% ludzi nie zobaczy efektów twojej pracy.
Patrys: to się zmienia, a jak będą standardy i zaczną się pojawiać fikuśne strony korzystające z nowych ficzerów, to i ludzie będą się chętniej przesiadać na Firefoxa/Operę/KHTML. :)
W każdym razie nadal brak GRIDa mnie frapuje… ;]
Tutaj jest troche błąd w takim podejściu, bo zatrzymamy się w 2001 roku z wyglądem i możliwościami stron. Jak dla mnie, to trzeba przyspieszyć migracje ludzi na inne przeglądarki. Gdy wejdzie CSS3, np. FF będzie już go obsługiwał [już obsługuje to co weszło z trzeciej wersji - nieoficjalnie i trzeba robić dodatkowe własności], IE dalej będzie zatrzymane na 1.5 a będzie więcej stron wykorzystujących standarty, to ludzie będą szybciej migrować…
No, jpc mnie o 80 sekund wyprzedził w tym co chciałem powiedzieć ;-)
Nadal będę używał tabel tam, gdzie css zawiedzie, bo trzeba to sobie przyznać, że zawodzi w wielu sprawach. Czasem też tygodniowa męka tworzenia css-designu jest nieopłacalna, bo kod istotnie się zwiększa. Mówią to nawet sami guru tego sposobu projektowania.
Według mnie ewangeliści css-design zamiast propagować ideę czystego i dostępnego kodu zrobili nagonkę na tabelki podając przy tym mętne powody, dla których należy rzucić owe tabele na korzyść nowego, jedynie słusznego stylu projektowania stron.
Cieszę się, że trafiłem na tego posta, bo to mi daje nadzieję, że są jeszcze ludzie, którzy krytycznie podchodzą do wszelkiego rodzaju "nowinek".
Problem z css jest jeden: Microsoft IE. Bardzo trudno zaprojektować coś co dobrze wygląda w FF(z.b) i jakoś działa w IE.
A co do nazw: czy white_11 nie jest funkcjonalne? A kogo to obchodzi!
Amen.
@mroq, wszystko jest dla ludzi ;] ale nagonka na tabelki, a raczej na tych, którzy stosowali je niezgodnie z ich przeznaczeniem jest całkowicie słuszna, założeniem xhtml i css jest przecież oddzielenie warstwy prezentacji od struktury strony, a tabelki w funkcji pozycjonowania łamią tą granicę, że już nie wspomnę, jak genialnie musi wyglądać odczytywanie takich stron przez przeglądarki odczytujące zawartość strony. Pomyśl o utopijnym świecie, w którym całkowicie odzielona struktura służy zarówno przeglądarkom, czytnikom RSS itp. Także tabelkom mówi nie!