W dniu 17-06-2011 22:51, Marek pisze:
> Dnia Fri, 17 Jun 2011 21:01:23 +0200, Peter May napisał(a):
>
>> Pisanie czegokolwiek działającego z JS, jak i bez JS, to nie jest żadna
>> "sztuka dla sztuki". Tak powinno się pisać podstawowo, że tak to ujmę.
>
> Podobnie to ująłem - jeśli można cel osiągnąć bez JS, to tylko wtedy należy
> unikać JS. Mniej więcej taką intencję miałem. Natomiast nie powinno stawiać
> się celu "nie piszemy bez JS" i pod to robić założenia projektowe,
> ograniczoną funkcjonalność itp. JS czyni korzystanie z pewnych mechanizmów

Sęk w tym, że w założeniach projektowych nie biorę od dawna pod uwagę
rozważań "z JS czy bez JS". Co więcej, JS nie należy unikać w żaden
sposób. Jednak warto pisać w myśl zasady opisanej tutaj:
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript

To nie ma nic wspólnego z powiedzeniem "w JS mogę więcej". W JS
programujesz co chcesz, ale jeśli bez JS da się to obsłużyć, to w porządku.

> dużo przyaźniejsze niż czysty HTML pozwala. Przykładowo: facebookowcy - oni
> nie wyobrażają sobie strony WWW bez guzika "like". Można jego ohydną formę

Facebook to akurat idealny przykład na to, jak można kod skomplikować do
granic absurdu. Wygenerowany przycisk "Like" to
iframe->div->table->div->itd. Czy to nie jest lekko przesadzone? Zwykły
<a href="facebook?parmatery>Like</a> zupełnie zadziała bezproblemowo w
każdym przypadku.

> wbić w layout strony (niepotrzebnie za pomocą JS - ale zostawmy to) a można
> też zrobić wyjeżdżającą z prawej krawędzi strony zakładkę. Pewnie widywałeś
> taki bajerek. Nie zaśmieca ekranu i satysfakcjonuje miłośników portali
> społecznościowych.

Można programować wszystko, co się chce. Chodzi mi o to, aby było
zrobione to z głową. Przykład:

<a href="#" onclick="return test();">Kliknij mnie</a>

To _nie zadziała bez JS_, ale przecież poprawne wykonanie tego to banał.
Jest masa takich przykładów. Choćby przesadnie nadużywany XHR, który
rodzi czasem więcej problemów, niż pożytku.

>> Zwłaszcza, że to ani nie zajmuje więcej czasu, ani nie jest specjalnie
>> skomplikowane.
>
> Tu chyba nie zaskoczyłem. W HTMLu czystym nie da się zrobić tego co można
> za pomocą JS. Np. aby jekiś banner zniknął po 5s.

Nie da się i nie o to chodzi. Chodzi o to, że jak ktoś nie obsługuje JS,
to po prostu baner nie zniknie po 5 s. I nic się nie stanie.

>> Ponadto brak JS to nie tylko stare komórki:
>
> Nie nie - napisałem "raczkujące" a to bardziej z niemowlęciem się kojarzy a
> nie ze starocią. Przypis o radiach lampowych komputerów dotyczył. Może
> nieprecyzyjnie to ująłem, sorki.
>
>> 1. Korporacje. Tu nie zawsze panują zasady, jak w normalnym świecie. Ot,
>> choćby firewalle filtrujące ściąganą zawartość. Czasem nawet stare
>> przeglądarki, gdzie korpo ma napisaną aplikację pod starą przeglądarkę i
>> nikomu z zarządu nie spieszy się, by to zmienić, bo "przecież działa".
>> Poza tym to dość spory koszt może być.
>
> To prawda. Są też takie korporacje, które nie dają dostępu do internetu w
> ogóle. Jednakże dla nich znaków dymowych nikt nie tworzy ani faksem stron
> WWW nie przesyła. Jeśli z różnych względów tak sobie zrobili, to muszą
> liczyć się z konsekwencjami. Jeśli piszesz aplikację bardziej "intranetową"
> pod kątem tej korporacji, to co innego. Jeśli jednak strona WWW ma być dla
> ludu, to też inne reguły stosujesz.

Aplikacje intranetowe to inna sprawa. Jeśli jednak upubliczniasz jakąś
witrynę globalnie, to nigdy nie wiem kto na nią wchodzi i jak ma
skonfigurowaną przeglądarkę. A to oznacza, że trzeba być przygotowanym
na minimalną konfigurację, ale ciągle udostępniając zawartość dla
użytkownika.

>> 2. Wtyczki w przeglądarkach blokujące JS, np. NoScript pobrało już
>> https://addons.mozilla.org/pl/firefox/addon/noscript
/ 86 981 523. Ilu
>> użytkowników ma na maksa powyłączany JS, tego nie wiadomo. Warto też
>> zwrócić uwagę na takie akcje:
>> http://webgraph.com/resources/facebookblocker/. "Tysiące" ładujących się
>> skryptów spowalnia ładowanie się treści i nabija transfer :P
>
> To już inne zjawisko. Z jednej strony JS pod FF stał się kiedyś szalenie
> powolny względem IE. Chyba nawet o rząd wielkości. To trochę wkurzało ludzi
> z wolnymi maszynami głównie. Potem Facebook zaczął - moim zdaniem -
> nadużywać zaufania userów. Zaśmieca cały internet - można uznać tą
> organizację za największego spamera.

Gdyby facebook potrafił napisać sensownie własne API, to może nie byłoby
tak źle.

> Przypomnij sobie czasy gdy SPAMu nie było. Nie było trzeba tworzyć softu
> zwalczającego to zjawisko. Komputery z tym softem są wolniejsze itd Z tego
> powodu nie można powiedzieć, że emaile są beee bo ktoś zasypuje śmieciami
> naszą skrzynkę.

Przepraszam, nie bardzo rozumiem co ma spam facebook-owy do
facebook-owego JS?

>> 3. To, że dane urządzenie mobilne ma obsługę JS, to nie znaczy, że
>> wszystko jest ok. Spróbuj<input type="file" multiple="multiple" /> na
>> systemie Android 2.3 (np. Samsung Galaxy Tab). Nie działa. Mimo, że
>> wykrywam, iż jest to obsługiwane.
>
> Ale to nie jest JS tylko HTML :-)

No tak. Nie doprecyzowałem. Pisałem "upload progress bar" i okazało się,
że feature detection mówiło, iż przeglądarka obsługuje multi upload.
Tyle, że on, niestety, nie działa.

> Generalnie sam mam telefon z Androidem 2.3 (HTC Desire HD). Nierzadko
> korzystam z internetu na nim - gdy muszę. Nie zastanawiam się wtedy czy
> jakiś element nie działa poprawnie a już w szczególności pole typu "file".

Abstrahując od telefonów itp. warto poczytać to:
http://michaux.ca/articles/feature-detection-state-o
f-the-art-browser-scripting

Chodzi mi o to, że warto testować najpierw czy dane metody w JS są
dostępne, zanim się je użyje. Wówczas nie musisz zastanawiać się czy coś
jest czy czegoś nie ma. A z drugiej strony, jak w przykładzie, co
podałem, nie zawsze jak coś jest, to na pewno działa. Np. input type
date w Google Chrome którejś tam wersji wstecz również niby było
zaimplementowane, ale nie działało.

> Patrzę zazwyczaj, o której pociąg odjeżdża albo czy są bilety w kinie. To
> nie jest sprzęt do korzystania z internetu lecz raczej to zestaw ratunkowy
> gdy inaczej nie można.

E, to zależy. Na tablecie już się całkiem przyzwoicie korzysta z internet.

>> JS był, jest i będzie. Najlepiej po prostu separować JS tak, aby brak
>> jego nie powodował, że z czegoś nie da się skorzystać. Dobry przykładem
>> jest opis porneL-a: http://pornel.net/onclick
>
> A tak... czytałem to kiedyś :-) Zgadzam się co do słuszności Twojego
> postulatu jednakże jest on utopijny jak komunizm. :-) Możesz być jednostką

Nie jest utopijny. Sam tworzę rozwiązania, które działają bez JS bez
większego wysiłku.

> głoszącą prawdę ale i tak zostaniesz przysypany ludzką twórczością w
> zakresie JS. Dlatego ja odpuściłem sobie już dawno walkę z wiatrakami i
> zakładam, że każdy ma support JS choć staram się unikać tego gdzie tylko
> można. Oznacza to również, że bardziej wyszukane projekty z gadającymi
> między sobą Flahami współpracującymi w dodatku ze screenem przeglądarki itp
> muszą mieć JS. I... działa to na Androidzie nawet :-)

Każdy może przyjąć zasadę, jaką chce :-)

--
Peter