Podstawy naszego zawodu nie zmieniły się od lat, webdeveloper musi znać “złoty trójkąt” – CSS, HTML, Javascript. Z tego CSS i HTML doskonale, a JS według potrzeb.

Musi też umieć tak ostylować stronę, żeby wyglądała “dość podobnie” pod większością przeglądarek ( obecnie: Firefox, Chrome, Opera, IE8, IE7 ).

Oczywiście używanie technik tworzenia strony, oraz odpowiednich narzędzi nie jest wymagane, webdeveloper może np.:

  • pisać stronę w notatniku, najczystszym HTML-em, uważając bez przerwy na każdy znaczek, galerię robić czystym CSS (tzw. puryści)
  • klikać stronę w dowolnym edytorze WYSIWYG (Frontpage), do tego nawet znajomość HTML-a i CSS-a nie potrzebna

Od razu ostrzegam, że ten artykuł NIE jest dla tych osób.

Ten artykuł jest dla wszystkich webdeveloperów, którzy nie są zainteresowani tworzeniem koła od nowa – wynaleźli je już raz sumerowie 6000 lat temu, koncepcja się raczej nie zmieniła…

Zatem, co każdy webdeveloper wiedzieć powinien:

Co to jest system kontroli wersji?

Czy zdażyło się Wam kiedyś wykonać jakaś zmianę na życzenie klienta, po czym okazało się że klient jednak tej zmiany nie chce (po zobaczeniu efektu)?

Albo udało się wam popełnić literówkę w HTML-u, a strona pod ie jakoś nie chciała tego przełknąć i się cała rozsypała?

Ewentualnie kot przebiegł nad komputerem, zrzucając wazonik, przez co jedyną kopię strony trafił szlag, łącznie z Wami i w następstwie kotem?

Mnie kilka razy, oprócz kota.

W tym momencie zwykle bardzo cieszy myśl: “dobrze, że użyłem systemu kontroli wersji”.

System kontroli wersji ( ang. version/revision control system ) służy do śledzenia zmian w kodzie źródłowym oraz pomocy programistom i webdeveloperom w łączeniu i modyfikacji zmian dokonanych w tym kodzie.

Jest wręcz niezastąpiony przy pracy grupowej nad kodem, łączeniu zmian i rozwiązywaniu konfliktów.

Bardzo przydatny również przy deploymencie na serwer, oraz stanowi swoisty backup kodu – można odzyskać kod z dowolnego momentu w czasie.

Kilka najpopularniejszych systemów to GIT, SVN (SubVersion), Mercurial, dośc proste w obsłudze, bezpieczne.
Ja sam używam GIT-a (bo najlepszy, ale nie upieram się). Każdy spełni swoją funkcję.

Co to jest framework CSS?

Każde stylowanie strony zaczyna się od zresetowania styli, tak żeby pod wszystkimi przeglądarkami wyglądały identycznie, domyślne rozmiary czcionek, brak paddingów, białe tło – to jest podstawa, na której dopiero można zacząć pracować.

Te bazowe style zwykle są identyczne, nie ma najmniejszego sensu ich modyfikować – właściwie kopiuje się je tylko z projektu na projekt.

Ale po co pisać je samemu?

Są dostępne bardzo dobre frameworki CSS, które stanowią solidną podstawę dla strony, resetują style oraz wprowadzają odpowiednie klasy bazowe ( np. do clearowania elementów, rozmiarów czcionki, formularzy etc. ).

Zwykle dodatkowo oferują też wsparcie dla gridów i sprite’ów (o nich za chwilę).

Trzy najpopularniejsze to Blueprint, YUI oraz 960Grid.

Ja sam używam tego pierwszego, ale YUI i 960 też mają kilka ciekawych rozwiązań.

Co to jest framework Javascript?

W sumie – można napisać cały js od podstaw, ewentualnie skopiować kod np. galerii z poprzedniego projektu po czym trochę się namęczyć z wdrożeniem tego kodu w innym projekcie.

Koło – pamiętacie?

Frameworki js udostępniają większość najczęściej używanych rozwiązań w jednej, zgrabnej paczce, działającej pod każdą przeglądarką:

  • obsługa AJAX
  • toggle’owanie elementów
  • dynamiczna zmiana DOM
  • duuużo pluginów do galerii, lightboxów, tabberów itd.
  • i wiele, wiele innych

Frameworków JS jest dużo, na szczególną uwagę zasługują:

  • jQuery (najbardziej popularny, chyba najprostszy w obsłudze, z olbrzymią dokumentacją i dużą liczbą pluginów)
  • Dojo
  • YUI
  • MooTools (dużo pluginów)
  • ExtJS (świetny do backendów)

Co to są sprite’y?

Załóżmy, że mamy zestaw 20 ikonek na stronie.

Załóżmy, że każda ikonka ma 3 wersje : nieaktywną, aktywną i podświetloną ( hover ).

Daje nam to łącznie 60 obrazków, które strona musi na starcie załadować i wyświetlić, czyli 60 requestów do serwera na 1 użytkownika przy pierwszym odwiedzeniu witryny, tylko z ikonek!.

Załóżmy, że mamy 100 użytkowników na raz na stronie, co daje nam 6000 requestów do serwera, a pamiętajmy że mówimy cały czas tylko o ikonkach, dochodzi HTML, Javascript itd.

Załóżmy, że połowa z nich ma opóźnienia na łączu, w związku z tym strona ładuje się 2 minuty …

Widzicie dokąd to prowadzi, dość sprytny webdeveloper połączy grafikę nieaktywną, aktywną i podświetloną w jeden plik – co zmniejszy ilość requestów na użytkownika do 20.

Bardzo sprytny webdeveloper użyje sprite’ów ( 1 request na użytkownika ).

Na tym właśnie polegają sprite’y -> na łączeniu podobnych grafik w jeden plik, po czym użyciu CSS-a ( background-position ) aby odpowiednio go wyświetlić na stronie.

Dzięki temu rozwiązaniu, typową stronę ostylujemy przy użyciu kilku grafik (jedna na elementy powtarzalne w pionie, druga w poziomie, trzecia na elementy niepowtarzalne, etc.).

Dodatkowo zyskujemy ok 20% na wielkości grafik.

Żeby nie tworzyć tych wszystkich grafik ręcznie istnieją oczywiście g*eneratory sprite’ów*, szczególnie godna polecenia jest strona http://spritegen.website-performance.org/, na którą możemy przesłać archiwum zip z grafikami, poustawiać kilka parametrów i odebrać wygenerowanego sprite’a, oraz pełen zestaw CSS.

Wystarczy tylko podpiąć

Co to są gridy?

Większość stron ma bardzo podobny układ: nagłówek, stopka, pośrodku 2 lub 3 kolumny. Wszystko tak naprawdę opartę na kolumnach… też odkrycie.

Grid, to po prostu styl CSS ustalający siatkę kolumn na stronie, dzięki temu można w bardzo szybki sposób ustalić rozmieszczenie elementów na stronie – wystarczy w HTML-u użyć odpowiednich klas, określających ile kolumn zajmuje dany element, czy jest wyclearowany, czy nie itd.

Ustalenie układu strony, który wygląda tak samo pod wszystkimi przeglądarkami niesamowicie przyspiesza stylowanie.

Dodatkowo systemy gridowe dostarczają różnorodne narzędzia, pozwalające np. zmienić układ strony na fluid (tez w oparciu o kolumny) czy wygenerować CSS-a na inną ilość kolumn.

Istnieją też narzędzia potrafiące wygenerować odpowiedni HTML na podstawie zadanych parametrów (ilość kolumn, szerokość strony, co ile kolumn).

Oczywiście, żeby w pełni wykorzystać potencjał systemów gridowych należy przedtem dostarczyć grafikowi ramy kolumn w jakich się ma zmieścić – na pewno się ucieszy, jego praca też stanie się łatwiejsza.

Najpopularniejsze systemy gridów to, wspomniane wcześniej: Blueprint, YUI oraz 960Grid.

Co to jest feature detection?

Jest to jedno z dwóch podejść do kompatybilności styli między przeglądarkami, można albo stylować pod określoną przeglądarkę ( browser targeting ), albo pod określoną funkcjonalność przeglądarki ( feature targeting ).

Stylowanie pod określoną przeglądarkę ma bardzo dużą ilość wad:

  • dość często trzeba się odwoływać do hacków
  • piszemy dużą ilość nadmiarowego kodu
  • przy wyjściu nowszej wersji będzie tego kodu jeszcze więcej
  • i trzeba go będzie napisać w międzyczasie
  • odpada większość metod z CSS3

Stylowanie pod funkcjonalność ma za to dużo zalet:

  • nie obchodzi nas, co użytkownik ma za przeglądarkę – tylko co ona potrafi (oprócz bugów ie – ale te są w większości znane)
  • przy wyjściu nowszej wersji przeglądarki – styl zostanie ten sam
  • można używać bezkarnie CSS3

Oczywiście wady tego rozwiązania też istnieją, najpoważniejszą jest konieczność przygotowania osobnego stylu pod przeglądarki z bugami ( IE ), ale to trzeba zrobić i tak zawsze.

Feature targeting znajduje głównie zastosowanie w przypadku stosowania CSS3, o czym pisałem chwilę temu w artykule “Bezkarne używanie CSS3”

Feature detection za pomocą javascriptu dodaje do tagu body lub html odpowiednie klasy, określające czy dane przeglądarka obsługuje czy nie daną właściwość ( np. border-radius, text-shadow, box-shadow, itd. ).

Pozwala to zarówno ostylować przeglądarkę używając CSS3, jak i zapewnić sensowny fallback dla starszych przeglądarek.

Wszystko dzięki małemu skryptowi dostępnemu na http://www.modernizr.com/

Co to jest IE6NoMore?

Stylowanie w moim wykonaniu zwykle wygląda następująco:

  • radosna twórczość ( Firefox, Chrome )
  • dopieszczanie szczegółów ( Opera, Safari )
  • futerkowanie ( IE8 )
  • zimny prysznic ( IE7 )
  • mrok, zgrzytanie zębami i przekleństwa ( IE6 )

O ile pierwsze 3 kroki to czysta przyjemność, czwarty – smutna konieczność, to przy piątym powiedziałem ostatnio stanowcze NIE.

Internet Explorer 6 został wypuszczony na świat pod koniec roku 2001, wtedy była to w miarę porządna przeglądarka. Ale to było wtedy – 9 lat temu.

Większość ludzi pewnie od tego czasu zmieniła kilka razy komputer i system operacyjny.

Najwyższy czas odesłać ie6 na zasłużony odpoczynek i przestać go wspierać!

W Polsce IE6 używa mniej niż 5% ludzi, z czego większość w pracy, w dużych firmach.

Naprawdę nie ma sensu robić styli pod tą przeglądarkę – kilka wad ie6 z punktu widzenia webdevelopera:

  • nie obsługuje przeźroczystych png (będących podstawą dzisiejszego stylowania)
  • sponiewierany box-model (użyłeś paddingu? no to masz pecha)
  • obsługuje javascript jak chce
  • wspiera szczątkowo CSS1, teoretycznie słyszał o CSS2
  • nie obsługuje :hover (chyba że na linkach)
  • o pozycjonowaniu absolutnym można pomarzyc
  • lista bugów dłuuuuga

IE6NoMore to kampania promująca aktualizowanie ie6 do nowszych przeglądarek, z ich strony (http://www.ie6nomore.com/, wersja polska: http://ie6.pl/) można pobrać skrypt htc który załączamy w odpowiednim stylu dla ie6, na tag body.

Użytkownicy wchodzący na stronę tą przeglądarką zobaczą na górze strony pasek z komunikatem “używasz bardzo starej przeglądarki, dowiedz się jak ją zaktualizować“ wraz z linkiem do strony objaśniającej, czemu ie6 jest złe i jak zaktualizować przeglądarkę.

Tyle jeżeli chodzi o podstawy, co powinien wiedzieć webdeveloper. Mam nadzieję, że chociaż część z tego tekstu okaże się dla Was przydatna.