W tym rozdziale dowiesz się...

Jak zostać prawdziwym profesjonalistą w dziedzinie tworzenia stron WWW?

• 
  CSS Zorientowane Obiektowo

  W jaki sposób tworzyć elastyczne strony WWW, które będą łatwe do rozwijania w przyszłości?

• 
  Przykazania webmastera

  Jak zostać prawdziwym profesjonalistą w dziedzinie tworzenia stron WWW?

CSS Zorientowane Obiektowo

W jaki sposób tworzyć elastyczne strony WWW, które będą łatwe do rozwijania w przyszłości?

Wstęp

Każdy programista wie, jaki przełom w rozwoju informatyki przyniosła koncepcja Programowania Zorientowanego Obiektowo (ang. Object Oriented Programming). Dlaczego by nie przenieść tego na grunt CSS? Może zabrzmi to zaskakująco, ale CSS już teraz daje taką możliwość. Nie są wymagane do tego żadne dodatkowe rozszerzenia w przeglądarkach, a jedynie zmiana sposobu myślenia webmasterów podczas projektowania arkuszy stylów. Paradoksalnie osobom, które nigdy nie programowały w językach proceduralnych, prawdopodobnie łatwiej przyjdzie zrozumienie założeń CSS Zorientowanych Obiektowo (ang. Object Oriented CSS), gdyż są one bardzo intuicyjne.

Obiekty

Popatrz przez chwilę na dowolną stronę WWW (tak, możesz spojrzeć również na stronę, którą właśnie czytasz :-)). Zwykle zawiera ona m.in.:

• nagłówek
• menu
• artykuł
• stopkę

Każdy z tych elementów z naszego punktu widzenia jest właśnie obiektem. Obiekt CSS to wizualnie samodzielny element strony. Artykuł potrafi wyświetlić się poprawnie bez nagłówka ani stopki serwisu. Taki sposób przedstawiania elementów strony jest dla człowieka bardziej intuicyjny niż pojmowanie jej jako zbiór wielu DIV-ów, SPAN-ów i innych znaczników. Obiektowość CSS sprowadza się do nadawania formatowania w kontekście takich obiektów, a nie poszczególnych znaczników występujących w kodzie źródłowym dokumentu. Pojedynczemu obiektowi zwykle odpowiada klasa CSS albo selektor identyfikatora:

#Header {
	/* nagłówek */
}

.Menu {
	/* menu */
}

.Article {
	/* artykuł */
}

#Footer {
	/* stopka */
}

Warto zwrócić uwagę, że w przypadku stosowania systemów parsowania szablonów na serwerze (np. w języku PHP), każdy obiekt jest kandydatem na zapisanie jego znaczników w osobnym pliku szablonu.

Atrybuty

Często obiekty nie są na tyle proste, aby można było określić ich wygląd przy pomocy pojedynczej reguły stylów (jednego selektora). Menu nawigacyjne będzie zawierać elementy podrzędne - listę odnośników - którym również musimy przypisać określony styl. Atrybuty stanowią zbiór wszystkich elementów (znaczników) potomnych obiektu, którym jest przypisany styl.

<div class="Menu">
	<ul>
	<li><a href="...">...</a></li>
	<li><a href="...">...</a></li>
	<li><a href="...">...</a></li>
	</ul>
</div>

Powyżej przedstawiony obiekt Menu może składać się z następujących atrybutów:

• wykaz ul
• punkt wykazu li (jeśli chodzi o stylizację, nie ma znaczenia, ile punktów ma wykaz, ponieważ wygląd dla nich określamy wspólnie)
• odnośnik a

W arkuszu CSS pełna definicja tej klasy może wyglądać na przykład tak:

.Menu {
	background-color: white;
}
.Menu ul, .Menu li {
	display: block;
	list-style: none;
	margin: 0;
	padding: 0;
}
.Menu li {
	float: left;
	margin-right: 1em;
}
.Menu a {
	color: blue;
	text-decoration: none;
}

Kompozycja

Zwróćmy uwagę, że typowy artykuł może zawierać informacje o:

• autorze - np. z jego imieniem, nazwiskiem i zdjęciem
• źródle - nazwa, logo i odnośnik

Każdy z tych elementów można traktować jako osobny obiekt (zmiana wyglądu informacji o autorze nie powinna wpływać na wygląd samej treści artykułu), z których składa się (ang. composition) główny obiekt artykułu. Myślenie o skomplikowanym obiekcie jako o złożeniu kilku mniejszych, samodzielnych obiektów, ułatwia nam pojmowanie otaczającej nas rzeczywistości. Patrząc na typowy komputer widzimy, że składa się on m.in. z ekranu, klawiatury, urządzenia wskazującego (np. myszki), a nie z masy połączonych ze sobą tranzystorów i innych elementów elektronicznych. Przeciętny człowiek nie byłby w stanie przyswoić tak wielkiej złożoności w postaci pojedynczego modelu. Z punktu widzenia kompozycji w obiektowości CSS chodzi o to, aby rozbijać w myślach skomplikowane obiekty na mniejsze i stylizować je oddzielnie. Korzyścią takiego podejścia będzie możliwość osadzenia np. informacji o autorze na osobnej stronie albo na liście wszystkich autorów piszących w serwisie.

Obiekty składowe są szczególnym przypadkiem złożonych atrybutów.

Przykład

<div class="Article">
	<div class="Source">...</div>
	...
	<div class="Author">...</div>
</div>

Rozszerzanie

W programowaniu zorientowanych obiektowo termin ten tłumaczy się częściej jako "dziedziczenie", jednak celowo używam tutaj innego pojęcia (ang. extends), aby nie myliło się z dziedziczeniem CSS, związanym z kaskadowością stylów.

Człowiek od zawsze miał potrzebę kategoryzowania otaczającej go rzeczywistości. Dzięki temu możemy łatwiej i precyzyjniej komunikować się ze sobą. Kategorie znaczeniowe, w jakie grupujemy otaczające nas obiekty, zwykle odzwierciedlają pewną hierarchię, opisującą różne poziomy ogólności poszczególnych pojęć. Na przykład laptop jest rodzajem komputera, a komputer jest rodzajem urządzenia elektronicznego.

Z punktu widzenia rozszerzania obiektów w CSS chodzi o to, aby stylizować elementy na różnym poziomie ogólności w zależności od ich przeznaczenia w serwisie. Przykładowo jeśli mamy już gotowy ogólny artykuł:

<div class="Article">...</div>

ale potrzebujemy jeszcze prawie identycznie wyglądającego artykułu recenzji (zawierającego dodatkowo np. ocenę redakcyjną), nie ma sensu tworzyć go od zera. Znacznie lepiej jest wykorzystać całą stylizację zapisaną w ogólnym artykule (Article), a osobno dodać tylko nowe rzeczy (Review):

<div class="Article Review">...</div>

Mówimy, że Article jest klasą bazową, którą rozszerza klasa pochodna Review.

Dzięki tej technice, unikając powtórzeń deklaracji, zmniejszysz rozmiary arkusza CSS (szybsze ładowanie, mniejszy transfer), a przede wszystkim przyspieszysz sposób zarządzania zmianami, ponieważ modyfikacja definicji klasy Article od razu zmieni elementy class="Article" oraz class="Article Review", tak aby pasowały do nowego szablonu witryny, a jednocześnie modyfikując klasę Review nie musisz się obawiać, że zepsujesz coś w elementach oznaczonych jako class="Article". Oczywiście możliwe jest rozszerzanie na większej liczbie poziomów zagnieżdżenia.

Wielokrotne rozszerzanie

Teoretycznie klasa pochodna może rozszerzać więcej niż jedną klasę bazową. Może to jednak wywołać trudne do przewidzenia konsekwencje przy zmianach deklaracji w klasach bazowych. Jeśli koniecznie chcesz skorzystać z tej techniki, klasy bazowe powinny być raczej maksymalnie uproszczone.

<div class="Information Important Warning">...</div>

W powyższym przykładzie klasa pochodna Warning (ostrzeżenie) ma dwie klasy bazowe: Information (informacja) oraz Important (ważne). Jednocześnie Important nie jest pochodną Information ani na odwrót - są to zupełnie niezależne klasy. Klasa pochodna (Warning) przejmuje stylizację zarówno z klasy Information (np. tekst ujęty w ramkę) jak i Important (np. czerwony tekst albo wytłuszczenie).

Przesłanianie

Co zrobić, jeśli recenzja - szczególny przypadek ogólnego artykułu - ma wyglądać jednak nieznacznie inaczej od swojego pierwowzoru (klasy bazowej)? Wybrane deklaracje z klasy bazowej można przesłonić (ang. override), przypisując im zmienione wartości w klasie pochodnej. Na przykład:

.Article {
	color: black;
	background-color: white;
	/* ... */
}

.Review {
	color: green;
	font-size: 12px;
	/* ... */
}

Pamiętaj jednak, że kolejność wymieniania nazw klas w atrybucie class="..." z punktu widzenia kaskadowości stylów nie ma znaczenia, dlatego należy zadbać, aby w arkuszu stylów definicja klasy Review znajdowała się później niż Article.

Ten prosty zabieg pozwoli nam uzyskać recenzję z zielonym tekstem, przy zachowaniu białego tła oraz ewentualnych wielu innych deklaracji, zdefiniowanych w klasie bazowej. W ten sposób, nawet przy istnieniu drobnych różnic wyglądu, nadal możemy korzystać z techniki rozszerzania cech obiektów, oszczędzając sobie sporo niepotrzebnego pisania. Gdyby jednak oba rodzaje artykułu wyglądały zupełnie inaczej, nie postępuj w ten sposób, gdyż tylko utrudni Ci to pracę.

Klasa abstrakcyjna

Klasa abstrakcyjna (ang. abstract class) jest przeznaczona wyłącznie do rozszerzania przez klasy pochodne, a nie do samodzielnego użycia w dokumencie. Jeśli w serwisie mamy więcej rodzajów publikacji, zapewne chcielibyśmy, aby każda z nich wyglądała podobnie. Takie wspólne deklaracje stylów możemy zdefiniować w klasie abstrakcyjnej Publication, a potem używać następująco:

<div class="Publication Article">...</div>
<div class="Publication Article Review">...</div>

Rożnica pomiędzy zwykłą klasą bazową (np. Article) a klasą abstrakcyjną jest taka, że nigdy w dokumencie nie pojawi się samodzielnie w postaci class="Publication". Mimo tego jest niezwykle przydatna, gdyż dzięki niej w jednym miejscu mamy zebrane deklaracje ogólnie stylizujące wszystkie publikacje w serwisie.

Singleton

Singleton to jeden ze znanych wzorców projektowych w programowaniu zorientowanym obiektowo. Jego celem jest zapewnienie, że w danym programie nigdy nie powstanie więcej niż jedna instancja określonej klasy. Na gruncie CSS zorientowanego obiektowo można to przyrównać do selektora identyfikatora, ponieważ w pojedynczym dokumencie HTML nie mogą istnieć dwa elementy o takim samym identyfikatorze (z identycznym atrybutem id="...").

Polimorfizm

Na koniec jeszcze jedna analogia do terminologii programowania zorientowanego obiektowo, znanego z niemal każdego nowoczesnego języka programowania. Stosowanie kontekstu selektorów można porównać do polimorfizmu, tzn. efekt działania tej samej deklaracji (klasy) zależy od typu elementu, do którego się odwołujemy. Na przykład:

<div class="Information Warning">...</div>

może działać inaczej niż

<span class="Information Warning">...</span>

chociaż nazwa przypisanej klasy CSS jest w obu przypadkach identyczna:

.Information {
	background-color: white;
}

div.Warning {
	color: red;
}

span.Warning {
	font-weight: bold;
}

Przykazania webmastera

Jak zostać prawdziwym profesjonalistą w dziedzinie tworzenia stron WWW?

Wstęp

Choć wiedza na temat konstrukcji samochodów czy komputerów jest powszechnie znana, niektóre firmy robią to lepiej niż inne. Najczęściej wynika to z ich innowacyjności (również umiejętności uczenia się od innych) oraz doświadczenia. Podobnie w dziedzinie tworzenia stron internetowych, można to wykonywać lepiej lub gorzej. Osoby początkujące często poruszają się po omacku. W ten sposób zanim zdobędą niezbędne doświadczenie, niejednokrotnie bardzo boleśnie przekonują się na własnej skórze, które rozwiązania byłyby lepsze od stosowanych przez nich w przeszłości. Kod w 100% zgodny z oficjalnymi specyfikacjami HTML i CSS niestety nie gwarantuje pełnego sukcesu - podobnie jak trudno oczekiwać, że każdy samochód potrafiący jeździć, usatysfakcjonuje klientów.

Samodzielne zdobywanie takiej wiedzy (doświadczenia) metodą prób i błędów mogłoby zająć całe lata. Nie musisz jednak tracić tyle czasu - teraz najważniejsze wytyczne masz spisane w jednym miejscu. Poniższa lista zawiera wskazówki, do których stosowanie się może zapewnić wysoką jakość Twojej pracy, poprzez uniknięcie często powtarzanych przez osoby niedoświadczone błędów architektonicznych. Powinno Cię również uchronić to od zabrnięcia w ślepe uliczki, z których potem bardzo trudno byłoby się wycofać. W skrajnym przypadku źle napisanego kodu w ogóle nie będzie się dało rozwijać, tzn. wprowadzając nawet z pozoru drobną zmianę na stronie, szybciej by było przepisać wszystko od nowa niż poprawiać istniejący kod. Stosowanie się do tego typu wytycznych często odróżnia osobę zajmującą się tworzeniem stron WWW tylko hobbystycznie od faktycznego profesjonalisty.

• Dobre praktyki HTML
• Dobre praktyki CSS
• Dobre praktyki skryptów

Dobre praktyki HTML

Dbaj o poprawność ortograficzną i stylistyczną tekstu

W dobie automatycznych korektorów pisowni, dysleksja nie może być żadnym uzasadnieniem błędów ortograficznych występujących na stronie. Naucz się zasad wpisywania znaków interpunkcyjnych. Uświadom sobie, że choćby oprawa graficzna Twojego serwisu była niezwykle estetyczna, a sama witryna bardzo funkcjonalna, rażące błędy ortograficzne wyglądają po prostu nieprofesjonalnie. Twoi potencjalni czytelnicy mogą wtedy z góry ocenić, że prawdopodobnie nie masz nic ważnego do przekazania i od razu opuszczą stronę.

Używaj polskich znaków diakrytycznych

Zrozumiałym może być, że SMS-y szybciej się pisze bez polskich liter. Podobnie nikt raczej nie będzie miał do Ciebie wielkich pretensji, jeśli nie używasz polskich znaków w rozmowach przez komunikatory internetowe. Choć osobiście jestem za tym, żeby nawet tam pisać w pełni po polsku, to potrafię zrozumieć, że wiele osób tak bardzo się spieszy, że nie ma ochoty używać tego dodatkowego klawisza Alt ;-) Jednak artykuły publikowane w sieci (w tym również prywatne blogi) są obszerniejszymi opracowaniami, gdzie brak polskich znaków diakrytycznych po prostu bardzo utrudnia czytanie. Poza tym kiedy nie używasz polskich znaków, automatyczne korektory pisowni nie mają szansy pomóc Ci w poprawianiu błędów.

Rozpoczynaj pracę od stworzenia semantycznego kodu HTML bez żadnej stylizacji

Jeśli od samego początku skupisz się na wyglądzie strony, możesz łatwo zapomnieć o semantyce, która powinna być zawsze nadrzędna. Postaraj się na tym etapie nie dodawać nawet żadnych klas CSS, elementów div ani span. Dopiero kiedy kod HTML będzie ukończony, zabierz się za jego stylizację przy pomocy CSS.

Nie używaj elementów ani atrybutów zdeprecjonowanych

Miały one na celu ustalanie wyglądu strony. Style CSS zostały stworzone właśnie po to, aby je wyeliminować (koncepcja rozdzielenia prezentacji od struktury dokumentu).

Unikaj stosowania ramek - zarówno tradycyjnych jak i lokalnych

Poza nielicznymi przypadkami, ramki nie są dobrym pomysłem. Z wadami takiego rozwiązania możesz zapoznać się w punkcie: "Czy stosowanie ramek jest bezpieczne?".

Nie stosuj tabelek do budowania układu strony

Zostały one przeznaczone do prezentacji zbioru powtarzających się danych. Jeśli wykorzystasz je do budowy szkieletu strony, mocno ograniczysz sobie możliwości późniejszej zmiany wyglądu serwisu (np. przeniesienie kolumny menu z lewej na prawą stronę itp.). Są lepsze alternatywy: Szablon strony na DIV-ach.

Nawigacja musi być intuicyjna i wygodna

Linki stanowiące menu nawigacyjne serwisu muszą być odpowiednio wyeksponowane. Niedopuszczalne jest, aby użytkownik szukał ich gdzieś w treści obszernego artykułu. Dobre miejsce na nawigację to nagłówek serwisu (poziome menu) oraz lewa lub prawa kolumna (pionowe menu lub menu z nagłówkami). Czasami w nagłówku umieszcza się powtórzoną nawigację, która zbiera najważniejsze odnośniki z całego serwisu. Podobnie coraz częściej powtórzona nawigacja pojawia się w stopce serwisu, ale w odróżnieniu od linków nagłówkowych, może zawierać znacznie więcej odnośników. Oprócz tego stopka jest dobrym miejscem na zaznaczenie praw autorskich i podanie odnośnika do kontaktu.

Zapomnij o wstawieniu nawigacji tylko na stronie głównej, a na podstronach samego linku "Powrót do strony głównej". To tylko niepotrzebny klik, a przy tym zmiana układu strony, co może zdezorientować użytkownika. Natomiast dobrym zwyczajem jest podlinkowanie na każdej podstronie logo serwisu (które powinno się znajdować w nagłówku), tak aby kliknięcie prowadziło na stronę główną witryny. Większość popularnych serwisów internetowych stosuję tę technikę, a więc wielu użytkowników jest już do niej przyzwyczajonych.

Menu powinno odzwierciedlać hierarchię kategorii, podkategorii itd. W przypadku rozbudowanych witryn zwykle nie ma jednak sensu udostępniać użytkownikowi od razu wszystkich poziomów, ponieważ znacznie wydłużyłoby to ładowanie strony. W takim przypadku można np. na poziomych zakładkach w nagłówku umieścić tylko główne kategorie, a po kliknięciu wyświetlać coraz głębsze poziomy zagnieżdżenia. Świetnym pomysłem jest specjalne zaznaczanie miejsca w nawigacji, gdzie w danej chwili znajduje się użytkownik. Przykładowo aktualnie wybrany link w menu może być pogrubiony. Dodatkowo przed właściwą treścią artykułu można umieścić tzw. ścieżkę nawigacji, czyli kolejne (najlepiej podlinkowane) kategorie nadrzędne - począwszy od głównej aż do aktualnie przeglądanej.

Unikaj używania atrybutu target="..." dla odsyłaczy

Decyzję o tym, czy odnośnik ma się otworzyć w nowym oknie, zwykle lepiej pozostawić użytkownikowi. Przecież to żaden problem kliknąć link środkowym przyciskiem myszki albo z przytrzymanym klawiszem Ctrl.

Nie używaj znaczników img do wstawiania grafiki tworzącej oprawę graficzną strony

Znacznik ten jest przeznaczony wyłącznie do wstawiania ilustracji w treści artykułów. Każdą inną grafikę wstawiaj w tle elementów strony - przy pomocy stylów CSS. Dzięki temu uzyskasz możliwość przygotowania odrębnego wyglądu w postaci skórek, a raz wstawionego obrazka img już nie da się w żaden sposób podmienić (bez zmiany jego atrybutu src="...").

Zawsze wypełniaj atrybut alt="..." dla ilustracji

Pamiętaj, że z Twojej strony mogą korzystać również osoby niewidome. A nawet jeśli nie, to właściwy tekst alternatywny może pomóc w podniesieniu pozycji Twojej strony w wynikach wyszukiwarek sieciowych.

Zapisuj ilustracje we właściwych formatach graficznych

• Do zdjęć najlepiej nadaje się format JPG.
• Dla ikon i przycisków często najlepsze rezultaty daje GIF.
• Format PNG posiada bardzo dobre możliwości kompresji oraz wiele stopni półprzezroczystości.

W żadnym razie nie używaj formatu BMP, gdyż jest on wyposażony w bardzo słabą kompresję, a więc zdjęcia tak zapisane będą się ładowały koszmarnie długo.

Stosuj fizycznie pomniejszone miniatury zdjęć

Jeśli masz na stronie galerię zdjęć, zadbaj, aby pełnowymiarowe zdjęcia ładowały się dopiero po kliknięciu w miniaturę. Miniatury w żadnym razie nie mogą być tymi samymi plikami graficznymi co duże zdjęcia, a jedynie pomniejszone przy pomocy atrybutów width="..." oraz height="...". W ten sposób, mimo iż zdjęcie na stronie wygląda na małe, faktycznie będzie się wczytywać tak długo jak duże. Pomijając już fakt, że cała strona z listą takich "miniatur" będzie się ładować koszmarnie długo, to przecież użytkownik może nie być zainteresowany każdym zdjęciem, a tylko tymi, które później kliknie, aby je powiększyć. Po co zatem już na starcie ładować mu wszystkie pliki w pełnych rozmiarach?

Strona powinna być czytelna bez grafiki

Oznacza to np. że nie możesz wstawiać treści artykułów w postaci obrazków tylko dlatego, że spodobała Ci się fantazyjna czcionka, która standardowo nie jest dostępna w popularnych systemach operacyjnych. A jeśli użytkownik będzie chciał zaznaczyć kawałek takiego "tekstu"? Jeśli już naprawdę musisz użyć niestandardowego fontu, dla krótkich nagłówków możesz skorzystać z techniki zamiennika obrazkowego, a dla obszerniejszych akapitów - z czcionek osadzonych.

Stosuj inny tytuł na każdej podstronie

Znacznik title powinien najlepiej odzwierciedlać treść zawartą na danej stronie. W związku z tym w każdym dokumencie powinien być inny, chyba że w serwisie masz dwa artykuły o identycznym tytule. Ponieważ znacznik ten może mieć również duże znaczenie, jeśli chodzi o pozycję strony w wynikach wyszukiwarek sieciowych, zaleca się nie wstawiać do niego bezużytecznych wyrazów - jak np.: strona główna, nienazwany dokument itp. Naprawdę chodziło Ci o to, żeby Twoja strona znajdowała się w wynikach wyszukiwania po wpisaniu takich fraz? ;-)

Używaj tytułów nagłówkowych

Doskonale dzielą one wizualnie obszerne teksty. Ułatwiają poruszanie się po stronie osobom niewidomym. Zapewniają lepszą pozycję Twojego serwisu w wynikach wyszukiwarek sieciowych. Pamiętaj również o prawidłowej kolejności wstawiania tytułów nagłówkowych: przed h2 zawsze musi się pojawić h1, przed h3 - h2 itd. Myśl o tym, jako o spisie treści książki z numerowanymi działami - h1 (1, 2, 3...), rozdziałami - h2 (1.1, 1.2, 1.3...), podrozdziałami - h3 (1.1.1, 1.1.2, 1.1.3...) itd. Doskonałym pomysłem jest również nadawanie identyfikatorów wszystkim tytułom nagłówkowym, które znajdują się w treści artykułów. Dzięki temu możliwe będzie odwołanie się do nich poprzez odsyłacz etykiety.

Dla każdego widocznego pola formularza używaj znaczników label

Nie tylko upraszczają korzystanie z pól opcji i wyboru (można kliknąć w tekst, a nie trzeba dokładnie celować w niewielką kontrolkę), ale również ułatwią używanie Twojej strony przez osoby niewidome.

Grupuj pola formularzy znacznikami fieldset, a nie div

Grupowanie pól ułatwi użytkownikom korzystanie z rozległych formularzy. Jeśli dodatkowo grupy pól są opatrzone legendą (znacznik legend), ułatwiasz w ten sposób korzystanie z takiego formularza osobom niewidomym. Przeznaczeniem znacznika div nie jest logiczny podział treści, tylko oznaczenie fragmentów kodu źródłowego w celu jego stylizacji.

Tam gdzie to tylko możliwe, używaj znaczników, które najbardziej szczegółowo oddają znaczenie elementów

Na przykład znacznik dfn niesie ze sobą więcej informacji o znaczeniu elementu niż em, a tym bardziej i. Lepiej oznaczony kod, to później łatwiejsza jego stylizacja, a zwykle dodatkowo lepsza pozycja w wyszukiwarkach i większa dostępność strony - np. dla osób niewidomych.

W dokumentach używaj tylko tyle znaczników i atrybutów, ile faktycznie jest niezbędne

Nie ma sensu robić bałaganu i dodawać znaczników na zapas, bo może kiedyś się przydadzą. Jeśli w przyszłości faktycznie będą potrzebne, wtedy po prostu je dodasz. W krótszym kodzie łatwiej jest się połapać, a przy tym strona będzie szybciej się ładować i renderować.

Nie używaj pustych elementów (znaczników)

Przeznaczeniem większości znaczników jest oznaczanie jakichś elementów. Tylko nielicznymi wyjątkami są znaczniki puste - jak np. img. Używanie znaczników niezgodnie z ich przeznaczeniem jest niepoprawne semantycznie. Jeśli potrzebujesz wprowadzić dodatkowy znacznik w celu odpowiedniego wystylizowania wyglądu, zamiast dodawać pusty element, obejmij nim ten fragment kodu źródłowego, któremu chcesz zmienić wygląd.

Nie dodawaj na stronie tekstu tylko po to, żeby go ukryć bez żadnego zamiennika

Takie działanie może zmylić osoby niewidome, używające syntezatorów mowy. Może również pociągać za sobą poważne negatywne konsekwencje, jeśli chodzi o pozycję strony w wyszukiwarkach sieciowych. W skrajnym przypadku strona można zostać zupełnie usunięta z wyszukiwarki!

Staraj się używać identyfikatorów tylko dla elementów szkieletu strony oraz etykiet odsyłaczy

Nawet jeśli w tej chwili chwili wydaje Ci się, że dany element będzie występował w dokumencie tylko raz, nie masz pewności, czy w przyszłości to założenie się nie zmieni. Nawet menu może przecież zostać powtórzone na dole strony, aby ułatwić nawigację użytkownikowi. Elementy szkieletu (np. nagłówek, stopka, główna sekcja, kolumna kontekstowa) nie stanowią natomiast reużywalnych elementów tylko pojemniki na inne elementy, a więc dla nich jak najbardziej należy używać identyfikatorów, a nie klas CSS.

Nie używaj znaczników br do tworzenia akapitów ani ustawiania elementów jeden pod drugim

Do tworzenia akapitów został przeznaczony specjalny znacznik - p. Do ustawiania elementów jeden pod drugim służy znacznik div. Używając do tego celu - niepoprawnie - znacznika br, nie tylko tworzysz niesemantyczny kod, ale również utrudniasz sobie późniejszą stylizację (np. ustalenie wysokości marginesu między sąsiednimi elementami).

Nie stosuj encji   do robienia wcięć ani odstępów pomiędzy wyrazami

Jeśli to zrobisz, nie będzie możliwości sterowania szerokością takich wcięć czy odstępów. Do ustalania wcięć używaj własności CSS text-indent, a do odstępów - margin albo padding.

Nie nadużywaj znacznika div ani span

Do stylizacji możesz przecież wykorzystać znaczniki semantyczne, które już znajdują się w kodzie źródłowym - wstaw jeden element div, będący pojemnikiem całego obiektu, a potem korzystaj z selektora potomka w celu wystylizowania elementów, które zawiera obiekt. Wstawianie zbędnych znaczników nie tylko zaciemnia kod, ale również wydłuża czas ładowania strony.

Formatuj kod źródłowy

Kod zawierający znaczniki z dodanymi wcięciami - zgodnie z poziomem ich zagnieżdżenia w drzewie dokumentu - jest czytelniejszy, a dzięki temu mniej podatny na błędy (od razu zauważysz ewentualny źle domknięty znacznik). Porównaj:

<div class="menu">
	<ul>
		<li>
			<a href="...">...</a>
		</li>
		<li>
			<a href="...">...</a>
		</li>
		<li>
			<a href="...">...</a>
		</li>
	</ul>
</div>

oraz

<div class="menu"><ul><li>
<a href="...">...</a>
	</li>
		<li>
<a href="...">...</a></li>
	<li><a href="...">...</a>
</li>
	</ul></div>

Co prawda wcięcia zwiększają rozmiary dokumentu, wydłużając nieco czas ładowania strony, ale zawsze możesz pójść na jakiś kompromis - np. zrezygnować z tych oczywistych wcięć (wiadomo że bezpośrednio w ul musi zawierać sie li).

Staraj się używać znacznika button zamiast input

Ułatwi Ci to późniejszą stylizację wyglądu oraz umożliwi bezproblemowe zastosowanie techniki zamiennika obrazkowego.

Dziel obszerne artykuły na osobne podstrony

Rozbudowane artykuły długo się ładują. Użytkownik po prostu może się szybko zniecierpliwić i w ogóle nie doczekać się, aż zobaczy pełną zwartość strony, tylko opuścić serwis. Poza tym przecież może wcale nie być zainteresowany całością artykułu, a jedynie jego fragmentem. Dlatego obszerne treści staraj się dzielić na podrozdziały albo w ostateczności na numerowane strony i umieszczać w osobnych dokumentach.

Nie zakładaj, że wszyscy użytkownicy posiadają tak szybkie łącze jak Twoje

Zgoda że dzisiaj już praktycznie nikt nie korzysta z dawnych modemów telefonicznych. Ale coraz popularniejszy staje się internet mobilny. Jego jakość w dużej mierze zależy od siły sygnału, a więc na słabo zaludnionych obszarach prędkość transmisji może być bardzo niska. Może to oznaczać, że strona przesadnie przeładowana grafiką, dynamicznymi skryptami i innymi multimediami będzie się ładować tak powoli, że użytkownik nie mogąc się doczekać, najzwyczajniej w świecie ją wyłączy :-(

Sprawdzaj poprawność składni HTML

Każda przeglądarka stara się w jakiś sposób zinterpretować i naprawiać błędy w kodzie źródłowym, które popełnił twórca strony. Nie ma jednak żadnej gwarancji, w jaki sposób zostanie to zrobione. Skutkiem tego mogą być błędy wyświetlania się strony w różnych przeglądarkach. W skrajnym przypadku strona może się w ogóle nie wyświetlić. Dlatego zaleca się sprawdzać poprawność składni każdego dokumentu, przed opublikowaniem go w sieci. Można do tego użyć specjalnego darmowego narzędzia dostarczonego przez organizację W3C: Markup Validation Service.

Dobre praktyki CSS

Nie używaj atrybutu style="..."

Te same deklaracje porozrzucane w wielu miejscach różnych dokumentów HTML znacznie utrudnią późniejsze wprowadzanie zmian, a także wydłużają czas ładowania strony. Poza tym utrudniają stosowanie standardowych zasad kaskadowości stylów oraz szczegółowości selektorów.

Unikaj stosowania deklaracji !important

Zaburzasz w ten sposób zasady kaskadowości, narażając się na nieoczekiwane problemy przy definiowaniu kolejnych reguł stylów w arkuszu CSS. Co zrobisz, jeśli deklaracja już zawiera !important, a będzie trzeba ją nadpisać? Przecież nie da się zrobić podwójnego !important. Tendencję do korzystania z tej metody mają zwłaszcza osoby, które nie znają zasad szczegółowości selektorów. Przyswojenie sobie tych kilku prostych i intuicyjnych punktów naprawdę nie jest trudne. Postaraj się to zrobić, a prawdopodobnie zupełnie zapomnisz o istnieniu deklaracji !important :-)

Nie wstawiaj wewnętrznego arkusza stylów, który powtarza się na kilku podstronach

W takim przypadku należy rozpatrzyć przeniesienie deklaracji do zewnętrznego arkusza. Pamiętaj, że wspólny plik *.css załaduje się tylko raz - przy pierwszym wejściu użytkownika na stronę - a potem będzie odczytany z pamięci podręcznej przeglądarki. Dzięki temu strony będą ładować się szybciej. Poza tym ułatwi Ci to dokonywanie zmian w wyglądzie serwisu, ponieważ nie będzie już potrzeby szukania wielu dokumentów, w których był wstawiony taki sam wewnętrzny arkusz CSS.

Minimalizuj liczbę osobnych plików arkuszy CSS

Każdy plik wymaga osobnego zapytania HTTP, a to znacząco wydłuża ogólny czas potrzebny na wczytanie strony. Nawet jeśli masz w serwisie kilka różniących się wizualnie podstron, często korzystniej będzie umieścić wszystkie style w jednym pliku i załadować za jednym razem. Kiedy użytkownik odwiedzi inną podstronę, wszystkie wymagane na niej style będzie już miał zapisane w pamięci podręcznej przeglądarki.

Unikaj importowania arkuszy stylów

• Niepotrzebnie wprowadza to dwie odmienne składnie do ładowania tych samych rzeczy.
• Wczytanie zwykłych zewnętrznych arkuszy stylów prawie zawsze jest szybsze, gdyż umożliwia równoległe pobieranie plików.
• Importowanie nie gwarantuje ustalonej kolejności pobierania plików.

Wersjonuj pliki *.css i pliki graficzne w nich zawarte

Pliki zewnętrznych arkuszy stylów oraz grafiki doskonale cache'ują się w przeglądarkach. Oznacza to, że jeśli użytkownik raz wejdzie na Twoją stronę, to kolejnym razem arkusz CSS prawdopodobnie w ogóle nie będzie pobierany z serwera tylko z pamięci podręcznej przeglądarki. Istnieją jednak przypadki, kiedy chcesz wymusić załadowanie nowej wersji pliku, ponieważ zaszły w nim zmiany. Samo wprowadzenie na serwer zmian w istniejącym pliku *.css nie wystarczy, ponieważ użytkownicy wciąż będą dostawać starą jego wersję, zapisaną wcześniej w pamięci podręcznej przeglądarki. Jeśli dodatkowo zmiany dotyczyły również kodu HTML, mamy gotowy przepis na zupełne rozsypanie się wyglądu strony. Ponieważ pliki *.html zwykle cache'ują się słabiej (na krótszy czas), może dojść do sytuacji, kiedy użytkownicy dostaną już nową wersję kodu źródłowego HTML, która wymaga jednak zmienionego właśnie arkusza CSS, ale sam arkusz zaczyta się stary - z pamięci podręcznej przeglądarki.

Aby do tego nie dopuścić, zawsze można wprowadzić na serwer po prostu nowy plik *.css i zmienić jego nazwę we wszystkich odwołaniach występujących w plikach *.html. Tak naprawdę sposób ten jest najbardziej pewny. Niestety po jakimś czasie na serwerze może zebrać się cała masa starych, już dawno niepotrzebnych plików. Nie można ich usuwać od razu, ponieważ część użytkowników przez jakiś czas może ich jeszcze potrzebować, dopóki będą dostawać poprzednie wersje plików *.html - z pamięci podręcznej przeglądarki. Dlatego często stosuje się inną metodę. Zmiany można wprowadzać w tych samych plikach *.css, a w adresach do nich (występujących w plikach *.html) dodać po pytajniku numer kolejnej wersji (albo aktualną datę), np.:

<link rel="stylesheet" href="style.css?2">

To samo dotyczy wszystkich odwołań do plików graficznych, występujących arkuszu CSS - jeśli uległy zmianie, należy podnieść im numer rewizji:

background-image: url("plik.gif?2");

Gdzie to tylko możliwe, staraj się skracać zapis w regułach stylów

Oszczędzisz sobie w ten sposób pisania, a także zmniejszasz rozmiar arkusza CSS, co przyspiesza ładowanie strony.

• Używaj atrybutów mieszanych - np. margin zamiast zestawu: margin-top, margin-right, margin-bottom, margin-left.
• Nie dopisuj jednostki do wartości zero, ponieważ nie jest tam wymagana. Zero to zawsze zero - bez względu w jakich jednostkach.
• Jeśli nie jest to konieczne, nie łącz selektora typu z innymi. Zamiast div.klasa powinno wystarczyć samo .klasa, chyba że faktycznie zależy Ci na tym, aby zastosować odrębną stylizację dla div.klasa, a inną np. dla form.klasa. Poza tym im ogólniejszy selektor, tym jest on bardziej uniwersalny, a więc ma więcej potencjalnych zastosowań.
• Nie używaj selektora uniwersalnego w połączeniu z innymi selektorami oprócz selektorów elementów. Selektor *.klasa działa tak samo jak .klasa, więc nie warto dodawać zbędnych znaków.
• W selektorach potomka nie musisz podawać pełnej ścieżki dziedziczenia. Wybierz tylko te elementy, które są istotne z punktu widzenia definiowanych stylów.
• Jeśli wygląd linków odwiedzonych nie różni się od nieodwiedzonych, to w ogóle nie używaj pseudoklas :link ani :visited (tylko po prostu selektora a), ponieważ niepotrzebnie wydłuża to zapis, a poza tym często pociąga za sobą konieczność wpisywania ich potem w wielu innych miejscach arkusza CSS. Jeśli już używasz tych pseudoklas, wstawiaj je we właściwej kolejności.

Minimalizuj liczbę identyfikatorów i klas CSS

Pozwoli to na łatwiejsze zarządzanie arkuszem CSS (prościej jest pamiętać jedną nazwę klasy niż kilkanaście jej odmian) oraz zmniejszy prawdopodobieństwo powstania konfliktów nazw i związanej z tym konieczności wymyślania kolejnej, nowej nazwy, kiedy już skończyły nam się wszystkie pomysły. W tym celu możesz nadać jedną klasę blokowi pełniącemu rolę pojemnika na elementy innych typów, a dalej korzystać np. z selektorów potomka:

.pojemnik p { /* ... */ }
.pojemnik p em { /* ... */ }

Jeśli to ma sens, korzystaj z kontekstu selektorów. Klasa CSS o nazwie informacja może zawierać inne deklaracje stylu, gdy zostanie przypisana do div, a inne gdy do span, ale znaczeniowo przecież oba elementy będą jakimś rodzajem informacji, więc nie ma sensu tworzyć osobnych klas informacja_blok i informacja_tekst:

div.informacja { /* informacja_blok */ }
span.informacja { /* informacja_tekst */ }

Jednak nie używaj tej techniki dla klas, które mają bardzo ogólne przeznaczenie, aby nie doprowadzić do takich zapisów:

a.informacja, abbr.informacja, abbr.informacja,
b.informacja, big.informacja, cite.informacja,
dfn.informacja, em.informacja, i.informacja, q.informacja,
small.informacja, span.informacja, strong.informacja {
	/* To nie jest zbyt dobry pomysł! */
}

Ustalając tło upewnij się, że element ma przypisany (lub odziedziczony) kolor tekstu (i odwrotnie)

Nie możesz zakładać, że domyślny kolor tła strony to biały, bo użytkownik może to zmienić w ustawieniach wyglądu swojego systemu operacyjnego. Głupio by było, aby na Twojej stronie pojawił się czarny tekst na czarnym tle, prawda? :-)

Ustal w jednym miejscu globalne style formatowania tekstu

Najlepiej użyć do tego selektora body albo html. Dzięki dziedziczeniu styl przeniesie się na pozostałe elementy dokumentu. Nie rób tego z użyciem samodzielnego selektora uniwersalnego, gdyż omija on dziedziczenie i może w ten sposób doprowadzić do niezrozumiałych zachowań przy definiowaniu kolejnych reguł stylów w arkuszu, a także wydłużyć czas potrzebny na wyrenderowanie strony.

Dzięki przypisaniu globalnych stylów, nie będzie trzeba tego robić być może nawet dla kilkudziesięciu osobnych elementów, a więc rozmiar pliku arkusza CSS będzie mniejszy, co przyspieszy ładowanie strony. Ponadto jeśli w przyszłości zechcesz zmienić np. wiodący kolor tekstu w serwisie, będzie wystarczyło wykonać to tylko w jednym miejscu, a nie w wielu porozrzucanych po całym arkuszu deklaracjach. Najczęściej ustalanymi globalnie własnościami formatowania tekstu są: background, color, font.

Używaj właściwych jednostek do ustawiania rozmiaru tekstu

Do określania wartości font-size na ekranie najkorzystniej jest używać jednostki px (a nie em ani %), a na wydruku - pt. Z uzasadnieniem możesz się zapoznać w punkcie: Najlepszy sposób ustalania wielkości czcionki.

Ustalaj rodzaj czcionki zawsze wspólnie z jej wielkością (i odwrotnie)

Pamiętaj, że czytelność tekstu w dużej mierze zależy od proporcji wysokości małej litery do dużej. W różnych fontach wartości te mogą być inne. 10-pikselowy tekst napisany czcionką Verdana być może będzie jeszcze czytelny, ale w przypadku Times New Roman już raczej nie. Nie opieraj się na założeniu, że w większości popularnych przeglądarek domyślny rozmiar czcionki wynosi 16px. Użytkownik zawsze może zmienić tę wartość w ustawieniach programu. Może się ona różnić np. w systemie Linux - z powodu niedostępności tam popularnych fontów, związanej z ich komercyjnym licencjonowaniem. A jaki będzie domyślny rozmiar tekstu na smartfonie czy tablecie - wszędzie 16px? To prawda, że domyślny rozmiar tekstu najczęściej jest równocześnie najlepiej czytelny na danym urządzeniu, ale tylko dla domyślnego rodzaju czcionki. Jeśli zmieniasz krój czcionki, domyślny rozmiar tekstu w urządzeniu może być dla niej za mały.

Ustalanie rodzaju czcionki zawsze kończ podając nazwę rodziny ogólnej

Jeśli wydaje Ci się, że każdy ma w swoim systemie operacyjny font Verdana, Arial czy Times New Roman, to masz rację - wydaje Ci się ;-) Przyjmij do wiadomości, że np. posiadacze wielu dystrybucji Linuksa standardowo nie mają takich czcionek, ponieważ są one licencjonowane. Nie masz absolutnie żadnej pewności co do konfiguracji systemu operacyjnego użytkownika. Dlatego właśnie używanie ogólnych rodzin czcionek (takich jak np. sans-serif, serif, monospace) na końcu deklaracji font-family może zapewnić, że tekst wyświetli się przynajmniej w podobny sposób.

Tekst musi być czytelny

Co z tego, że być może Twoim zdaniem miniaturowa czcionka wygląda niezwykle efektownie, skoro tak mały tekst będzie bardzo trudny do odczytania nawet przez użytkowników z dobrym wzrokiem, nie mówiąc o osobach niedowidzących. Spróbuj choć raz spojrzeć na swój serwis oczami Twoich gości, a przekonasz się, że dłuższe czytanie obszerniejszych artykułów w ten sposób jest niezwykle męczące. Nie każdy będzie miał ochotę albo po prostu nie będzie potrafił powiększyć tekstu w swojej przeglądarce, tylko po prosu poszuka sobie w sieci innej strony o tej tej samej tematyce.

Kolor tekstu musi wyraźnie kontrastować z tłem. Może wydaje Ci się, że ciemnoszary tekst na czarnym tle idealnie się komponuje, ale naprawdę fatalnie się go czyta. Nie zmuszaj użytkowników do zaznaczania treści na stronie tylko po to, żeby w ogóle dało się ją odczytać, bo nie każdy może być tak pomysłowy. Pamiętaj również o doborze takich kolorów, które nie będą męczyć wzroku. Jaskrawe barwy zdecydowanie nie są polecane. Opublikowanie strony po prostu z czarnym tekstem na białym tle to naprawdę nie jest wstyd :-) Jeśli już musisz wstawić tło obrazkowe pod tekstem, unikaj grafik zawierających mocno kontrastujące obszary koloru lub ostre krawędzie.

Staraj się nie wstawiać tekstu w zbyt szeroką kolumnę, gdyż jest to niewygodne w czytaniu. Przy przenoszeniu wzroku z końca jednej linijki na początek następnej, można wtedy łatwo się pogubić. Pamiętaj, że coraz popularniejsze są monitory panoramiczne, na których Twoja strona może być bardzo szeroka, a więc pomyśl o ustaleniu jakiejś stałej lub przynajmniej maksymalnej szerokości układu strony w przeglądarce.

Rozważ zwiększenie wysokości linii, ponieważ standardowa wartość może być zbyt mała.

Nie zmuszaj czytelników do szukania odnośników

W przypadku linków umieszczonych w treści artykułów zadbaj, aby dobrze się odróżniały od otaczającego je zwykłego tekstu. Nie każ użytkownikom chodzić po Twojej stronie z kursorem myszki jak z wykrywaczem metali - aż nad którymś wyrazem zobaczą znajomy kursor np. łapki ;-) Dobrze jest, jeśli link różni się nie tylko kolorem, ale jeszcze przynajmniej jednym innym sposobem formatowania - np. posiada podkreślenie. Osoby cierpiące na daltonizm, mogą mieć problem z odróżnieniem kolorów. Poza tym mało odróżniający się kolor może być ciężki do zauważenia nawet dla osób z doskonałym wzrokiem, a zupełnie niemożliwy na ekranie czarno-białym.

Rozważ używanie techniki "duszków" CSS (and. CSS sprites)

Mniej zaptań HTTP oznacza szybsze ładowanie strony i mniejszy transfer z serwera (tańszy hosting dla Twojego serwisu).

Nie stosuj trybu Quirks na nowo tworzonych stronach

Został on obmyślony w celu utrzymania kompatybilności na starych stronach, które były nieprawidłowo napisane. Zachowanie przeglądarek w trybie Quirks nie jest identyczne, co może powodować wiele problemów.

Nie powtarzaj kodu (zasada DRY - ang. Don't Repeat Yourself)

Zanim dodasz kolejną regułę stylów, sprawdź czy nie ma już takiej, która robi dokładnie to, czego potrzebujesz. Jeżeli została już wcześniej zdefiniowana bardzo podobna, ale jednak nie do końca identyczna reguła stylów, rozważ jej ujednolicenie. Kopiując fragmenty deklaracji utrudniasz sobie zarządzanie zmianami w przyszłości (modyfikacji będzie trzeba dokonywać w wielu miejscach porozrzucanych po całym arkuszu CSS) i sprawiasz, że strona będzie dłużej się ładować użytkownikom.

Stosuj technikę CSS Zorientowanych Obiektowo

Dzięki temu nie pogubisz się w obszernym arkuszu stylów oraz zapobiegniesz niekontrolowanemu powtarzaniu kodu, ułatwiając sobie tym samym rozwój serwisu w przyszłości.

Staraj się tak stylizować obiekty na stronie, aby automatycznie dopasowywały się do szerokości bloku pojemnika

Dzięki temu, przy zmianie szerokości kolumny lub przenoszeniu obiektów w inne miejsce, nie będzie zachodzić potrzeba odzielnego przestylizowania być może nawet kilkudziesięciu elementów strony.

Używaj klas kontekstu układu strony dla elementu body

Załóżmy, że standardowo Twój serwis zawiera kolumnę menu kontekstowego. Jednak w kilku dokumentach wymagany jest szerszy układ strony - bez kolumny menu. Nie ma sensu w takim przypadku kopiować całego arkusza CSS, aby tylko zmienić ten układ. Znacznie lepiej przypisać na tych nielicznych podstronach do elementu body specjalną klasę CSS, która dzięki zastosowaniu selektora potomka, zmieni układ strony.

Ponieważ element body jest zawsze pojedynczy w każdym dokumencie, może istnieć pokusa, aby zamiast klasy CSS, użyć identyfikatora. Wtedy jednak utracimy możliwość rozszerzania klas. Możemy mieć przecież kilka układów stron bardzo do siebie podobnych, a więc taka możliwość okaże się bardzo przydatna.

Staraj się unikać bardzo mocnego stylizowania kontrolek formularzy

Wśród grafików czasem panuje przekonanie, że standardowy wygląd formularzy jest brzydki. Pamiętaj jednak, że mimo wszystko użytkownik jest przyzwyczajony właśnie do takiego ich wyglądu, ponieważ ma z nim do czynienia na co dzień w swoim systemie operacyjnym. Może się poczuć zdezorientowany, kiedy zobaczy na tyle nietypowy wygląd bardzo mocno ostylizowanej kontrolki, że na pierwszy rzut oka nie skojarzy jej z żadnym znanym mu dotąd standardowym polem formularza, przez co nie dotrze do ważnych części serwisu. Przykładowo w wielu systemach operacyjnych normalnie przyciski są ukazywane jako wypukłe, a pola tekstowe - wklęsłe. Masz pewność, że użytkownik domyśli się do czego służą, jeśli ostylizujesz je na odwrót?

Powstaje zatem pytanie, czy w ogóle zmieniać wygląd pól formularzy? Użytkownicy już raczej przyzwyczaili się, że na stronach WWW niektóre kontrolki często mają zmieniony wygląd: przyciski (w tym wysłania formularza i wyczyszczenia danych), pola tekstowe (w tym hasło) oraz obszary tekstowe. O ile zatem zmieniony przycisk faktycznie będzie przypominał coś, w co można kliknąć, a pole tekstowe - kontrolkę w którą można wpisać treść, wydaje się, że lekka stylizacja w większości przypadków nie powinna im zaszkodzić. Zalecam jednak uważać na listy rozwijalne i selektory plików, gdyż niektóre przeglądarki nie dają pełnych możliwości zmiany ich wyglądu, co może wywołać nieestetyczny wygląd. Pól wyboru ani opcji lepiej w ogóle nie ruszać (poza ustaleniem marginesów czy położenia).

Ustal spójny sposób nazywania klas CSS oraz identyfikatorów

• Nazwy powinny być rzeczownikami, zwykle w liczbie pojedynczej (chyba że dotyczą listy elementów).
• Nazwa musi odzwierciedlać przeznaczenie, a nie sposób formatowania elementów. Co zrobisz, jeśli na początku zdefiniujesz klasę class="czerwony_tekst", a za jakiś czas stworzysz drugą skórkę dla serwisu, w której element ten będzie miał kolor zielony?
• Klasy ani identyfikatory nie powinny zawierać w sobie nazwy znacznika, dla którego pierwotnie zostały przeznaczone, ponieważ wywoła to spore zamieszanie, gdy będzie trzeba przypisać taką klasę do innego znacznika (czyli zamiast .container_div użyj po prostu div.container).
• Klasy ani identyfikatory nie powinny zawierać w sobie nazwy sekcji na stronie, w której pierwotnie dany element był osadzony, ponieważ w przyszłości może to ulegać zmianom. Trochę dziwnie będzie wyglądał obiekt nawigacja_naglowkowa, jeśli zaistnieje potrzeba przeniesienia go do stopki ;-)
• Klasy i identyfikatory powinny być intuicyjne, tak aby po samej nazwie można się było szybko zorientować, do czego służą. Oczywiście nikt nie zabroni Ci zdefiniować class="azx323434_bg4532" albo class="c", ale czy jutro na pewno będziesz pamiętać, do czego była przeznaczona taka klasa, a nawet jeśli tak, to czy inne osoby współtworzące serwis nie będą miały z tym kłopotów?
• Tworzenie kolejnych nazw poprzez numerację, gdy nie możesz już wymyślić nic sensownego (np. informacja2, informacja3, informacja4 itd.) to kiepski pomysł. Czy za pół roku będziesz pamiętać, czym różni się informacja2 od informacja3?
• Jeśli serwis nie będzie posiadał wersji obcojęzycznej ani nie planujesz, że będą go rozwijać osoby z innych krajów, możesz używać polskojęzycznych nazw (bez polskich znaków diakrytycznych!). Jeśli wygodniej Ci będzie używać angielskich - również nie ma problemu. Ważne, żeby starać się nie mieszać nazw polskich i angielskich, a już najgorsze co można zrobić, to tworzyć pojedyncze nazwy jednocześnie w dwóch językach, np. class="wazny_text". Wyjątkiem od tej reguły mogą być tylko identyfikatory używane w etykietach odsyłaczy. Ponieważ mogą pojawić się w pasku adresu przeglądarki, powinny być w takim samym języku jak treść strony. Dodatkowo zaleca się, aby nazwy tych etykiet zawierały tylko małe litery alfabetu łacińskiego (bez polskich znaków diakrytycznych), cyfry oraz ewentualnie znaki podkreślnika. Natomiast jako separatora wyrazów można używać znaku minusa.
• Istnieje wiele sposobów tworzenia kilkuczłonowych nazw, np.: class="nazwa_klasy" (prawdopodobnie najczęściej stosowane), class="nazwaklasy" (raczej mało czytelne), class="nazwa-klasy", class="NazwaKlasy" (często stosowane w językach programowania zorientowanych obiektowo), class="nazwaKlasy". Zdecyduj się na jeden wariant i stosuj go konsekwentnie.

Ustal jednolity sposób formatowania reguł w arkuszach stylów

Poukładany kod lepiej się czyta, a przez to jest mniej podatny na niezauważone błędy. Staraj się poprawnie oddzielać spacjami znaki interpunkcyjne zawarte w składni CSS - "zbity" kod co prawda nieco szybciej się ładuje, ale jest znacznie mniej czytelny. Popularne warianty (zdecyduj się na jeden):

html, body {
	color: black;
	background-color: white;
}

html, body
{
	color: black;
	background-color: white;
}

html, body { color: black; background-color: white; }

Nie zakładaj, że wszyscy użytkownicy posiadają tak duży ekran jak w Twoim monitorze

Dostęp do sieci z rożnego typu urządzeń mobilnych staje się dzisiaj tak samo ważny, jak z komputerów stacjonarnych czy tradycyjnych laptopów. Chyba trudno się spodziewać, że ekran telefonu komórkowego pomieści tyle samo, co wielki, stacjonarny monitor panoramiczny. Dobrym rozwiązaniem tego problemu są osobne arkusze dla urządzeń przenośnych, a jeszcze lepiej zapytania mediów.

Sprawdzaj poprawność wyświetlania się strony w popularnych przeglądarkach

To świetnie, że Twoim zdaniem przeglądarka, której używasz, jest najszybsza, najnowocześniejsza, najbezpieczniejsza, najwygodniejsza i w ogóle wszystkie możliwe "naj" :-) Niestety istnieją ludzie, którym jeszcze nie została objawiona ta prawda, a więc wciąż uparcie korzystają z innych przeglądarek ;-) Dlatego przed opublikowanie strony w sieci sprawdź, czy aby Twój przepięknie wyglądający serwis nie rozsypuje się zupełnie, wyświetlony w innej przeglądarce niż Twoja.

Umieszczanie na stronie ostrzeżeń w stylu: "Ta strona jest przystosowania dla przeglądarki..." jest szczytem arogancji webmastera. Jeśli w ten sposób traktujesz swoich potencjalnych czytelników, jak myślisz, po ilu sekundach bezpowrotnie opuszczą Twój "wspaniały" serwis, zirytowani Twoją nieodpowiedzialną postawą?

Sprawdzaj poprawność składni CSS

Skutkiem błędów, popełnionych przy tworzeniu arkuszy CSS, mogą być nieestetyczne różnice sposobu wyświetlania strony w poszczególnych przeglądarkach. Dlatego zaleca się sprawdzać poprawność składni każdego arkusza stylów, przed opublikowaniem strony w sieci. Można do tego użyć specjalnego darmowego narzędzia dostarczonego przez organizację W3C: CSS Validation Service.

Dobre praktyki skryptów

Kluczowe funkcjonalności serwisu powinny być dostępne bez JavaScript

Poza niektórymi wyjątkami (np. rozbudowane aplikacje WWW, które bez JavaScript nie mają sensu), wszelkie dynamiczne skrypty powinny być tylko dodatkiem do strony. Jeżeli po wyłączeniu obsługi dynamicznych skryptów w przeglądarce, główna zawartość Twojej strony jest niedostępna albo są problemy z menu nawigacyjnym, to znak, że coś jest mocno nie tak. Taka strona może być zupełnie niedostępna dla osób niewidomych. Ponadto w skrajnym przypadku Twoja strona może być przez to nawet praktycznie zupełnie nieobecna w wynikach wyszukiwarek sieciowych.

Znacznik noscript nie stanowi rozwiązania wszystkich problemów. Jeżeli wstawiasz do niego cała alternatywną zawartość na wypadek niedostępności JavaScript (technika z ang. Graceful Degradation), zwykle wydatnie powiększasz rozmiary strony, wydłużając tym samym czas potrzebny na jej załadowanie. Najczęściej korzystniej będzie "doczepić" dodatkowe dynamiczne funkcjonalności do istniejącego kodu HTML (technika z ang. Progressive Enhancement) - jeśli przeglądarka nie obsługuje JavaScript, po prostu wyświetli sam statyczny kod.

Nie stosuj bez potrzeby dynamicznych zamienników kontrolek formularzy

Zdarza się, że poczucie estetyki niektórych grafików tak bardzo cierpi na widok standardowego wyglądu pól formularzy na stronie, że nie wystarcza im już nawet mocna stylizacja kontrolek przy pomocy CSS. Jedynym ratunkiem wydaje się wtedy wykorzystanie jakiejś wtyczki do popularnych frameworków JavaScript, dzięki której zamiast tradycyjnych pól - zwłaszcza listy rozwijalnej albo pola wyboru bądź opcji - osadzane są dynamiczne komponenty, całkowicie kontrolowane za pomocą skryptu. Takie działanie jest jednak uzasadnione wyłącznie w przypadkach, kiedy standardowe kontrolki nie udostępniają jakichś ważnych funkcjonalności, na których nam zależy. Na przykład tradycyjne pole kombi nie pozwala wyświetlać w sobie obrazków ani dowolnie formatować fragmentów tekstu, a przełączniki wyboru w większości przeglądarek są tylko dwustanowe.

Jednak używanie dynamicznych zamienników tylko dlatego, że nie podoba się nam ich standardowy wygląd, jest działaniem nieodpowiedzialnym. Taka kontrolka w niektórych przeglądarkach może nie wyglądać estetycznie, ale również nie działać prawidłowo. Dość prawdopodobne, że nie będzie w ogóle działać na urządzeniach mobilnych lub jej używanie będzie istnym koszmarem. Zwykle jest znacznie gorzej dostępna dla osób niewidomych. Poza tym najczęściej nie obsługuje ona pełnej funkcjonalności udostępnianej dla jej standardowej wersji w systemie operacyjnym użytkownika. Często pojawiają się np. problemy z zamiennikiem listy rozwijalnej przy obsłudze rolki myszki czy klawiatury, przez co na dłuższą metę używanie takiej kontrolki staje się po prostu bardzo niewygodne. Fantazyjny wygląd ani efektowne animacje tego raczej nie zrekompensują. Najgorsze jest jednak to, że takie dynamiczne zamienniki mogą tak bardzo różnić się wyglądem i sposobem działania od standardowych pól formularzy, że użytkownik może w ogóle nie zwrócić na nie uwagi jako na elementy interaktywne albo nie zrozumieć ich działania, przez co opuści serwis lub nigdy nie dotrze do jego ważnych części.

Przykładem niezrozumienia może być dynamiczny zamiennik tradycyjnego pola wyboru, w postaci małego poziomego przełącznika, podobnego do suwaka. Użytkownicy mogą próbować przeciągać suwak zamiast po prostu w niego kliknąć albo w ogóle nie zrozumieją jego działania, ponieważ suwak kojarzy im się raczej z czymś innym. Jeśli nie uda im się przestawić pozycji takiego przełącznika, porzucą wypełnianie formularza, myśląc, że nie działa.

Unikaj stosowania atrybutów zdarzeń

Nowoczesne biblioteki języków skryptowych pozwalają przypisywać zdarzenia z poziomu samego kodu skryptu (technika z ang. Unobtrusive JavaScript). Dzięki temu zarządzasz nimi z jednego miejsca (co ułatwi wprowadzanie zmian) i nie zaśmiecasz samego kodu HTML.

Unikaj bezpośredniej zmiany własności stylów za pomocą JavaScript

W samej dynamicznej zmianie wyglądu elementów przy pomocy skryptów nie ma niczego złego. Pamiętaj jednak, że arkusz CSS powinien być jedynym miejscem, gdzie określa się wygląd strony. Oznacza to, że z poziomu JavaScript najczęściej korzystniej jest dynamicznie zmienić nazwę klasy elementu, a nie wybrane własności stylów. Wyjątkami od tej reguły są:

• ukrywanie elementu - nie ma sensu tworzyć klasy CSS, której jedynym zdaniem jest schowanie elementu
• animacje - ponieważ zmiana wartości własności stylów odbywa się w sposób płynny, utworzenie tak wielu osobnych klas CSS mijałoby się z celem

Minimalizuj liczbę osobnych plików *.js

Każdy plik wymaga osobnego zapytania HTTP, a to znacząco wydłuża ogólny czas potrzebny na wczytanie strony. Zawsze możesz połączyć wszystkie bądź większość skryptów w jednym lub kilku plikach.

Wersjonuj pliki *.js

Pliki z kodem JavaScript zwykle cache'ują się tak samo dobrze, jak zewnętrzne arkusze stylów. W związku z tym po wprowadzeniu w nich zmian, nie wystarczy po prostu wysłać je na serwer pod dotychczasową nazwą, ale konieczna jest dodatkowo zmiana adresu odwołań do nich, występujących we wszystkich plikach *.html:

<script src="plik.js?2"></script>

Nie zakładaj, że każdy posiada tak wydajny komputer jak Twój

Pomijając już bardzo stare komputery, których właściciele nie wymieniają, bo się na tym nie znają albo po prostu bo nadal działają, zastanów się przez chwilę, jak płynnie będzie działać Twoja strona, przeładowana niepotrzebnymi dynamicznymi skryptami, na zwykłym telefonie komórkowym? Czy w ogóle będzie się dało z niej korzystać?

Unikaj stosowania technologii Flash, a zwłaszcza appletów Java

Obie te technologie (nie mylić z JavaScript, którego umiejętne stosowanie jest zupełnie bezpieczne) nie są wystarczająco dostępne. Utrudniają odbiór strony przez osoby niewidome oraz wyszukiwarki sieciowe. Wiele urządzeń przenośnych w ogóle nie potrafi ich obsługiwać. Poza tym często wymagają bardzo wydajnego komputera. Zapewniam Cię, że dla użytkownika telefonu komórkowego, tabletu albo osoby niewidomej znacznie ważniejsze jest po prostu odczytanie treści niż obejrzenie wymyślnych animacji na Twojej stronie.