Front-end development, a sprawa polska
Ostatnio spędzam sporo czasu oglądając sobie różne serwisy różnych profesjonalnych przysłowiową „pełną gębą” agencji internetowych z wypasionym designem i dużymi korporacjami w portfolio klientów. Nie, żebym szukał pracy, ale czasem po prostu lubię podpatrzeć innych, żeby zobaczyć co mogę poprawić w swojej pracy.
Przeglądam więc czasem fora Goldenline i Profeo, czytam wątki tworzone i rozwijane przez ludzi o tytułach „front-end developer”, gdzie radzą, prawią i mądrzą się w sprawach standardów, semantyki HTML’a i tym podobnych spraw. Potem mam w zwyczaju oglądać serwisy firm oraz klientów ludzi światłych w temacie… i tu niestety zaczyna się zgroza. O ile na strony zbudowane na table-based layoutach już raczej się nie trafia (chociaż i takie kwiatki widziałem), strony te cierpią na dwa podstawowe problemy.
Divitis
Znakomita większość stron agencji, które odwiedziłem do tej pory, cierpi na zaawansowane stadium tego, co zachodni front-end developerzy nazywają divitis. Divitis objawia się w następujący sposób — webdeveloper, który ją przygotowywał, wiedział jedynie, że tabelki są „be”, a divy są „cacy”. Niestety, o takim zagadnieniu jak dostępność serwisu, czytelność w urządzeniach mobilnych z wyłączonymi arkuszami stylów oraz semantyka samego HTML’a już nikt mu nie wspomniał i efekt jest prosty — strona składa się wyłącznie z elementów div. Gdy zwróci się takiemu developerowi uwagę, nie będzie widział problemu. Co zrobić wówczas? Uświadamiamy takiego człowieka, że HTML nie składa się wyłącznie z elementów div, a oraz span , natomiast W3C wymyśliło kilka fajnych tagów, aby ustrukturyzować HTML m.in. dla przeglądarek nie obsługujących styli czy chociażby crawlerów wyszukiwarek i najprostszym sposobem na poprawienie wyszukiwalności strony jest nauczyć się tych tagów używać. Rekordziści rzekomo zatrudniający etatowych front-end developerów nie mieli ani jednego taga innego niż div użytego na stronie — wielopoziomowa nawigacja potrafiła sprowadzić się do ładnie ostylowanych linków upchniętych pojedynczo w divy, opakowane w… diva z id="menu" . Owszem, walidowało się, jako XHTML 1.0 Strict nawet, ale co z tego, skoro po wyłączeniu styli nawet nie muszę chyba wspominać jak wyglądało.
Oczywiście, są miejsca, gdzie przesadne strukturyzowanie HTMLa oraz jego semantyka nie mają specjalnego znaczenia — są to m.in. aplikacje internetowe mające „emulować” aplikacje desktopowe. Zwykle z powodu wyskakujących Javascriptowych okienek modalnych, czy innych tricków strona bez styli i JavaScriptu nie miała by sensu istnienia, ale w przypadku strony głównej agencji, która chwali się tworzeniem „użytecznych, dostępnych i zgodnych ze standardami serwisów internetowych”, warto zwrócić na takie kwiatki uwagę.
Zainteresowanych odsyłam do artykułów zewnętrznych:
- ENHANCE — The Misunderstood DIV
- Joe Dolson — Why use semantic HTML?
- The Future of the Web — „Who will read your semantic HTML?”
Bezsensowny Javascript
Kolejnym podstawowym problemem spotykanym w tego typu serwisach jest nagminne bezsensowne użycie Javascriptu, w tym braku separacji markupu HTML od jego zachowania oprogramowanego Javascriptem. Cóż z tego, że używasz Prototype, Mootools, czy jQuery, skoro nie rozumiesz ich idei? Biblioteki te powstały między innymi, aby wspomagać pisanie Javascriptu, który jest odseparowany od markupu, czyli tzw. „unobtrusive Javascript”. A tymczasem na wielu stronach agencji chwalących się profesjonalnym podejściem do tematu możemy zobaczyć takie kwiatki jak onclicki w markupie, czy linki prowadzące donikąd.
Czy Ty, drogi front-end developerze znanej agencji, zastanowiłeś się kiedyś co dzieje się ze spiderem przeszukującym serwis Twojego klienta, kiedy natrafia on na link z href="#" i onclick="openModal(test.html)"
Nie? To ja Ci powiem — próbuje podążać za wartością href i trafia donikąd, a więc nie indeksuje wyskakującego modala. To samo stanie się, gdy osoba niewidoma lub niedowidząca trafi na Twoją stronę używając screen readera — „kliknie” w otwórz okno i nic się nie stanie. Jeśli uważasz, że tworzysz dostępne i dobrze wyszukujące się serwisy, napisz link tak, aby prowadził on gdzieś nawet gdy nie ma Javascriptu. Jeśli pop-up, który ma wyskoczyć jest zaszyty gdzieś w kodzie, tylko ma ustawione display:none, ustaw mu ID i kieruj linkiem pod #ID. Jeśli otwiera się zewnętrzna strona, poprowadź href do tej strony, a do Javascriptu obsługującego event click dodaj return false;, aby przeglądarki obsługujące JS nie podążyły za linkiem, a jedynie otwarły go w modalu — dzięki temu wilk będzie syty i owca cała. Gdzie możliwe, odseparuj Javascript od markupu, wsadzając go w osobne pliki, podłączające się do strony za pomocą uchwytów (event handlers) — oszczędzisz pracy przeglądarkom bez Javascriptu, a i kod będzie łatwiejszy w zarządzaniu. Zainteresowany? Odsyłam więc, tak jak poprzednio, do kilku zewnętrznych artykułów.
- Jeremy Keith — „Behavioral separation”, A List Apart
- Christian Heilmann — „The Seven Rules of Unobtrusive Javascript”, Opera Developers Community
- Ara Pehlivanian — „Deck the Halls with Unobtrusive Javascript”, Sitepoint
Urodziłem się 9 października 1984 w Krakowie. Obecnie jestem studentem Informatyki Stosowanej na Akademii Górniczo-Hutniczej w Krakowie.
Projektowaniem graficznym i wzornictwem przemysłowym interesowałem się od zawsze. Jako dziecko rysowałem jak szalony, potem zajmowałem się grafiką i ASCII-artem na demoscenie. Mniej więcej od 2000 roku zajmuję się projektowaniem stron internetowych, od czasu posiadania Internetu w domu zainteresowałem się także standardami, SEO/SEM, dostępnością i użytecznością serwisów internetowych.