Dlaczego standardy są tak ważne? (cz. 1)

Tak, jak w miarę rozwoju motoryzacji ktoś kiedyś ustalił, że na zielonym jedziemy, a na czerwonym stoimy, tak w miarę rozwoju Internetu z czasem ustalono pewne dobre zasady. A jednak wielu twórców witryn uparcie jedzie na czerwonym, a co gorsza… na zielonym staje. Co jakiś czas zdarza mi się trafić wręcz na takie rodzynki jak np.: „agencja specjalizująca się w tworzeniu stron WWW”, której witryna w całości oparta jest o Flash, a na większości urządzeń, na których ją wyświetlamy, w miejscu strony zieje wielka czarna dziura. Może więc sprawa warta jest podjęcia kolejny raz.

Zwracam się z jednej strony do twórców tego typu witryn, ale przed wszystkim do ich klientów, często nieświadomych zjawiska. Niech to będzie garść podpowiedzi, które być może kiedyś pomogą uchronić się przed konsekwencjami złych wyborów. Oczywiście z punktu widzenia developera powinny to być absolutnie oczywiste kwestie, niech nikt nie poczuje się tym urażony. Jednakże inspiracja do tego wpisu wzięła się niestety z życia. Będzie to więc kilka subiektywnych „grzechów głównych” związanych z witrynami WWW, które mi (jako ich użytkownikowi) wydają się najbardziej uciążliwe, a jednocześnie wciąż niezmiernie popularne. Wyszło tych grzechów trochę, dlatego postanowiłem podzielić ten temat na kilka osobnych wpisów.

#1 Poprawność kodu i zgodność ze standardami W3C

Tylko i aż tyle. Z punktu widzenia developera wydaje mi się, że rutynowa walidacja ukończonej witryny (czy interfejsu aplikacji) przed wypuszczeniem jej w świat nie jest dużą uciążliwością, a czasem pomoże wychwycić drobne potknięcia. Oczywiście, zdarza się, że walidator wskaże nam „błędy”, których jesteśmy świadomi i na które się godzimy. Kluczem jednak jest słowo świadomość – nic, a szczególnie odstępstwa od reguł, nie powinny nigdy dziać się nieświadomie i bez dokładnej znajomości konsekwencji.

Jako klient wierzysz w profesjonalizm wykonawcy i często, chcąc nie chcąc, godzisz się z tym, że „przecież się na tym nie znam, więc jak miałbym to zweryfikować„. Z pewnością nie wszystko jesteś w stanie zweryfikować, ale część rzeczy na pewno. Niektórzy mawiają „wierz, ale sprawdzaj„. A więc sprawdzaj:

1. Wejdź na validator.w3.org, podaj adres (lub wklej źródło) swojej witryny (najlepiej wszystkich lub przynajmniej kilku podstron z osobna). Sprawdź, czy walidator wskaże jakieś błędy lub ostrzeżenia. Jeśli wynik Cię zaniepokoi, skonsultuj to z wykonawcą, lub niezależnym specjalistą. Zgłoś te zastrzeżenia wykonawcy przed odbiorem zamówienia.
2. Analogicznie sprawdź poprawność arkuszy stylów CSS na jigsaw.w3.org/css-validator/. Jeśli nie wiesz jak to zrobić, możesz spróbować np. w ten sposób: Wyświetl źródło swojej strony (w większości przeglądarek po otwarciu strony wystarczy wcisnąć ctrl+u lub kliknąć prawym klawiszem myszy i wybrać „źródło strony„) i znajdź fragmenty kodu, przypominające ten:

   <link rel="stylesheet" href="/style.css" type="text/css"/>

   Kliknij w link stanowiący zawartość atrybutu href i skopiuj adres URL wyświetlonego dokumentu. Wklej go we wspomnianym walidatorze i sprawdź efekty, podobnie jak wcześniej.

3. Otwórz konsolę w swojej przeglądarce i sprawdź, czy w trakcie korzystania z witryny pojawiają się jakieś błędy. Klikaj w elementy, testuj co się da. Jeśli błędy się pojawią – skonsultuj je ze specjalistą. Docelowo żadne błędy nie powinny występować. Jeśli nie wiesz jak uruchomić konsolę w przeglądarce, spróbuj skorzystać z tych kombinacji klawiszy:

• Google Chrome: F12
• Opera: ctrl+shift+c
• Mozilla Firefox: F12
• Internet Explorer: F12

Po co to wszystko? Oczywiście nie po to, żeby uprzykrzać życie developerowi, ale aby uchronić się przed konsekwencjami takich błędów. Niezgodność kodu ze standardami i błędy skryptów mogą powodować nieprawidłowe funkcjonowanie niektórych elementów witryny lub całkowite przerwanie wykonania skryptu. Mają też wpływ choćby na pozycjonowanie Twojego serwisu czy sposób jego wyświetlania w różnych przeglądarkach. Będą więc także wpływać na jego odbiór przez odwiedzających.

#2 Obsługa przez różne przeglądarki

Niestety twórcy przeglądarek internetowych też nie zawsze nadążają z wdrażaniem nowych standardów, a czasem wręcz można odnieść wrażenie, że próbują zrobić na złość światu, szczególnie wówczas, gdy ich przeglądarka jest opatrzona logiem z niebieską literką „e”. W efekcie czasem okazuje się, że to, co działa i wygląda w określony sposób w jednej przeglądarce, nie zachowuje się już tak samo, gdy użyjemy innej. Dlatego, najzwyczajniej w świecie otwórz i „przeklikaj” swój serwis w co najmniej kilku najpopularniejszych przeglądarkach, jak Google Chrome, Mozilla Firefox, Opera, Internet Explorer czy Safari (statystyki dotyczące popularności wiodących przeglądarek znajdziesz choćby tu: www.w3schools.com/browsers/browsers_stats.asp). Strona powinna wszędzie działać i wyglądać tak samo. Jeśli zauważysz jakieś niepokojące różnice – skonsultuj się z wykonawcą, być może coś umknęło jego uwadze.
Bywa jednak też i tak, że ze względu na różnice w interpretacji stylów CSS, czy wykorzystanie różnych silników JavaScript, pewne elementy będą działać odrobinę inaczej w różnych przeglądarkach i jest to nie do uniknięcia. Ważne jednak, aby każdy element serwisu pozostał dostępny i w pełni funkcjonalny bez względu na to, w jakiej przeglądarce zostanie otworzony.

#3 Flash, JS i ciasteczka.

Czyli bądźmy świadomi technologii, których używamy. I nie zapominajmy o tych, którzy w przeciwieństwie do nas z nich nie korzystają. W zaawansowanych aplikacjach webowych można, a czasem nawet trzeba pozwolić sobie na postawienie użytkownikowi pewnych wymagań technicznych. Ale w przypadku zwykłych witryn internetowych, zmuszanie użytkownika do instalowania wtyczek, czy włączania obsługi JavaScript, bo bez tego nie da się… przeczytać artykułu na blogu… jest, dyplomatycznie ujmując, mocno „na wyrost”. Czy użytkownik naszego serwisu będzie wytrwale szukał przyczyny nieprawidłowego działania strony, zmieniał ustawienia przeglądarki i instalował dodatkowe wtyczki, aby wreszcie zobaczyć upragnioną zawartość? A może po prostu ucieknie jak najszybciej i poszuka innej, podobnej, ale działającej witryny? Parafrazując poetę: szanujmy swoich gości, bo szybko odchodzą.
Jeśli zleciłeś wykonanie witryny internetowej, przed jej odbiorem sprawdź, czy po wyłączeniu w przeglądarce obsługi JavaScript, ciasteczek, Flasha (i innych wtyczek jeśli są uruchomione) witryna nadal jest w pełni użyteczna. Powinna! A na koniec wyłącz też obsługę CSS i sprawdź jeszcze raz. Co ryzykujesz, oprócz tego, że niektórzy odwiedzający nie zobaczą Twojego serwisu? Ot, choćby to, że w niektórych przypadkach np. Google może wykluczyć Twoją witrynę ze swojego indeksu. A więc krótko mówiąc nie będzie się jej dało wyszukać. To może zaboleć. W najlepszym przypadku witryna zostanie nisko oceniona (a więc będzie wyświetlana nisko w wynikach wyszukiwania), a niektóre jej treści nie zostaną w ogóle odczytane (a więc nie będzie możliwości ich wyszukania). Jednak przede wszystkim możesz po prostu zniechęcić do siebie osoby odwiedzające Twoją witrynę. Jeśli coś da się wyświetlić bez pomocy wtyczek i skryptów – z zasady tak właśnie powinno być wyświetlane. Developerzy czasem zapominają, że interfejs każdej witryny internetowej, to ostatecznie tekst, ujęty w znaczniki HTML. I każdą powinno dać się do tej prostej postaci sprowadzić. Wszystkie pozostałe rzeczy (style CSS, skrypty JS itd.) to tylko dodatki, których niektórzy użytkownicy nigdy nie zobaczą. Każda witryna powinna w pełni funkcjonować po wyłączeniu obsługi tych elementów, a cała jej treść powinna pozostać dostępna. Oczywiście są rozwiązania, których nie da się w ten sposób zaimplementować, bo zasada ich funkcjonowania z założenia opiera się o skrypty wykonywane po stronie klienta. Mam jednak nadzieję, że ta różnica jest dla każdego oczywista.

Przejdź do części 2 >