Kto normalny wyłącza JavaScript?!

Project: Terminated

Blog nie jest już dalej prowadzony ani aktualizowany. Mimo tego, wpisy i komentarze są dalej dostępne. Możesz przeczytać pożegnalny wpis albo przejść do archiwum.

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łę.

Separacja warstw

Na początek jednak wspomnę o rzeczy oczywistej. Inaczej bowiem nie można nazwać tworzenia strony z separowaniem warstwy prezentacji od zawartości. Mowa o CSS składowanym w zewnętrznych plikach, będących wdziankiem dla znaczników HTML, stanowiących o treści.

Istnieje jeszcze jedna warstwa stron internetowych – zachowanie opisywane przez JavaScript. Skrypty należy umieszczać w zewnętrznych plikach z tego samego powodu – aby być w stanie zmienić dowolną część oddziałującą na wiele stron.

Wszyscy znają starą maksymę walidacji formularzy – waliduj w przeglądarce, ale zawsze sprawdzaj też na serwerze. Ponieważ JavaScriptowi nie można ufać. Jestem wprost zadziwiony, że ta prawda zostaje zapomniana, gdy tylko pokazać parę efektownych animacji DHTML.

Dlaczego nie opierać się na JavaScript?

Ponieważ może go nie być. Twoje następne pytania / twierdzenia są proste do przewidzenia:

Nikt normalny nie wyłącza JavaScript.

Ile procent ludzi wyłącza JS? Dwa?

Nasz serwis posiada inny target.

To nie nasza sprawa

Prawda jest często dla backendowców bolesna – to jest nasza sprawa i to prawie zawsze. Każdy z użytkowników naszego serwisu może mieć wyłączony JavaScript. Oto dlaczego:

Strona nie załadowała się do końca.

JavaScript uruchamiany jest dopiero po załadowaniu się szkieletu dokumentu (co i tak jest lepsze niż starodawne metody) – do tego czasu wszystkie puste linki i formularze-kukiełki będą po użyciu przeładowywać użytkownikowi stronę.

Nie można tego załatwić przez wstawienie javascript:void(0) do href="", nie przez przesłonięcie całości loaderem – JavaScript ma być oddzielony od warstwy zawartości i prezentacji. Dla dobra zarówno gościa jak i programisty.
Nie sprawdziłeś wszystkich kombinacji.

Nikt nie jest w stanie napisać bezbłędnego kodu, na pewno nie podczas pierwszego cyklu oprogramowania. Nawet jeśli wydaje Ci się, że pod IE i Firefoksem działa dobrze, nie jesteś w stanie powiedzieć czy na Operze na konsoli Wii, skrypt uruchamia się tak samo.

Nie wiesz czy po paru godzinach spędzonych przy serwisie wystąpi błąd, na wyłapanie którego nie było budżetu. Ten błąd spowoduje wykonanie domyślne przeładowanie strony podczas wykonywania skryptu na pustym linku albo podczas przetwarzania martwego formularza. A użytkownik właśnie stracił swoje dane albo cierpliwość.

Oddziel stronę od aplikacji

Następne przełomowe twierdzenie tyczy się przeznaczenia naszego serwisu. Bo nawet gdy uda nam się przekonać zespół, że JavaScript może być niedostępny – zaczyna się smutek i zgrzytanie zębów.

Powszechne jest bowiem przekonanie, że każda część serwisu powinna działać bez JavaScriptu. Musi działać tylko jedna – umożliwiająca korzystanie ze strony, niekoniecznie aplikacji. Najlepiej pokazać różnicę na przykładzie.

Wyobraźmy sobie proces rejestracji i wgrywanie avatara.

Podstawową funkcją jest możliwość wgrania zdjęcia i korzystania z niego do identyfikacji w serwisie. Wystarczy zwykły formularz z polem wyboru pliku.

Zaawansowaną funkcją jest aplikacja JavaScript pozwalająca na wycięcie części zdjęcia po wgraniu i zapisanie tejże jako avatar. Wszystko dzieje się bez przeładowania, aż do zapisu – akcja standardowego formularza zostaje nadpisana w JavaScript – który wysyła przez Ajax zdjęcie na serwer, pokazuje je użytkownikowi, udostępnia interfejs do wycięcia fragmentu i dodaje przycisk "Zapisz", przenoszący dalej.

Twój serwis powinien być tak napisany, aby można było wgrać zdjęcie bez JavaScriptu – fakt dopasowania avatara nie jest kluczowy w procesie rejestracji.

Dobrze, ale jak?

Projektując aplikację myśl o Ajaksie, niekoniecznie od razu go implementując. Zapewnij sobie mechanizmy, które zwracają całą stronę albo tylko jej kawałek. Przedyskutuj funkcjonalność z koderami JavaScript, określ która jej część jest absolutnie niezbędna do przeglądania witryny i zachowania ciągłości pozytywnego doświadczenia użytkownika, a która jest dodatkiem, dobudówką przekształcającą fragmenty Twojego serwisu w aplikacje.

Przykłady funkcji działających bez JS:

Możliwość rejestracji w serwisie
Obejrzenie kolejnej strony prywatnych wiadomości.
Przejście do innej części strony.
Dodanie komentarza.
Zagłosowanie na klip, artykuł, komentarz.
Edytowanie wpisu na blogu.
Skorzystanie z wyszukiwarki.
Wgranie zdjęć do składnicy online.

I ich starsi bracia, dopisani w JavaScript:

Automatyczne sprawdzenie dostępności loginu.
Doładowanie kolejnej porcji wiadomości.
Przełączanie wizualnych tabów.
Wysłanie go przez Ajax, bez przeładowania strony i możliwość wysłania kolejnego.
Automatyczna akcja, bez przeładowania.
Edytowanie w miejscu – zamiana akapitów tekstu na formularze.
LiveSearch.
Skorzystanie z zaawansowanego uploadera pokazującego postęp procesu.

Projektując kod JavaScript dużego serwisu, zaopatrz się w framework, który pozwoli Ci swobodnie poruszać się po dokumencie, kopiować, dodawać i usuwać jego części – aktualnie każdy posiada funkcje trawersowania DOM, ja polecam oczywiście ten napisany wokoło faktu manipulacji DOM, jQuery.

Nie myśl o tym jak część interfejsu będzie działać pisząc dla niej HTML, nie wyobrażaj sobie tego co się wydarzy po kliknięciu z włączonym JavaScript. Zawsze przygotowuj się na wypadek jego braku.

Wyjątki

Napisałem już wyżej jak wygląda proces na przykładzie wgrywania avatara. Logiczne jest, że nie da się w sposób wygodny dla użytkownika oprogramować aplikację edytującą zdjęcie – przeładowywanie strony setki razy aby zmniejszyć szerokość fotki jest bez sensu.

Tak samo podszedłem do problemu projektując interfejsy wczesnej bety Respectance.com – wiadome było, że edytor pozwalający łączyć zdjęcia, dodawać efekty przejścia i zapisywać je w postaci klipu musiał wymagać JS – ale była to pełnoprawna aplikacja i tylko część serwisu.

Identycznie działa konfiguracja przycisków wstawiających HTML w panelu administracyjnymi Joggera. Skoro całość opiera się na fakcie posiadania JavaScript (a wysyłanie formularza za każdym wciśnięciem taga jest o wiele gorsze niż ich brak), tak więc edycja przycisków spokojnie mogła zostać zrobiona bez martwienia się o jego brak. Lecz jest to jedyna „JS-only” opcja całego Joggera.

Nie możemy bowiem opierać się na JavaScripcie - jest to technologia czekająca nadal na ustandaryzowanie, przyspieszenie i nowy zestaw funkcjonalności.

Przypomnę więc:

Budujmy serwisy w staroświecki sposób, ze zwykłymi linkami kierującymi do akcji serwera i przeładowywaniem formularzy.
Nadpisujmy te domyślne akcje przez aplikacje JavaScript, zwiększając użyteczność i wydajność interfejsów.

Tagi wpisu: ajax, dom, graceful degradation, hijax, javascript, progressive enhancement, usability, web applications, webapps

Informacje i hiperłącza

Piotr Petrus 'Riddle'

Blog o projektowaniu zgodnych ze standardami stron internetowych.

Praktyczne przykłady, sztuczki CSS, sposoby obchodzenia błędów przeglądarek, lekki i nieinwazyjny JavaScript, użyteczny design, dostępność i skrypty użytkownika.

RSS

Informacje o wpisie

Napisał riddle 07 listopada 2007 o 02:35

Kategorie: JavaScript & DOM, Standardy sieciowe, Użyteczność

Wpisy archiwalne

Archiwum miesięczne

Dzięki!

Komentarze

Riddle 1 07 listopada 2007, 02:35
I jeszcze jeden przykład – głosowanie na komentarze, określające ich przydatność w serwisie. Dwa przyciski, w dół / w górę.

Podstawowa funkcja to „społeczna moderacja” – ocenę zawartości można zobaczyć na Diggu czy YouTube. Jest to zwyczajny link z parametrami wskazującymi na wątek i komentarz, który zmienia stan.

Zaawansowana funkcjonalność to kwestia użyteczności – brak przeładowania strony, zmniejszenie ilości przesyłanych danych i szybsze powiadomienie o wyniku akcji. Domyślna akcja jest wyszczuplona przez JavaScript. Jest to ważne – gdy popatrzymy choćby na podlinkowany Digg.com, możemy się przekonać jak długo potrafią ładować się komentarze. Bez podstawowej funkcji, każdy z linków głosujących byłby bezużyteczny przez pewien okres czasu – w którym możemy już zacząć czytać komentarze i zechcieć je oceniać. Bez podejścia progresywnego ulepszania (progressive enhancement) odświeżylibyśmy sobie stronę.

A więcej informacji tutaj:
- Hijax
- You cannot rely on JavaScript being available. Period.
WZ. 2 07 listopada 2007, 03:18
Well said.
Warto dodać —
- Jeśli element (powiedzmy, launcher którejś funkcjonalności) opiera się wyłącznie na JavaScripcie (i nie ma mowy o alternatywie w wypadku braku wspomnianego), to warto przerzucić jego wywołanie do warstwy zachowania, bo bez JS będzie kompletnie bezużyteczny i nawet w przypadku progressive enhacement może być mylący w różnych wypadkach (dlaczego ten przycisk niedziała???).
- Pisząc o ograniczeniach w wypadku wyłączonego JS – niektórzy mogą mieć „wyłączoną myszkę” ;) więc pod to chyba podchodzi też zapewnianie równorzędnej funkcjonalności z klawiatury – logiczna kolejność, typowe błędy typu sam onclick na linkach albo onclick zamiast onsubmit na formularzach.
- W przypadku linków ładowanych przez AJAX automatycznie, minimalnym kosztem – niech link odwołuje się do pliku z kompletnym drzewem dokumentu, dopiero później obierzmy go ze zbędnych rodziców i wstawmy konkretny element jako response (ZAMIAST: ładowania plików będących tylko „wewnętrzną częścią”).
Coś jeszcze? Temat chyba open–ended ;)
Cezary 3 07 listopada 2007, 06:04

@WZ, a zdarzenie click nie jest odpalane także przy nawigacji klawiaturowej? Wydaje mi się, że kiedyś testowałem, że przyciśnięcie entera na linku to też onclick.

Z ciekawostek ja ostatnio zauważyłem, że Google zaczął ściągać moje JS-y, więc pewnie nauczył się także je parsować i patrzeć co na stronie zmieniają. Brak JavaScriptu w wyszukiwarkach to był kiedyś dodatkowy argument za opracowywaniem stron z JS wyłączonym – żeby dać się zindeksować.
pawkow 4 07 listopada 2007, 06:38

Ok, to ja mam pytanko: powiedzmy, ze mam stronę, gdzie dodaję komentarz. Przy włączonym JS serwer zwraca mi odpowiedź, powiedzmy string ‘true’ lub ‘false’. Na podstawie tych danych przedstawiam informację userowi.

Co jednak, kiedy taki user ma wyłączony js ? Zostanie przekierowany do strony, i wyświetli mu się komunikat o treści true. Jak czemuś takiemu zapobiec ?

Myślałem o wykrywaniu w skrypcie, czy zapytanie przesłane zostało od użytkownika czy przez Ajax, jednak to chyba nie jest najlepszy pomysł.

Podsumowując: szukam rozwiązania dobrego :)
Cezary 5 07 listopada 2007, 07:54

@pawkow: Załóżmy, że Twoje true i false to „taki login już istnieje w systemie” i „login wolny”. W takim przypadku przygotowujesz normalny formularz, po którego wysłaniu najprawdopodobniej taka informacja pojawia się na górze (gdziekolwiek) na wynikowej stronie – opracowujesz całą stronę. Dodając do tego JavaScript po jakimś tam zdarzeniu (onsubmit?) robisz to co teraz tylko musisz zapobiec domyślnej akcji onsubmit jakimś return false, preventDefault, stop czy czym tam jeszcze stosownym do używanych narzędzi.

Linkować do zasobu, który napisze true nie ma sensu – trzeba wygenerować całą stronę – najprawdopodobniej pod innym adresem, ale jeśli będziesz się trzymał wzorca projektowego MVC po stronie serwera, to za dużo nowego kodu się nie napiszesz.

Jak podasz więcej szczegółów, to da się podać konkretny dostępny przepis.
Marcin / Ktos 6 07 listopada 2007, 08:34

Ja jeszcze tylko potwierdzę słowa Riddla dodając jedną rzecz: nie wolno próbować opierać całego ładowania treści strony o Ajax. Owszem, może jest to fajne, że się strona sama „aktualizuje”, że treści są doładowywane w trakcie, jak użytkownik już coś może robić, ale nie jest fajne, jak ja, wchodząc z przedhistorycznej przeglądarki, nie widzę nic oprócz nagłówka.

I czy kolejny wpis oznacza, że postanowiłeś, że trzeba pisać na blogu, Rid?
Maciej Łebkowski 7 07 listopada 2007, 09:23

Co do gogla – ściąga JS-y chociażby dlatego, że uruchomił codesearch.google.com. A może do sitemap? A może…

W każdym razie, to że ściąga, nie oznacza, że parsuje. Wstaw do tego JS-a linka i sprawdź, czy Goog kiedykolwiek pod niego zawita.
Dziudek 8 07 listopada 2007, 09:37

@Marcin / Ktos – to co piszesz jest po prostu zrobione dla efektu, a nie dla usprawnienia działania… Bo równie dobrze dane mogły być od razu załadowane z (X)HTML, zamiast efekciarskiego efektu „doładowania” – w tej sytuacji można jedynie zrobić przycisk to sprawdzania czy pojawiły się jakieś nowe informacje i wtedy doładować je AJAX-em…

@pawkow – na pewno da się to przerobić na statyczną wersję tylko to co robiłeś robiłeś z założeniem, że JS jest włączony…

Co do samej idei jaką we wpisie przekazuje Riddle – podszedłbym do tego tak – zgadzam się, ale w granicach rozsądku. Dlaczego ?

Czasem trzeba zastanowić się czy aby na pewno się opłaca zadbać o to, że JavaScript będzie wyłączony – jeżeli ta kwestia wymaga ode mnie kilku-kilkunastu dodatkowych godzin poświęconej programowaniu statycznych alternatyw, a ma na tym skorzystać 10 osób z czego 8 i tak by nie było zainteresowane treścią strony to zrobienie tego jest raczej kwestią zapewnienia sobie satysfakcji przez programistę, bo z ekonomicznego punktu widzenia jest to bezsensowne… Oczywiście w wypadku serwisów Web 2.0 sprawa nabiera zupełnie innej skali, ale w wypadku małych projektów i stronek czasem się to naprawdę nie opłaca – ja osobiście mogłem stworzyć wersję działającą bez JS mojej przeglądarki delicji ale wymagałoby to napisania kodu PHP, który zajmowałby z 2 razy tyle co skrypt JS, a z tego rozwiązania skorzystałoby (może) kilka osób…

Także moim zdaniem owszem warto stosować się do zaleceń zawartych we wpisie, ale nie można popadać w skrajności ;)
Riddle 9 07 listopada 2007, 09:51

Dziudek, wybacz jeśli za wcześnie wyciągam wnioski, ale z tego co napisałeś wynika dla mnie w miarę jasno, że nie przyłożyłeś się za bardzo do przeczytania wpisu – w nim jest bowiem jasno napisane, że nie jest to 8-10 osób, nie jest to klika osób na tysiące pozostałych.

Naszym obowiązkiem jako profesjonalnych koderów jest pisać z uwzględnieniem progressive enhancement.

WZ: Dzięki za komentarz, znakomicie rozszerza to co napisałem. :) Co do onclick to chyba jednak chodziło Ci o onmousedown, ale przesłanie oczywiście rozumiem i jak najbardziej się zgadzam.

Pawkow: Dlatego napisałem – najpierw podstawowa „Web1.0” strona z przeładowaniem i wynikową stroną w HTML. Później dodatki JS bez przeładowania.
Dziudek 10 07 listopada 2007, 09:56

@Riddle – z Twojego wpisu nie wynika jasno, że chodzi o większe projekty, dlatego napisałem co myślę o postawionej we wpisie idei jeżeli chodzi o małe projekty ;) Z Twojego wpisu wynika głównie: Nie możemy bowiem opierać się na JavaScripcie , a w niektórych wypadkach może być to po prostu nieopłacalne…
wariat 11 07 listopada 2007, 10:20

„Naszym obowiązkiem jako profesjonalnych koderów jest pisać z uwzględnieniem progressive enhancement.”

No to w końcu kto jest odpowiedzialny za to co jest w panelu joggera i okolicach? Rozumiem, że tam to jacyś amatorzy tak?

MSPANC
forrestar 12 07 listopada 2007, 10:28

Zanim ktoś odniesie się do mojego komantarza – o ile w ogóle się odniesie – proszę go dokładnie przeczytać ;).

Zgadzam się z treścią wpisu Riddle’a, zgadzam się w pełni.

Jednakże ;)... nie zdarzają się Wam sytuacje, kiedy klient nalega wręcz na oparcie części wykonywanej dla niego strony na JS? Mogę przekonywać, mogę odmówić wykonania – bo jest to wbrew moim przekonaniom. Ale mogę też stracić tego klienta i kolejnych. Coś za coś, bardzo trudno jest wybrać. Mogę tworzyć zawsze, tylko i wyłącznie z moimi przekonaniami i być bezrobotnym, mogę dostosować się do oczekiwań klienta i mieć na chleb :). Zdarza mi się i pierwsza i druga opcja.

A tak całkiem od innej strony – podkreślam, mimo, że zgadzam się w pełni z wpisem Riddle’a… nie mieliście kiedyś ochoty się „postawić?”.

Dla przykładu – olać tworzenie stron także pod IE, tworzyć jedynie pod nowoczesne przeglądarki. Ba, więcej, bezczelnie wrzucić komunikat dla użytkownika IE, że jego przeglądarka jest be i fe, i aby a) wspomóc rozwój sieci i b) móc poprawnie wyświetlić tą stronę —> powinien zaopatrzyć się w coś lepszego niż taki IE ?

Nie mieliście choć raz w życiu ochoty na coś takiego :) ? Może dzięki temu dotarłoby do konserwatywnych użytkowników Sieci „o co kaman”, i gdyby zaczęli przerzucać się na nowoczesne przeglądarki – wymogłoby to wreszcie działanie na MS? Stworzyliby nową przeglądarkę godną takiej Opery czy Firefoxa?

Wypowiedzcie się szczerze :).
D4rky 13 07 listopada 2007, 12:00

Do listy koniecznosci dodam rowniez urzadzenia mobilne (PDA, komorki). Naprawde wole miec mozliwosc wygodnego przegladania strony jadac pociagiem czy busem kilkadziesiat kilometrow. Nawet nie wiecie jak przyjemnie sie wtedy czyta np. Joggera, gdy nie masz co robic, a za oknem ciemno.

Zreszta, nie tylko ja to zauwazylem
EM 14 07 listopada 2007, 12:57

„ja polecam oczywiście ten napisany wokoło faktu manipulacji DOM, jQuery.”

ja polecam przyjrzeć się do czego głównie używamy frameworka. Jeśli zależy nam na szybkości działania to polecam małe porównanie: http://mootools.net/slickspeed/
Hoppke 15 07 listopada 2007, 12:58

Jogger mi zeżarł komentarz, więc napiszę w skrócie:

Front-end nie jest prawie nigdy samodzielnym produktem. Jest tylko nakładką na to, co tkwi pod spodem. Często to, co tkwi pod spodem jest tak złożone, że jogger czy youtube w porównaniu z tym wyglądają jak „hello world” przy Excelu.

Innymi słowy: jeśli masz szczęście pracować przy interfejsie tak prostym, że odbiorca/odbiorcy zaakceptuje go bez JS, to super. Korzystaj z tego. A jeśli klient nie wymaga wersji non-JS, to jej nie rób i lepiej wykorzystaj zaoszczędzony czas na testy i dalsze ulepszanie UI.

Często zdarzają się też sytuacje, że bez JS/AJAX się nie da. Profesjonalistę (albo przynajmniej front-endowca z szerokim doświadczeniem) można IMO poznać po tym, że ma świadomość występowania takich sytuacji i umie podać przykłady ze swojej praktyki. A jeśli umie sam wymyślać takie przykłady bez powoływania się na swoje konkretne doświadczenie, to już w ogóle super.
Riddle 16 07 listopada 2007, 13:06

Nie, nie korzystaj z tego. Podejdź profesjonalnie i zapewnij działanie stronie, gdy JavaScriptu nie będzie – jak napisałem w poście.

Zamysłem Hijaksa jest skierowanie developerki w stronę progressive enhancement – aby te skomplikowane trzewia w stylu Excela (lecz jest to zły przykład, bo Excel to aplikacja, a nie coś co można stripnąć do standardowej polinkowanej strony) pozwalały na zwyczajne akcje, a nie tylko magię JavaScriptu.

Czyli albo się totalnie nie zgadzasz z wpisem, albo go nie przeczytałeś. ;-)
Hoppke 17 07 listopada 2007, 13:10

„Podejdź profesjonalnie i zapewnij działanie stronie, gdy JavaScriptu nie będzie”

Przykład z życia. Mam klienta, który chce, by proces który do tej pory był zakodowany bez JS, obejmował kilka stron i ładnych kilkadziesiąt przeładowań tych stron zrobić mu dynamicznie. Bo konstruowanie szablonu kontraktu wysokiego ryzyka zajmuje pracownikowi ponad pół godziny.

No i chłopacy z działu UI zrobili z tego jeden ekran z siecią różnych okienek i formularzy, które dzięki AJAX-owi inteligentnie zmieniają swoją zawartość, dzięki czemu pracownik jest w stanie poustawiać wszystkie parametry i powprowadzać wszystkie dane w ciągu ok. 5 minut.

Co zrobi Profesjonalny Riddle?
Riddle 18 07 listopada 2007, 13:23

Z tego co piszesz wynika dla mnie tylko jedno – nie zrozumiałeś wpisu, ponieważ ja nie napisałem że nie jestem za Ajaksem, dynamicznymi formularzami i usprawnieniem workflowu endusera.

Jestem całym sercem, ale jeśli da się wydzielić w tym skrypcie JS standardowe przechodzenie do kolejnych części zawartości, to muszą być zrobione liniowo w postaci HTML → link → HTML, a później spięte i przyśpieszone przez xmlHttpRequest, wyświetlające na jednej stronie.

Dodam także, że nie mam pojęcia jaki typ skryptu / aplikacji Twoi kumple zrobili i czy się to uprościć do schematu, który opisałem. Jeśli się nie da to tak – zostaje to jako aplikacja JS i nie ma do tego wersji „Web1.0”. Napisałem to we wpisie także.

Na koniec powiem jeszcze – Polska to taki śmieszny kraj, w którym nie dość że klientowi wydaje się, że jest lepiej przeszkolony od zespołu który mu stronę klika (standardowa procedura myślenia klientów), to jeszcze często nie pozwala na argumentację lepszych rozwiązań.

Dlatego wiem, że mój wpis w kontekście polskich agencji interaktywnych i klikaczy takich jak Ty, jest utopijny – podobnie jak promowanie rozwiązań tableless, czystego kodu i JavaScriptu niezaśmiecającego namespace’u. Mimo to będę to robił, bo kodowanie nie kończy się na „Polsce”. Przeczytaj tylko podlinkowane w moim 1 komentarzu wpisy.

Mam jednak szczęście pracować w agencji, która nie znosi partactwa, a za takie uważam zrobienie formularza logowania na przycisku-linku z atrybutem onclick="return letMeIn();" bez żadnej alternatywy. Czy mówię, że Ty partaczysz? Nie, nie wiem tego.
arag0rn 19 07 listopada 2007, 13:31

Hoppke, Riddle: wy chyba mówicie o dwóch różnych rzeczach. Ja na przykład rozwijam w pracy aplikację która nie tylko wymaga JS, ale i Gecko. Używamy ocsinventory-ng, więc jak się okazało że walczenie z IE jest nieopłacalne admin kliknął „deploy” instalując Fx na wybranych maszynach (zresztą Fx i tak jest nieoficjalnym „corporate standard”) i mam od tamtej pory w bardzo dużym poważaniu to czy ktoś zechce sobie użyć IE, wyłączyć JS czy co tam jeszcze. Jest ściśle kontrolowane środowisko, jestem w stanie je wymusić, więc nie dorabiam sobie niepotrzebnej nikomu roboty i mogę się skupić na istocie problemu. Tu ma rację bytu podejście Hoppke.

Natomiast projektując serwis internetowy dla publiki nad którą nie mam kontroli wolę podejście Riddle’a, bo wtedy oszczędzam sobie setki godzin refactoringu i pracowania w kółko nad tym samym kodem tylko po to żeby zaczęło to jako tako działać w innych niż zakładane warunkach.
Hoppke 20 07 listopada 2007, 13:51

arag0rn, bo ja wiem? Wydawało mi się, że mówię dość ogólnikowo. Riddle ma skrzywienie na serwisy web2.0, community-based, a ja akurat z takimi w ogóle nie mam do czynienia i dlatego od razu widzę, że to co przedstawia jako „profesjonalizm” nie jest uniwersalne ani słuszne w każdym przypadku.

Podstawą profesjonalizmu jest IMO trafienie w potrzeby klienta/odbiorców, czyli trafna analiza. Dlatego mówię, że jeśli klient zaakceptuje stronę bez JS, to można z tego skorzystać[1]. Jeśli klient WYMAGA strony non-JS oraz AJAX/JS (jak to ma w przypadku klienta „community”), to należy przygotować takie wersje.

[1] – ale jeśli klient zamawia produkt w wersji dla IE z włączonym JS (i taka jest zakontraktowana platforma docelowa), to robienie mu wersji non-JS „just in case” jest NIEPROFESJONALNE. Nieprofesjonalne, bo tracisz czas na robienie wersji non-JS (czasem to nic nie kosztuje – wtedy ok, ale częściej to całkiem wymierny nakład pracy, bo JS/AJAX nie używa się bez potrzeby), tracisz czas na testowanie wersji non-JS (tutaj niestety to może zdublować nakład czasu potrzebnego na testy) , no i komplikujesz UAT. Jednym słowem wciskasz klientowi coś, czego nie chce, nie potrzebuje i prawdopodobnie nigdy nie wykorzysta, zamiast dopracować to, na czym mu zależy. A jak pokazuje praktyka, w projektach informatycznych prawie zawsze największym problemem jest zmieszczenie się w czasie.

Profesjonalizm to dostarczenie dobrego projektu. Czasem „wersja bez JS” nie ma dla klienta żadnego znaczenia. Wiem, że front-end developer nie musi mieć świadomości takich faktów, ale profesjonalista powinien już zdawać sobie sprawę, że jeśli coś jest dla klienta nieistotne, to nie należy tracić na to czasu. Bo zawsze można lepiej wykorzystać ten czas.
Riddle 21 07 listopada 2007, 13:59

Hoppke, jeśli klient zamawia coś na zamkniętą platformę to masz rację. Jeśli jednak wiesz, że oglądać stronę może każdy w Internecie, to progressive enhancement jest wymogiem.

Należy też zawsze brać poprawkę na niedouczenie klienta. I też mi chodzi tylko o systemy niededykowane platformom.
Hoppke 22 07 listopada 2007, 14:38

Riddle, odnośnie tego akapitu „że Polska to śmieszny kraj”... To nie tak. Ja nie mówię, że klient ma zawsze rację. Mówię, że front-endowiec to niekoniecznie osoba właściwa do negocjowania z klientem (pomijając malutkie firemki i projekciki).

Może opiszę swój background. Obecnie pracuję w UK. Odbiorcami „produktów” są przede wszystkim Aon i Lloyds (w USA, UK, ostatnio nawet w Chinach). Plus kilkudziesięciu różnej maści klientów rozsianych po całym świecie.

Faza „zbierania wymagań” to tu zadanie dla ludzi, którzy się w tym specjalizują i wiedzą dobrze co da się osiągnąć w jakiej technologii, a często świetnie orientują się też w tym co klient chce zrobić(!), więc umieją mu wyperswadować gdy próbuje sobie w stopę strzelić. To nie jest tak, że klient narzuca swoje zdanie front-endowcom.

Koder czy spec od CSS nie ma dostatecznej wiedzy biznesowej, a wiedza techniczna jaką posiada jest zbyt szczegółowa i za mało przekrojowa by poradzić sobie ze zrozumieniem klienta i wyborem najlepszego rozwiązania. Dlatego ktoś inny to nadzoruje. Widać to szczególnie mocno gdy nie robisz serwisu „dla każdego”, tylko np. robisz serwis dla prawników czy brokerów giełdowych. On nawet niekoniecznie musi być zamknięty, wystarczy że ma wyspecjalizowaną grupę odbiorców.

Świadomość takich faktów to część tego, co pracodawcy tu nazywają „full product lifecycle experience”. Musisz wiedzieć w jakim procesie uczestniczysz (jaką metodologię stosuje), kto jest odbiorcą itp.

Bo oczywiście – jeśli robisz coś dla internetowego community, to będzie to inaczej wyglądało. Masa ludzi z nieznanymi konfiguracjami sprzętowymi, z nieznanym trendem zmian w przyszłości. Trzeba być otwartym na jak najwięcej możliwości. Tak samo zmieniają się kompetencje – jeśli np. robisz jakiś nieduży projekt (np. sklep internetowy), to jako autor front-endu możesz pewnie sporo wymusić, nawet zmianę części logiki biznesowej (typu: na tej stronie chcę mieć takie i takie dane, więc koderzy będą musieli przepisać jakiś moduł). Czasem możesz wybrać, że chcesz mieć dane wejściowe w XML (i narzucić wygodną dla Ciebie strukturę) i obrabiać je w XSL-u, ale czasem struktura XML-a będzie totalnie pochrzaniona i jako front-ender musisz z tym żyć. Czasem dostaniesz tylko jakieś webservices z których będziesz musiał korzystać.

W projektach pewnej wielkości przestajesz mieć wpływ na wybór pewnych rzeczy (jak np. robienie stron non-JS obok AJAX-owych właśnie), bo takimi decyzjami zajmuje się kto inny. Ktoś bardziej kompetentny.

W niektórych kawałkach projektu nad którym pracuję nawet „usability” jest odgórnie zaprojektowane i UI-guys nie muszą się tym przejmować, bo projektowanie i pilnowanie „usability” czy „user experience” to zadanie dla jeszcze innej osoby, wykształconej w tym właśnie kierunku. I ta osoba zwróci interfejsowcom uwagę w razie czego, mówiąc co należy na stronie zmienić.

Dlatego myślę, że od zasady typu „rób wersję non-JS gdy tylko to możliwe” lepsze jest „uczestnicz w projekcie (procesie produkcji) zgodnie z jego zasadami”. Bo to pierwsze jest prawdziwe tylko w pewnych przypadkach (i to wcale nienajliczniejszych IMO), a to drugie prawdziwe chyba zawsze.

Ja wiem, że kodowanie nie kończy się na Polsce. Ale pamiętaj Riddle, że profesjonalizm nie kończy się na zasadach web2.0.
Cezary 23 07 listopada 2007, 14:45

Ostrożnym warto być ze stwierdzeniem o specyfice problemu Polski. Gdyby na świecie te pomysły szeroko przyjęte, to Jeremy Keith nie miałby tyle chętnych na objazdowe przedstawienie – co chwila w innym kraju. Aktualnie na web20expo w Berlinie. Jak czytam agendę z jego wystąpień, to w kółko to samo nawija na wyszystkich sxsw, dconstruct, fowa itd.… A wszystko, na co idą tysiące €/£/$, można znaleźć sfilmowane w necie…
tomq 24 07 listopada 2007, 16:58

Całkowicie się zgadzam, że strony powinny być w pełni dostępna dla jak największej ilości użytkowników …
Z drugiej jednak strony uważam, że nie można się zatrzymywać i pamiętać ciągle o ludziach, którzy nie wpisują się w grono potencjalnych użytkowników naszej aplikacji/serwisu.
Mając na względzie wszystkie osoby, które są wyjątkami – nasza strona powinna mieścić się na ekranie przy szerokości 640px i być obsługiwana przez IE 5.5 z wyłączonym JS?
Riddle 25 07 listopada 2007, 16:59

W części wpisu „Dlaczego nie opierać się na JavaScript?” są dwa duże punkty wyjaśniające czemu JS wyłączony może mieć każdy z nas.
Hoppke 26 07 listopada 2007, 17:02

BTW, odnośnie dostępności i dbania o wszystkich klientów – czasem prowadzi to do ciekawych przegięć. Jak np. pierwszy przykład z WTF :)
Michał Krupa 27 07 listopada 2007, 18:18

Odnośnie „Nie sprawdziłeś wszystkich kombinacji.”:

Przy stosowaniu bardziej zaawansowanych skryptów lub jakiegokolwiek frameworku w większych serwisach powinno się przemyśleć obsługę tych skryptów przez starsze przeglądarki. Dla przykładu: jQuery lubi wyrzucać błędy w IE 5 (tak, wiem, prehistoria, ale wciąż są sytuacje kiedy jest to jedyna dostępna przeglądarka) przy każdym załadowaniu strony, co skutecznie zniechęca do używania takiej strony. Trzeba się zastanowić czy w ogóle wysyłać takie skrypty użytkownikowi (blokada na podstawie analizy nagłówków http) a w zamian zaserwować mu niewielki komunikat (oczywiście łącznie z normalną zawartością strony) o zaistniałej sytuacji z możliwością wyboru co chce zrobić w takiej sytuacji. Pewnie, że nie zawsze jest to możliwe, jednak gdy js odpowiada głównie za dodatki (wspomniany digg) a nie ważne funkcjonalności (aplikacji google) może się to być dobrym gestem w stronę użytkowników.
D4rky 28 07 listopada 2007, 18:24

Michale Krupa – właśnie. Google. Sztandarowy przykład, że chcieć to móc – większość ich najważniejszych aplikacji (gmail, picasa) ma wersję niejavascriptową. Nie da się? Im to powiedzcie.
Michał Krupa 29 07 listopada 2007, 18:38

D4rky: „Krupo” ;) Tak, ale serwisy takie jak Google Reader bez js straciłyby sens istnienia.

Za brak wersji niejavascirptowych (piękne słowo ;)) często odpowiada, jak ktoś już wspomnial, budżet projektu, jednak googla bym raczej o to nie posądzał...
Hoppke 30 07 listopada 2007, 19:52

D4rky: Google jest akurat świetnym przykładem na to, że nie zawsze się da.

Picasa czy GMail to akurat względnie proste aplikacje, używające JS głównie do funkcjonalności która nie jest krytycznie ważna.

Ale popatrz np. na googlowy arkusz kalkulacyjny – bez JS ta aplikacja przestaje istnieć. Ba, Google ma problem nawet z obsługą przeglądarek – ich bardziej zaawansowane appy działają poprawnie tylko w IE/FF…
Riddle 31 07 listopada 2007, 19:59

GMail bez JS to inna aplikacja. Nie ma tam progressive enhancement, tylko code fork. ;)
Adriano 32 07 listopada 2007, 21:41

„Kto normalny wyłącza JavaScript?!” – kiedyś spotkałem się z dyskusją na podobny temat. Pytanie brzmiało: „Kto wyłącza JavaScript?”.
Jedna z odpowiedzi brzmiała następująco:

„imho paranoicy i ludzie optymalizujący nawet ilość ikon na pulpicie, żeby im się szybciej system uruchamiał.”

Co o tym sądzisz Riddle? ;)
CoYoT 33 07 listopada 2007, 21:49

A co np. z dynamicznymi kalendarzami? Trochę to jest zbyt czasochłonne, żeby to samo pisać jeszcze w PHP i robić pop-up’a z kalendarzem (większość pop-up‘ów i tak jest domyślnie blokowana, a sporo użytkowników nie zauważa w ogóle, że do blokady doszło).
Riddle 34 07 listopada 2007, 22:12

Adriano: Jak ktoś chce, niech wyłącza. Znam ludzi, którzy w ten sposób blokują sobie reklamy i popupy. Cóż, ja mam Firefoksa (a jak mi się znudzi to Operę, Safari i inne nowoczesne przeglądarki). Oczywiście są też firmy, które wolą wyłączyć pracownikom JS niż zmienić „Internet” na bezpieczniejszy program.

CoYoT: Taka kontrolka umieszcza dane w towarzyszących jej polach tekstowych (nawet jeśli są one ukryte, aby stworzyć iluzję wyboru na widgecie kalendarza), więc może być spokojnie dodana w JS – podstawowa funkcja czyli wpisanie daty jest dalej możliwa (stąd ew. ukrycie pól należy robić nie w CSS, a JS).

Wczoraj pojawił się też wpis na Google Webmaster Central Blog polecający dokładnie to co opisałem wyżej. :)
CoYoT 35 07 listopada 2007, 22:16

No fakt, dzięki za tak prędką odpowiedź. :) A swoją drogą to wydaje mi się, że póki co większym złem są strony przeładowane Flashem albo takie które wyświetlają reklamy nad właściwą zawartością strony i czasem nie da się ich „wyklikać” bez przeładowania strony :/
yanoo 36 08 listopada 2007, 15:26

mnie i tak najbardziej bawi powiększanie obrazka javascript: void(0) :))
maquina 37 08 listopada 2007, 21:45

@Hoppke:
„Picasa czy GMail to akurat względnie proste aplikacje, używające JS głównie do funkcjonalności która nie jest krytycznie ważna.”
Ha ha ha.

„Google ma problem nawet z obsługą przeglądarek – ich bardziej zaawansowane appy działają poprawnie tylko w IE/FF…”

Poprawna obsługa dwóch implementacji Javascriptu przy takim stopniu zaawansowania to już dużo. Może kiedyś będzie jakaś pojedyncza, dominująca implementacja? (Ta, jasne :D)
D4rky 38 08 listopada 2007, 21:48

maquina – AFAIR jest DOM Level 1-3
maquina 39 08 listopada 2007, 21:57

@D4rky: AFAIR nie tylko DOMem JavaScript stoi?
Hoppke 40 08 listopada 2007, 22:03

@maquina:
„Poprawna obsługa dwóch implementacji Javascriptu przy takim stopniu zaawansowania to już dużo.”

I dlatego dużą część bugów aplikacji googla dawało się w Operze naprawić pojedynczym userscriptem?

Ha ha :)
Dot 41 10 listopada 2007, 00:52

@Hoppke: Cóż, wynika stąd jasno, że Google po prostu założyło, że nie chce wspierać przeglądarki Opera. Bo jeśli coś DA SIĘ poprawić, do tego dość prosto, a Google tego nie zaoferowało, to raczej nie dlatego, że nie potrafili.

P.S. Sprawa może być jeszcze innej natury – ten sam userscript odpalony w greasmonkey na przykład rozwalałby stronę i Google wybrało Fx nad Operę, albo coś takiego – nie analizowałem tych problemów, bo z Opery nie korzystam do przeglądania Internetu, jedynie do testowania swoich stron.

Co do samego tematu:
Są trzy rodzaje grup odbiorców:
1) Grupa zamknięta (w szczególnym wypadku, acz nie tak bardzo rzadkim, jedna osoba) – wówczas można stronę stworzyć tak, by działała w konkretnej konfiguracji. Dość częstym przykładem są panele administracyjne prywatnych stron i tym podobne elementy, gdzie można napisać stronę pod użytkownika, ostatecznie nakłonić użytkownika do zmiany przeglądarki. Sam kiedyś pisałem taką aplikację, która zarządzana była TYLKO przy pomocy AJAXa, bo osoba, dla której ją pisałem miała przeglądarkę, która to obsługiwała. Wystarczyło.
2) Grupa wąska – tutaj można ocenić, jakie jest wykorzystanie poszczególnych technologii w danej grupie odbiorców. Czasem można odrzucić niektóre „tryby zgodności”, czasem dochodzi się do wniosku, że jest to niemożliwe.
3) Ogólne community – w tym wypadku strona musi działać i być użyteczna pod Fx, Operą, IE (7, 6, dobrze by było, jakby na 5.5 i 5.0 też, ale nie popadajmy w paranoję, nie zawsze potrzeba), Linksem, w przeglądarkach mobilnych i screenreaderach. Na deser powinna być łatwa w indeksowaniu przez roboty. Tak być powinno, a jak jest, wszyscy wiemy :).

Co do wspomnianego wcześniej panelu administracyjnego joggera – tutaj sprawa ma się trochę inaczej, jest to bądź co bądź panel administracyjny. Jogger jest dostępny dla każdego, ale jest to przypadek, w którym można określić dla panelu jakieś konkretne wymagania, szczególnie, że społeczność joggerowców to głównie osoby świadome alternatywnych rozwiązań i najczęściej korzystające z nowoczesnych przeglądarek typu Fx/Opera, cieszące się z funkcjonalności, jakie daje AJAX i powiązane z nim technologie i trendy.
Riddle 42 10 listopada 2007, 02:52

Z tym joggerowym panelem to był FUD, działa pięknie bez JS – sami sprawdźcie.
Hoppke 43 10 listopada 2007, 12:27

@Dot: no ze wsparciem Opery wychodzi na to, że im po prostu zwisa.
Dobrym przykładem jest np. Writely, który kiedyś był przykładową aplikacją działającą prawie wszędzie i na wszystkim, a po wykupieniu przez Google nagle obsługa Opery się rozsypała.

Operowy UserScript pewnie by rozwalił IE i FF, bo zapewne nie ma w nim instrukcji uzależniających wykonywanie od modelu przeglądarki. Pewnie dałoby się go włączyć w JS Google.

Inna sprawa, że Opera ma chyba jakiś mechanizm „globalnego” patcha javascriptu, który jest rozpowszechniany z browserem (i chyba nawet synchronizowany co jakiś czas z serwerami Opery). Gdyby Google opracowało łatkę, która musiała być rozpowszechniana osobno, to mogliby ją dać ludziom z Opery, oni by ją włączyli i tyle.

Googlowe niewspieranie Opery to dobry temat na teorie spiskowe. Tak samo jak współpraca Google z FF (np. ten numer z przesyłaniem do Google referera i jakichś ciastek za każdym razem gdy subskrybujesz rss-y przez FF).

Jeśli dobrze kojarzę, to FF się ostatnio chciał wykręcić z dealu dofinansowywania przez Google , więc możliwe, że obsługa Opery się teraz polepszy. A może chcą, by Google ich finansowało mniej oficjalnie, PR by się poprawił... Się zobaczy.

BTW, kiedyś przechodziłem test kompetencji w ramach aplikowania do jednej z firm. Test wykonywało się przez browser przy użyciu jednorazowego loginu i hasła, który trzeba było wykorzystać w ciągu trzech dni chyba. Był to test wielokrotnego wyboru, ograniczony czas odpowiedzi na wszystkie pytania. Z założenia raczej nikt nie dałby rady odpowiedzieć na wszystko, więc można było pomijać pytania niewygodne. Ogólnie wyżej punktowali jakość odpowiedzi niż ich ilość.

Test był opakowany w JS który miał wykrywać próby „oszukiwania” – przełączanie okienek, otwieranie nowych kart itp. Chodziło o to, że gdy tylko użytkownik zmieni okienko na inne (by np. wygooglać odpowiedź) to cały test się unieważniało (i następny raz do firmy można było aplikować chyba dopiero po paru latach, a może w ogóle już nigdy?).

Tak, to była firma z baaaardzo dużym prestiżem (nie Google – ale równie rozpoznawalna w branży, zajmująca się softem na zamówienie i lepiej płacąca).

Pominę fakt, że tak „zabezpieczony” test i tak można było oszukać kładąc obok laptopa „do googlania odpowiedzi”.

Lepsze było to, że używałem wtedy pożyczonego komputera z jakąś starszą Operą. I JS na każdej stronie z pytaniem mi się wykładał, o czym Opera informowała gustownym okienkiem dialogowym. Podejrzewam, że zabezpieczenie „antycheaterskie” mnie nie obowiązywało :)

I cała ta otoczka elitarności i krytyczności testu umiejętności nagle prysła, bo użytkownik miał starszą przeglądarkę...
Morlo 44 12 listopada 2007, 09:22

I daltego lubie RoR, w latwy sposob mozna stworzyc wersje oparta na JS i bez JS :)
Piotr 45 12 listopada 2007, 11:38

Ten propagandowy tekst o IE, wyskakujący na początku, zdradza niedojrzałość emocjonalną autora.
Riddle 46 12 listopada 2007, 11:42

Nie, to jest strona z jednolitym przekazem, a nauka standardów na Explorerze jest histerycznie śmieszna.
dominik 47 12 listopada 2007, 14:39

Riddlu, zgadzam się w 100% z przekazem artykułu. Od jakiegoś czasu przyjęliśmy taką politykę, tworząc CRMy na zamówienie. JSowe gadżety + rzeczywiste usprawnienia są layerem ponad aplikacją, która poradzi sobie bez nich w razie konieczności.

Nie rozumiem jak takie wyważone przedstawienie sprawy może powodować taką ilość kontrowersji w komentarzach.
Hoppke 48 12 listopada 2007, 14:44

@dominik: widać wyważone przedstawienie było tak czytelne tylko dla niektórych, stąd kontrowersje.
Mateusz A. 49 22 listopada 2007, 02:15

Warto też wspomnieć, że testowanie poprawności zawartości pól formularza jedynie po stronie klienta (właśnie za pomocą JS) jest absolutnie niewybaczalną dziurą w systemie…

Były przypadki sklepów internetowych, gdzie po stronie klienta była przechowywana informacja o wartości zakupów i można ją było sobie podmienić przed wysłaniem formularza :-)
krokodyl 50 23 listopada 2007, 22:07

Jeszcze rok temu prawie w ogóle nie korzystałem z js przy tworzeniu www, teraz używam go coraz więcej – niestety :(
feedel 51 02 grudnia 2007, 11:08

I prawie wszystko znów rozbija się o to, czy robimy stronę dobrą, czy taką jaką chciał zleceniodawca.
Hoko 52 18 grudnia 2007, 18:39

Dzięki Bogu! Już myślałem, że tylko ja większość scriptowych rozwizań uważam za co najmniej przeszkadzające… A zleceniodawców to byście mogli trochę uświadamiać i wychowywać... ;)
Kuba 53 19 grudnia 2007, 23:32

Jak myślicie ile procent użytkowników (szacunkowo) ma wyłączony JavaScript ?
Drogomir 54 27 grudnia 2007, 13:18

Napisałem artykuł o tym jak podejść do nieinwazyjnego javascriptu w railsach – może komuś się przyda :)

Riddle: trackback coś nie bardzo chce działać.
Dostępny.net 55 12 stycznia 2008, 23:21

Dostępny (?) Flash

Flash jest chyba najpopularniejszą obecnie technologią stosowaną do prezentacji multimedialnych/interaktywnych elementów na stronach www. Jednocześnie nieomal równie często nadużywaną.
Niestety ze względu na swoja budowę nastręcza sporej[...]
Rafi 56 19 marca 2008, 18:08

Z mojego doświadczenia, a nieco go mam, przez nasze aplikacje przechodzi rocznie ok. 0,5 mln użytkowników problem wyłączonego JS praktycznie nie występuje. Nieomal wszystko opieramy na JS, chociaż oczywiście nie wyłącznie (vide: walidacja formularzy). Jeśli robi się aplikację internetową (nie jakąś tam stronkę, ale sensownej wielkości aplikację), którą ma mieć wygodny interfejs użycie JS jest praktycznie obowiązkowe. Wierzcie mi, że ludzie wolą mieć wygodny interfejs, niż żeby im działał bez JS. I wierzcie mi, że żaden zleceniodawca nie będzie płacił za wersję bez JS, bo szkoda na to pieniędzy. Każdy kto miał do czynienia ze zleceniodawcami doskonale o tym wie :). Chyba, że za kodowanie lubi zarabiać jak w mcDonaldzie, a i takich znam – widziałem niedawno ofertę, że ktoś zrobi prosty system zarządzania użytkownikami serwisu za kwotę... 50 zł. Powodzenia.
Riddle 57 25 marca 2008, 03:11

Hej, nie musimy Ci wierzyć, bo sami robimy strony i wbrew temu co chciałbyś myśleć, nie znajdziesz tutaj osób piszących tylko na swoje potrzeby. Dlatego jeśli chcesz coś osiągnąć, zejdź z tonu. ;-)

Przechodząc do meritum – aplikacje internetowe muszą wymagać JS; napisałem to także w poście, zerknij sam.

Istnieje duża szansa, że zleceniodawca w Polsce nie będzie płacił za wersję JS. Podobnie duża jak ta, że nie zapłaci za usprawnienia dostępności, czysty kod i przejrzyste style. Mało osób jest uświadomionych jak należy robić strony, a Ci którzy nie wiedzą zlecają pracę doświadczonym zespołom. Jeśli chcesz przynależeć do jednego z nich, musisz przestawić myślenie z klienckiego na zgodne ze standardami. Możliwe, że jesteś w stanie opchnąć klientowi niedoskonałą stronę – ale to na Tobie spocznie za to odpowiedzialność. Wystarczy, że świadomość będzie na tyle duża, że sam klient zechce zweryfikować to co zrobiłeś – i masz problem.

Dlatego warto podchodzić idealnie do kodu, poświęcać trochę więcej czasu. To wszystko się później zwróci.
zar 58 03 kwietnia 2008, 08:37

Po części to prawda, ale w dobie internetu 2.0 i youtube, można już założyć pewne minimum… Że filmy są odtwarzalne u użytkownika, że JS jest włączony… Takie rzeczy. Nie możemy popadać w paranoje i budować strony pod lynxa…