O dobrych intencjach i kiepskim designie

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.

web