Perfection or Vanity

Po wypuszczeniu Internet Explorera 7, zespół programistyczny Microsoftu ucichł na cały rok. Posty na blogu bywały sporadyczne, nikt nie informował – w odróżnieniu od raportów developerki IE7 – jakie cele zostały osiągnięte. Mam nadzieję, że zmieniło się to dzisiaj, kiedy to na IEBlog pojawiła się informacja o pozytywnym przejściu testu Acid2 przez, będącego ciągle na warsztacie, Internet Explorera 8.

Tytułowe pytanie towarzyszy mojej karierze frontend developera od zawsze. Gdy tylko mogę, walczę z mitem prowokującym ten okrzyk zdziwienia programistów server-side i koderów JS. Postanowiłem w końcu napisać dlaczego nie wolno opierać naszego najnowszego serwisu Web2.0 o JavaScript, jak należy myśleć podczas jego projektowania i jakie są nieliczne wyjątki – zgadliście – potwierdzające regułę.

Update: Nie traktuj tego tekstu poważnie, napisałem go na Prima Aprilis.

Kodowanie stron nie jest zadaniem specjalnie łatwym - proces jest spowalniany przez niezgodności międzyprzeglądarkowe i różnice w aplikowaniu standardów. Ostatnimi czasy warunki w jakich przychodzi nam pisać strony uległy znacznej poprawie, a dodając ogromne ilości hacków dla złego z założenia Internet Explorera - wymyślonych przez zdolnych webdeveloperów przez te wszystkie lata - jesteśmy w stanie osiągać w miarę jednolity wynik. W miarę, ponieważ jedna przeglądarka cały czas spowalnia marsz standardów i przenoszalności kodu. A jest nią Opera.

Roger Johansson powiedział kiedyś tak:

Web professionals who refuse to update their skills and insist on using outdated methods can no longer be called web professionals.

(Profesjonaliści, którzy odmawiają uczenia się nowych rzeczy i upierają się przy używaniu przestarzałych metod nie mogą być już dłużej nazywani profesjonalistami - tłum. wł.)

Kiedyś budowaliśmy strony za pomocą tabel, teraz nadszedł czas na podzielenie dokumentu na sekcje i stworzenie z nich layoutu za pomocą CSS. Rozszerzając wypowiedź Johannsona - wszyscy, którzy projektują dalej na zagnieżdżonych tabelach w niedługim czasie albo przestawią się na CSS albo wypadną z obiegu.

Tabelowy layout jest niedopuszczalny, ale prosty w użyciu i bardzo przewidywalny. Webdesignerzy zaczynający pisać w CSS mają całkiem poważne problemy, ponieważ nowoczesne projektowanie opiera się na pozycjonowaniu treści zawartej w blokach. Ich rozmiary nie są sztywne (i w większości sztywne być nie powinny), dlatego nie można uzyskać równych kolumn. Nie można? Zaraz się przekonamy…

Projektowaliście kiedyś mailingi HTML w nowoczesny sposób? Lista niedziałających konstrukcji oraz uproszczeń jakie trzeba zastosować w CSS jest bardzo długa - design wymaga wpasowania się w kilka webmaili oraz parę aplikacji pocztowych. Wśród tych ostatnich prym oczywiście wiedzie Outlook - ~75% rynku. Mimo wszystko nie jest to bardzo trudne, istnieją materiały dla naszej wygody i jakoś to powoli idzie. Do przodu.

Ostatnio jednak MS naprawdę chce iść na wojnę z webdesignerami. Niedawno wyszła nowa wersja Outlooka - 2007. I tutaj, jeśli jeszcze nie słyszeliście o całej sprawie, polecam usiąść i odstawić wszelkie napoje. MS postanowił przełączyć renderowanie maili w HTML z Explorera na Worda.

Można śmiało powiedzieć, że cała magia JavaScriptu opiera się na zdarzeniach i akcjach wykonywanych po odebraniu któregoś z nich. Zdarzenia to na przykład wpisanie tekstu do formularza, kliknięcie w link, umieszczenie kursora nad obrazkiem, załadowanie dokumentu i tym podobne. Bez nich praktycznie nie istniałyby skrypty.

Aby obsłużyć jakieś zdarzenie potrzeba je przechwycić i wykonać odpowiedni kod. Netscape wprowadził do HTML-a nowe atrybuty obsługujące zdarzenia takie jak onclick, onmouseover, onsubmit — Microsoft podążył tym szlakiem i w końcu okazało się, że jest ich po prostu masa.

Mało kto zdaje sobie sprawę, że to rozwiązanie jest wręcz starożytne.